INTERNET DRAFT Tomohiro Otani
Updates: RFC 3471 KDDI R&D Labs
Intended status: standard track (Editor)
Expires: Jan. 31, 2009 July 14, 2008
Generalized Labels for G.694 Lambda-Switching Capable Label Switching
Routers
Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.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.
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. However, RFC 3471 has
defined that a wavelength label (section 3.2.1.1) "only has
significance between two neighbors" and global wavelength continuity
is not considered. In order to achieve interoperability in a network
composed of next generation lambda switch-capable equipment, this
document defines a standard lambda label format, being compliant with
ITU-T G.694. Moreover some consideration on how to ensure lambda
continuity with RSVP-TE is provided. This document is a companion to
the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It
defines the label format when Lambda Switching is requested in an all
optical network.
Table of Contents
T. Otani et al. Standard track - Expires Jan. 2009 [Page 1]
Internet Drafts July 2008
Status of this Memo................................................ 1
Abstract........................................................... 1
1. Introduction.................................................... 3
2. Conventions used in this document............................... 3
3. Assumed network model and related problem statement............. 3
4. Label Related Formats........................................... 5
5. Security consideration.......................................... 8
6. Acknowledgement................................................. 8
7. References...................................................... 8
7.1. Normative References.......................................... 8
7.2. Informative References........................................ 9
Editor's address................................................... 9
Contributors' address.............................................. 9
Intellectual property considerations.............................. 10
Copyright statement............................................... 10
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 2]
Internet Drafts July 2008
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 for four new classes of
interfaces and switching:
o Layer-2 Switch Capable (L2SC)
o Time-Division Multiplex (TDM)
o Lambda Switch Capable (LSC)
o 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].
This document presents details that are specific to the use of GMPLS
with a new generation of Lambda Switch Capable (LSC) equipment.
Technologies such as Reconfigurable Optical Add/Drop Multiplex
(ROADM) and Wavelength Cross-Connect (WXC) operate at the wavelength
switching level. As such, the wavelength is important information
that is necessary to set up a wavelength-based LSP appropriately and
the wavelength defined in [G.694] is widely utilized.
2. Conventions used in this document
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 [RFC2119].
3. Assumed network model and related problem statement
Figure 1 depicts an all-optically switched network consisting of
different vendor's optical network domains. Vendor A's network is a
ring topology that consists of ROADM or WXC, and vendor B's network
is a mesh topology consisting of PXCs and DWDMs, otherwise both
vendors' networks are based on the same technology.
In this case, the use of standardized wavelength label information is
quite significant to establish a wavelength-based LSP. It is also an
important constraint when conducting CSPF calculation for RSVP-TE
signaling. The way the CSPF is performed is outside the scope of this
document, but defined in [GMPLS-CSPF].
It is needless to say, a LSP must be appropriately provisioned
between a selected pair of ports not only within Domain A but also
over multiple domains satisfying wavelength constraints.
Figure 2 illustrates in detail the interconnection between Domain A
and Domain B.
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 3]
Internet Drafts July 2008
|
Domain A (or Vendor A) | Domain B (or Vendor B)
|
Node-1 Node-2 | Node-6 Node-7
+--------+ +--------+ | +-------+ +-+ +-+ +-------+
| ROADM | | ROADM +---|------+ PXC +-+D| |D+-+ PXC |
| or WXC +========+ or WXC +---|------+ +-+W+=====+W+-+ |
| (LSC) | | (LSC) +---|------+ (LSC) +-+D| |D+-+ (LSC) |
+--------+ +--------+ | | +-|M| |M+-+ |
|| || | +++++++++ +-+ +-+ +++++++++
|| Node-3 || | ||||||| |||||||
|| +--------+ || | +++++++++ +++++++++
||===| WXC +===|| | | DWDM | | DWDM |
| (LSC) | | +--++---+ +--++---+
||===+ +===|| | || ||
|| +--------+ || | +--++---+ +--++---+
|| || | | DWDM | | DWDM |
+--------+ +--------+ | +++++++++ +++++++++
| ROADM | | ROADM | | ||||||| |||||||
| or WXC +========+ or WXC +=+ | +-+ +++++++++ +-+ +-+ +++++++++
| (LSC) | | (LSC) | | | |D|-| PXC +-+D| |D+-+ PXC |
+--------+ +--------+ +=|==+W|-| +-+W+=====+W+-+ |
Node-4 Node-5 | |D|-| (LSC) +-+D| |D+-+ (LSC) |
| |M|-| +-+M| |M+-+ |
| +-+ +-------+ +-+ +-+ +-------+
| Node-8 Node-9
Figure 1 Wavelength-based network model.
+-------------------------------------------------------------+
| Domain A | Domain B |
| | |
| +---+ lambda 1 | +---+ |
| | |---------------|---------| | |
| WDM | N | lambda 2 | | N | WDM |
| =====| O |---------------|---------| O |===== |
| O | D | . | | D | O |
| T WDM | E | . | | E | WDM T |
| H =====| 2 | lambda n | | 7 |===== H |
| E | |---------------|---------| | E |
| R +---+ | +---+ R |
| | |
| N +---+ | +---+ N |
| O | | | | | O |
| D WDM | N | | | N | WDM D |
| E =====| O | WDM | | O |===== E |
| S | D |=========================| D | S |
| WDM | E | | | E | WDM |
| =====| 5 | | | 8 |===== |
| | | | | | |
| +---+ | +---+ |
+-------------------------------------------------------------+
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 4]
Internet Drafts July 2008
Figure 2 Interconnecting details between two domains.
In the scenario of Figure 2, consider the setting up of a
bidirectional LSP from ingress switch 1 to egress switch 4. In order
to satisfy wavelength continuity constraint, a fixed wavelength
(lambda 1) needs to be used in domain A and domain B. A Path message
will be used for the signaling, the PATH message must contain the
upstream label and a label set object; both containing the same
lambda. The label set object is made by only one sub channel that
must be same as the upstream label. The path setup will continue
downstream to switch 4 by configuring each lambda switch based on the
wavelength label. This label allows the correct switching of lambda
switches and the label contents needs to be used over the inter-
domain. As same above, the path setup will continue downstream to
switch 7 by configuring lambda switch based on multiple wavelength
labels. If the node has a tunable wavelength transponder, the tuning
wavelength is considered as a part of wavelength switching operation.
Not using a standardized label would add undue burden on the operator
to enforce policy as each manufacturer may decide on a different
representation and therefore each domain may have its own label
formats. Moreover, manual provisioning may lead to misconfiguration
if domain-specific labels are used.
Therefore, a wavelength label should be standardized in order to
allow interoperability between multiple domains; otherwise
appropriate existing labels are identified in support of wavelength
availability. As identical wavelength information, the ITU-T
frequency grid specified in [G.694.1] for Dense WDM (DWDM) and
wavelength information in [G.694.2] for Coarse WDM (CWDM) are used by
LSRs and should be followed as a wavelength label.
4. 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 based
on [G.694] and Label Set definition specific for LSC LSRs.
4.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.
LSC equipment uses multiple wavelengths controlled by a single
control channel. In such case, the label indicates the wavelength to
be used for the LSP. This document proposes to standardize the
wavelength label. 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]. In that sense, we can call G.694
wavelength labels.
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 5]
Internet Drafts July 2008
Since the ITU-T DWDM grid is based on nominal central frequencies, we
need to indicate the appropriate table, the channel spacing in the
grid and a value n that allows the calculation of the frequency.
That value can be positive or negative.
The frequency is calculated as such in [G.694.1]:
Frequency (THz) = 193.1 THz + n * channel spacing (THz)
, where n is an integer (positive, negative or 0) and channel spacing
is defined to be 0.0125, 0.025, 0.05 or 0.1 THz. When wider channel
spacing such as 0.2 THz is utilized, the combination of narrower
channel spacing and the value n can provide proper frequency with
that channel spacing. Channel spacing is not utilized to indicate the
LSR capability but only to specify a frequency in signaling.
For the other example of the case of the ITU-T CWDM grid, the spacing
between different channels was defined to be 20nm, so we need to pass
the wavelength value in nm in this case. Examples of CWDM
wavelengths are 1470, 1490, etc. nm.
The wavelength is calculated as follows
Wavelength (nm) = 1470 nm + n * 20 nm
The tables listed in [G.694.1] and [G.694.2] are not numbered and
change with the changing frequency spacing as technology advances, so
an index is not appropriate in this case.
4.2 DWDM Wavelength Label
For the case of DWDM, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S | Reserved | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) Grid: 3 bits
The value for grid is set to 1 for ITU-T DWDM Grid as defined in
[G.694.1].
+----------+---------+
| Grid | Value |
+----------+---------+
|ITU-T DWDM| 1 |
+----------+---------+
|ITU-T CWDM| 2 |
+----------+---------+
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 6]
Internet Drafts July 2008
|Future use| 3 - 7 |
+----------+---------+
(2) C.S.(channel spacing): 4 bits
DWDM channel spacing is defined as follows.
+----------+---------+
| C.S(GHz) | Value |
+----------+---------+
| 12.5 | 1 |
+----------+---------+
| 25 | 2 |
+----------+---------+
| 50 | 3 |
+----------+---------+
| 100 | 4 |
+----------+---------+
|Future use| 5 - 15 |
+----------+---------+
(3) n: 17 bits
n is an integer to take either a negative, zero or a positive value.
The value used to compute the frequency as shown above.
4.3 CWDM Wavelength Label
For the case of CWDM, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S | Reserved | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The structure of the label in the case of CWDM is the same as that of
DWDM case.
(1) Grid: 3 bits
The value for grid is set to 2 for ITU-T CWDM Grid as defined in
[G.694.2].
+----------+---------+
| Grid | Value |
+----------+---------+
|ITU-T DWDM| 1 |
+----------+---------+
|ITU-T CWDM| 2 |
+----------+---------+
|Future use| 3 - 7 |
+----------+---------+
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 7]
Internet Drafts July 2008
(2) C.S.(channel spacing): 4 bits
CWDM channel spacing is defined as follows.
+----------+---------+
| C.S(nm) | Value |
+----------+---------+
| 20 | 1 |
+----------+---------+
|Future use| 2 - 15 |
+----------+---------+
(3) n: 17 bits
n is an integer. The value used to compute the wavelength as shown
above.
We do not need to define a new type as the information stored is
either a port label or a wavelength label. Only the wavelength label
as above needs to be defined.
5. Security consideration
This document introduces no new security considerations to [RFC3473].
GMPLS security is described in section 11 of [RFC3471] and refers to
[RFC3209] for RSVP-TE.
6. Acknowledgement
The authors would like to thank Adrian Farrel, Lawrence Mao, Zafar
Ali and Dan Li for the discussion.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 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.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling - Resource ReserVation Protocol Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 8]
Internet Drafts July 2008
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
7.2. Informative References
[GMPLS-CSPF] Otani, T., et al, "Considering Generalized Multiprotocol
Label Switching Traffic Engineering Attributes During Path
Computation", draft-otani-ccamp-gmpls-cspf-constraints-07.txt, Nov.
2007.
[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.
Editor's address
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
Contributors' address
Richard Rabbat
Google, Inc.
1600 Amphitheatre Pkwy
Mountain View, CA 94043
Email: rabbat@alum.mit.edu
Sidney Shiba
Email: sidney.shiba@yahoo.com
Hongxiang Guo
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Saitama, 356-8502, Japan.
Phone: +81-49-278-7864.
Email: ho-guo@kddilabs.jp
Keiji Miyazaki
Fujitsu Laboratories Ltd
4-1-1 Kotanaka Nakahara-ku, Kawasaki Kanagawa, 211-8588, Japan
Phone: +81-44-754-2765
Email: miyazaki.keiji@jp.fujitsu.com
Diego Caviglia
Ericsson
16153 Genova Cornigliano, ITALY
Phone: +390106003736
Email: diego.caviglia@ericsson.com
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 9]
Internet Drafts July 2008
Intellectual property considerations
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.
Copyright statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
T. Otani et al. Standard track - Expires Jan. 31, 2008 [Page 10]