One document matched: draft-otani-ccamp-gmpls-lambda-labels-00.txt
IETF Internet Draft T. Otani
Updates: RFC 3471 H. Guo
Proposed status: standard track KDDI R&D Labs
Expires:Dec. 2007 K. Miyazaki
Fujitsu Lab.
Diego Caviglia
Ericsson
June 2007
Generalized Labels of Lambda-Switching Capable Label Switching
Routers (LSR)
Document: draft-otani-ccamp-gmpls-lambda-labels-00.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
[RFC3471] has defined that a wavelength label (section 3.2.1.1) "only
has significance between two neighbors" and global wavelength
continuity is not considered and getting significant. In order to
achieve interoperability in a network composed of new generation
lambda switch-capable equipment, this document proposes a standard
lambda label format. Moreover some consideration on how to ensure
lambda continuity with RSVP-TE is provided.
T. Otani et al. Standard track - Expires Dec. 2007 1
Internet Drafts June 2007
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
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Conventions used in this document...............................3
4. Requirements on Label Identification............................5
7. Security consideration..........................................9
8. Acknowledgement................................................10
9. Intellectual property considerations...........................10
Author's Addresses................................................11
Document expiration...............................................11
Copyright statement...............................................11
T. Otani et al. Informational - Expires Dec. 2007 2
Internet Drafts June 2007
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:
- Layer-2 Switch Capable (L2SC)
- Time-Division Multiplex (TDM)
- Lambda Switch Capable (LSC)
- 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.
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’ network is 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 within Domain A, considering
wavelength information. Even over multiple domains, a LSP must be
accordingly established satisfying wavelength constraints.
Figure 2 illustrates in detail the interconnection between Domain A
and Domain B.
T. Otani et al. Informational - Expires Dec. 2007 3
Internet Drafts June 2007
|
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) | | | PXC +-+D| |D+-+ PXC |
+--------+ +--------+ | | +-+W+=====+W+-+ |
Node-4 Node-5 | | (LSC) +-+D| |D+-+ (LSC) |
| | +-+M| |M+-+ |
| +-------+ +-+ +-+ +-------+
| Node-8 Node-9
Figure 1 Wavelength-based network model
+---------------------------------------------------------------+
| Domain A | Domain B |
| | |
| +---+ +---+ lambda 1 | +---+ +---+ |
| | | |L S|---------------|---------|L S| |L S|-- |
| --| | |A W| lambda 2 | |A W| |A W|-- |
| --| | WDM |M I|---------------|---------|M I| |M I|-- |
| --|L S|=====|B T| . | |B T| WDM |B T|-- |
| --|A W| |D C| . | |D C|=====|D C|-- |
| --|M I| |A H| lambda n | |A H| |A H|-- |
| --|B T| | 2|---------------|---------| 3| | 4|-- |
| --|D C| +---+ | +---+ +---+ |
| --|A H| | |
| --| 1| +---+ | +---+ +---+ |
| --| | |L S| | |L S| |L S|-- |
| --| | |A W| | |A W| |A W|-- |
| --| | WDM |M I| WDM | |M I| WDM |M I|-- |
| --| |=====|B T|=========================|B T|=====|B T|-- |
| --| | |D C| | |D C| |D C|-- |
| --| | |A H| | |A H| |A H|-- |
| | | | 5| | | 6| | 7|-- |
| +---+ +---+ | +---+ +---+ |
+---------------------------------------------------------------+
Figure 2 Interconnecting details between two domains
T. Otani et al. Informational - Expires Dec. 2007 4
Internet Drafts June 2007
In the scenario of Figure 2, consider the setting up of a
bidirectional LSP from ingress switch 1 to egress switch 4. A fixed
wavelength (lambda 1) will be used in domain A throughout domain B
satisfying wavelength continuity. A Path message will be used for the
signaling, the PATH message must contain the upstream label and a
label set object; both this two objects have to contain the same
lambda, that is, the label set object is made by only one sub channel
that must be the 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.
4. Requirements on Label Identification
Here, some signaling-related requirements are listed considering
actual operation of above wavelength switched optical networks.
1. 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.
2. 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) SHOULD be used by LSC LSRs when setting up LSPs.
3. Labels SHOULD be stable and not allow for rounding errors.
4. Existing labels should be still utilized appropriately even if
wavelength availability is advertised.
Moreover, some routing-related requirements are indicated, but not
covered in this document.
5. An operator MAY want to advertise wavelength availability in the
network.
6. Care SHOULD be taken if advertising the wavelength availability in
order to reduce impact on the existing OSPF-TE.
7. To decrease the probability of operators' error or difficulties,
it is RECOMMENDED that advertising using OSPF-TE/ISIS-TE be
standardized to simplify management.
5. Label Related Formats
T. Otani et al. Informational - Expires Dec. 2007 5
Internet Drafts June 2007
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.
5.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].
Since the ITU-T DWDM grid is based on nominal central frequencies, we
will 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.0 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, 0.1, or 0.2 THz.
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 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.
5.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.|S| n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) Grid: 3 bits
T. Otani et al. Informational - Expires Dec. 2007 6
Internet Drafts June 2007
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 |
+----------+---------+
|Future use| 3 - 7 |
+----------+---------+
(2) C.S.(channel spacing): 3 bits
DWDM channel spacing is defined as follows.
+----------+---------+
| C.S(GHz) | Value |
+----------+---------+
| 12.5 | 1 |
+----------+---------+
| 25 | 2 |
+----------+---------+
| 50 | 3 |
+----------+---------+
| 100 | 4 |
+----------+---------+
| 200 | 5 |
+----------+---------+
|Future use| 6 – 7 |
+----------+---------+
(3) S: 1 bit
Sign for the value of n, set to 1 for (-) and 0 for (+)
(4) n: 9 bits
The value used to compute the frequency as shown above.
5.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 | Lambda | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T. Otani et al. Informational - Expires Dec. 2007 7
Internet Drafts June 2007
(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 |
+----------+---------+
(2) Lambda: 11 bits
Integer value of lambda in nm is defined as below.
+-------------+
| Lambda (nm) |
+-------------+
| 1470 |
+-------------+
| 1490 |
+-------------+
| 1510 |
+-------------+
| 1530 |
+-------------+
| 1550 |
+-------------+
| 1590 |
+-------------+
| 1610 |
+-------------+
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.
6. Lambda constraint in all-optical networks
6.1 Wavelength continuity
An all-optical network imposes the Lambda continuity constraint, that
is, a label cannot be changed hop by hop, but must have an end to end
scope.
The above is not supported by RFC3471 that states that a label has
significance only between two neighbors.
T. Otani et al. Informational - Expires Dec. 2007 8
Internet Drafts June 2007
This memo changes the way an all optical node process and manage a
Path message with Lambda label.
Two possible scenarios are taken into consideration:
1. The node is able via OEO operation to change the Lambda
2. The node is a pure optical device and is not able to change the
Lambda
The first scenario can be supported either by nodes with a double
switching matrix (eclectic and optic) but also by nodes that have
only an optic matrix and a G.709 tunable transponder on the outgoing
interface.
This scenario is covered by 3471 procedures and then will not be
taken into consideration in the following.
Scenario 2 imposes in case of bidirectional LSPs some constraints:
. on the same hop Upstream and Downstream must be the same;
. on an end to end basis the LSP must use the same Label
The first constraint do not need any modification to the already
defined RSVP-TE protocols and behaviors, and can be satisfied just
setting the Upstream Label value equal to the Label Set subchannel
value. The action must be inclusive and there must be only one
subchannel in the object.
The second constraint cannot be satisfied with the way RSVP-TE works
today. The solution proposed here is: if a node is not able to
perform OEO conversion then it must use on its outgoing interface the
same Lambda it received on the incoming interface.
The above applies in the case the ERO does not contain information up
to the label level.
6.2 Advertising wavelength availability
Wavelength availability may be thought of as a constraint in an all-
optical network. Although it may be collected through an EMS/NMS
system, operators may want to have it advertised using GMPLS routing.
It may be needed to standardize the information advertised using
OSPF-TE and ISIS-TE if an operator wishes to have it advertised. This
allows the operator to parse LSA information without regard to the
applied policy in different manufacturer domains. However, more
investigation to extend the existing routing protocol is required
from the point of routing scalability and this consideration is out
of scope in this document.
7. 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.
T. Otani et al. Informational - Expires Dec. 2007 9
Internet Drafts June 2007
8. Acknowledgement
The authors would like to express their thanks to Sidney Shiba,
Richard Rabbat for originally initiating this work. They also thank
Adrian Farrel and Lawrence Mao for the discussion.
9. 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.
10. References
10.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.
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
T. Otani et al. Informational - Expires Dec. 2007 10
Internet Drafts June 2007
10.2. Informative 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.
[GMPLS-CSPF] Otani, T., et al, "Considering Generalized Multiprotocol
Label Switching Traffic Engineering Attributes During Path
Computation", draft-otani-ccamp-gmpls-cspf-constraints-05.txt, March
2007.
Author's Addresses
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp
Hongxiang Guo
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Phone: +81-49-278-7864
Saitama, 356-8502. Japan Email: ho-guo@kddilabs.jp
Keiji Miyazaki
Fujitsu Laboratories Ltd
4-1-1 Kotanaka Nakahara-ku, Kawasaki Phone: +81-44-754-2765
Kanagawa, 211-8588. Japan Email: miyazaki.keiji@jp.fujitsu.com
Diego Caviglia
Ericsson
16153 Genova Cornigliano Phone: +390106003736
ITALY Email: diego.caviglia@ericsson.com
Document expiration
This document will be expired in Dec. 30, 2007, unless it is updated.
Copyright statement
Copyright (C) The IETF Trust (2007).
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
T. Otani et al. Informational - Expires Dec. 2007 11
Internet Drafts June 2007
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
T. Otani et al. Informational - Expires Dec. 2007 12 | PAFTECH AB 2003-2026 | 2026-04-23 16:30:23 |