[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt
hi,
there is a specific point to be clarified in this document:
semanticless vs semanticful label (even here there is a distinction
between spectral vs indexes i.e. using the wavelength index)
domain-wide vs link local significant label
so, the comparison from this perspective with TDM labels is difficult to
parse, the latter is semanticful but link local
now, i don't specifically see what has changed the late 90's, early
y2k's, to have a change in the wavelength label definition; there are
several solution possible
- absolute values: the freq. of the wavelength: difficult to adopt
because referenced values are nominal and knowing all interactions
between wavelengths this knowledge is at the end of little practical
usage; (introduces implicit ordering)
- indexed values: the # of the wavelength: it does not provide for a
future proof label space for inst. in case new frequencies are inserted
in the grid (introduces explicit ordering)
- diff. values e.g. freq spacing starting from a reference value: pauses
the question of the reference value and does suffer from the former
issue (introduces implicit ordering)
- the solution available today - cumbersome in some control plane
operations (e.g. label set translation) and not easy to troubleshoot but
independent of any physical consideration (spectral), scale to any
number of wavelength per fiber, does not introduce any ordering, the
most flexible (since allowing each system to maintain its specific
control operations) and the less constraining since maintaining the
control plane operations independent of any data plane specifics
<http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt>
CCAMP Working Group Sidney Shiba (Fujitsu)
Internet Draft Richard Rabbat (Fujitsu)
Updates: 3471
Proposed Category: Standards Track
Expires: March 2006 September 2005
Generalized Labels of Lambda-Switching Capable Label Switching
Routers (LSR)s
draft-shiba-ccamp-gmpls-lambda-labels-00.doc.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference
[RFC2119].
Abstract
Technology in the optical domain is constantly evolving and as a
consequence new equipment providing lambda switching capability has
been developed and is currently being deployed. [RFC3471] has defined
that a wavelength label (section 3.2.1.1) "only has significance
between two neighbors". However, in a network composed of a new
Expires March 2006 [Page 1]
Generalized Labels for LSC-Capable LSRs October 2005
generation of lambda switch-capable equipment, this document explains
why the label should have global meaning similarly to the label
defined for SONET/SDH technology (SUKLM format defined in [RFC3946])
and describes extensions to enable global meaning.
This document is a companion to the Generalized Multi-Protocol Label
Switching (GMPLS) signaling. It defines the Label Switching Capable
(LSC) technology specific information needed when using GMPLS.
Table of Contents
1. Introduction.....................................................2
1.1. Problem Description............................................2
2. Label Related Formats............................................4
2.1. Wavelength Labels..............................................4
2.2. Label Set Wavelength Subchannel................................4
2.3. RSVP-TE Extensions.............................................5
3. IANA Considerations..............................................5
4. Security Considerations..........................................5
5. Acknowledgements.................................................6
6. References.......................................................7
6.1. Normative References...........................................7
6.2. Informative Reference..........................................8
7. Copyright Statement.............................................10
8. Intellectual Property Statement.................................11
1. Introduction
As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from
supporting only packet (Packet Switching Capable - PSC) interfaces
and switching to also include support of four new classes of
interfaces and switching: Layer-2 Switch Capable (L2SC), Time-
Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-
Switch Capable (FSC). A functional description of the extensions to
MPLS signaling needed to support new classes of interfaces and
switching is provided in [RFC3471].
1.1. Problem Description
This document presents details that are specific to the use of GMPLS
with a new generation of Lambda Switch Capable (LSC) equipment as
opposed to a the prior generation of LSC equipment composed of of
Wavelength Division Multiplexing (WDM) + Photonic Cross Connect (PXC)
combined system (shown below) that was originally considered at the
time of writing of RFC 3471.
Expires October 2005 [Page 2]
Generalized Labels for LSC-Capable LSRs October 2005
Technologies such as Reconfigurable Optical Add/Drop Multiplex
(ROADM) and Dynamic-OADM operate at the wavelength switching level.
As such, the wavelength is important information that is necessary to
successfully setup a wavelength LSP.
_______ _______ _______
/|_|6 1|_|\ /|_|5 1|_|\ /|_|5 1|_|\
| |_|7 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM
===| |_|8 (1) 3|_| |=====| |_|7 (2) 3|_| |======| |_|7 (3) 3|_| |====
| |_|9 4|_| | | |_|8 4|_| | | |_|8 4|_| |
\| |_______| |/ \| |_______| |/ \| |_______| |/
For technologies such as the ROADM and DOADM, the WDM port mapping
does not provide sufficient information for selecting the required
wavelength for an LSP. Here are four cases that highlight where it is
important to have wavelength information available globally.
1. Label Set: A Label Set object may be used to limit the label
choices of a downstream node (section 3.5 of RFC 3471). This
Label Set object needs to carry one of the labels defined in
section 3.2 of that same document, i.e. either port, wavelength
label or waveband label. In order to be able to generate that
wavelength information, it is important to have global
dissemination of wavelength information.
2. Explicit Route Object/Record Route Object: Here as well, any
meaningful information should be global, which implies the use of
wavelength since a locally-significant label will have no meaning.
3. In SONET/SDH, one can think of the label with the set values of
SUKLM bits as locally significant and set their values as a
matter of policy to have global meaning. This would add undue
burden on the operator to enforce policy. In addition, manual
provisioning may lead to misconfiguration.
4. Finally, the values for the wavelengths need to be out of the
same pool of values to have global meaning. Any representation
of the lambdas needs to be the same on all nodes irrespective of
the manufacturer.
_______ _______ _______
| | | | | |
WDM | LSC | WDM | LSC | WDM | LSC | WDM
=======|1 2|=========|1 2|=========|1 2|=======
| | | | | |
|_______| |_______| |_______|
Expires October 2005 [Page 3]
Generalized Labels for LSC-Capable LSRs October 2005
The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM)
and [G.694.2] for Coarse WDM (CWDM) are the labels that SHOULD be
used by these LSC LSRs.
2. Label Related Formats
To deal with the widening scope of MPLS into the optical and time
domains, several new forms of "label" have been defined in [RFC3471].
This section contains clarifications for the Wavelength label and
Label Set definition specific for LSC LSRs.
2.1. Wavelength Labels
In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to
have significance between two neighbors, and the receiver may need to
convert the received value into a value that has local significance.
Equipment providing "true" lambda switching (LSC) uses multiple
wavelengths controlled by a single control channel. In such case, the
label indicates the wavelength to be used for the LSP. In order to
allow global meaning, this document redefines the Wavelength label as
being an IEEE floating point encoding of the wavelength. As an
example of wavelength values, the reader is referred to [G.694.1]
which lists the frequencies from the ITU-T DWDM frequency grid. The
same can be done for CWDM technology by using the wavelength defined
in [G.694.2].
The information carried in a Wavelength label is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: 32 bits
The label indicates the frequency value to be used. The value is
IEEE Floating point encoded. This may be an ITU-T DWDM frequency.
For convenience, Appendix 1 provides the list of IEEE Floating
point values for the ITU-T DWDM frequency grid.
2.2. Label Set Wavelength Subchannel
This document aligns with the general definition of Label Set in
section 3.5 of [RFC3471]. However, it provides a clarification
Expires October 2005 [Page 4]
Generalized Labels for LSC-Capable LSRs October 2005
related to the subchannel value to be used by an LSC LSR. For this
type of equipment the subchannel field SHOULD represent the
Wavelength label (ITU-T DWDM frequency grid).
2.3. RSVP-TE Extensions
In other to distinguish Wavelength label with local significance from
the Wavelength label with global meaning, the latter SHOULD use the
same format as the generalized label with the new C-Type (TBA).
In the context of "true" lambda switching, the generalized label has
the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU-T DWDM Frequency Grid Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current
document an object is defined. This object contains a C-Type. This
section defines the rules for the assignment of the related C-Type
value. This section uses the terminology of BCP 26 "Guidelines for
Writing an IANA Considerations Section in RFCs" [BCP26].
As per [RFC2205], C-Type is an 8-bit number that identifies the
function of an object. All possible values except zero are available
for assignment.
The assignment of the C-Type value of the object defined in this
document inherits C-Type from the Label object, i.e., object class
number 16 [RFC3209].
The Wavelength Switching Label defined in this document has the
following C-Type value to be assigned by IANA:
o RSVP_LABEL (Class-Num = 16)
- Wavelength Switching Label (C-Type = To Be Assigned)
4. Security Considerations
Expires October 2005 [Page 5]
Generalized Labels for LSC-Capable LSRs October 2005
There may be an argument that by giving the label global meaning, one
would decrease security. The closest example of using global meaning
is the label setting for SONET/SDH. By using a global meaning for its
labels, SONET/SDH did not introduce any new security considerations.
This serves as an indication that this document introduces no new
security considerations to either [RFC3473] or [RFC3472]. GMPLS
security is described in section 11 of [RFC3471] and refers to
[RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP.
5. Acknowledgements
The authors would like to thank Adrian Farrel for his feedback and
comments.
Expires October 2005 [Page 6]
Generalized Labels for LSC-Capable LSRs October 2005
6. References
6.1. Normative References
[G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
applications: DWDM frequency grid", June 2002.
[G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM
applications: CWDM wavelength grid", December 2003.
[IEEE754] "Standard for Binary Floating-Point Arithmetic", IEEE-
754, 1985.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constrained-Based LSP Setup using LDP", RFC 3212,
January 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
Protocol Label Switching (MPLS) Signaling - Constraint-
based Routed Label Distribution Protocol (CR-LDP)
Extensions", RFC 3472, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS} Signaling - Resource ReserVation Protocol Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
Expires October 2005 [Page 7]
Generalized Labels for LSC-Capable LSRs October 2005
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
6.2. Informative Reference
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
Appendix 1 - ITU-T DWDM frequency grid and IEEE floating point
The list below illustrates some nominal central frequencies within
the C and L bands of the DWDM grid (12.5THz spacing) taken from
[G.694.1]and their respective IEEE floating point (32 bits encoding)
value [IEEE754].
Nominal central Wavelength label
Frequency (THz) (IEEE Floating point)
--------------------- ------------------------
. .
. .
. .
195.9375 0x4343F000
195.9250 0x4343ECCD
195.9125 0x4343E99A
195.9000 0x4343E666
195.8875 0x4343E333
195.8750 0x4343E000
195.8625 0x4343DCCD
195.8500 0x4343D99A
195.8375 0x4343D666
195.8250 0x4343D333
195.8125 0x4343D000
195.8000 0x4343CCCD
195.7875 0x4343C99A
195.7750 0x4343C666
195.7625 0x4343C333
195.7500 0x4343C000
195.7375 0x4343BCCD
195.7250 0x4343B99A
195.7125 0x4343B666
195.6875 0x4343B000
195.6750 0x4343ACCD
Expires October 2005 [Page 8]
Generalized Labels for LSC-Capable LSRs October 2005
195.6625 0x4343A99A
. .
. .
. .
. .
. .
. .
193.2375 0x43413CCD
193.2250 0x4341399A
193.2125 0x43413666
193.2000 0x43413333
193.1875 0x43413000
193.1750 0x43412CCD
193.1625 0x4341299A
193.1500 0x43412666
193.1375 0x43412333
193.1250 0x43412000
193.1125 0x43411CCD
193.1000 0x4341199A
193.0875 0x43411666
193.0750 0x43411333
193.0625 0x43411000
193.0500 0x43410CCD
193.0375 0x4341099A
193.0250 0x43410666
193.0125 0x43410333
193.0000 0x43410000
192.9875 0x4340FCCD
192.9750 0x4340F99A
192.9625 0x4340F666
. .
. .
. .
. .
. .
. .
184.7750 0x4338C666
184.7625 0x4338C333
184.7500 0x4338C000
184.7375 0x4338BCCD
184.7250 0x4338B99A
184.7125 0x4338B666
184.7000 0x4338B333
184.6875 0x4338B000
184.6750 0x4338ACCD
184.6625 0x4338A99A
184.6500 0x4338A666
184.6375 0x4338A333
Expires October 2005 [Page 9]
Generalized Labels for LSC-Capable LSRs October 2005
184.6250 0x4338A000
184.6125 0x43389CCD
184.6000 0x4338999A
184.5875 0x43389666
184.5750 0x43389333
184.5625 0x43389000
184.5500 0x43388CCD
184.5375 0x4338899A
184.5250 0x43388666
184.5125 0x43388333
184.5000 0x43388000
. .
. .
. .
Authors' Addresses
Sidney Shiba (Fujitsu)
2801 Telecom Parkway
Richardson, TX 75082, USA
Phone: +1 972 479 6041
Email: sidney.shiba@us.fujitsu.com
Richard Rabbat (Fujitsu)
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085, USA
Phone: +1 408 530 4537
Email: richard@us.fujitsu.com
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7. Copyright Statement
Expires October 2005 [Page 10]
Generalized Labels for LSC-Capable LSRs October 2005
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires October 2005 [Page 11]