[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6205

INTERNET DRAFT                                           Tomohiro Otani
Updates: RFC 3471                                                  KDDI
Intended status: standard track                                (Editor)
Expires: July 19, 2009                                 January 13, 2009


 Generalized Labels for G.694 Lambda-Switching Capable Label Switching
                                Routers

      Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and 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.

   This Internet-Draft will expire on July 19, 2009.


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.


T. Otani et al.   Standard track - Expires July 19, 2009           [Page 1]

Internet Drafts                                            January 2009

Table of Contents

   Abstract...........................................................1
   1. Introduction....................................................2
   2. Conventions used in this document...............................2
   3. Assumed network model and related problem statement.............2
   4. Label Related Formats...........................................5
   5. Security Considerations.........................................8
   6. IANA Considerations.............................................9
   7. Acknowledgement................................................10
   8. References.....................................................11
   8.1. Normative References.........................................11
   8.2. Informative References.......................................11
   Appendix A. DWDM Example..........................................11
   Appendix B. CWDM Example..........................................12
   Authors' address..................................................13
   Intellectual property and Copyright Statement.....................14


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



T. Otani et al.  Standard track - Expires July 19, 2009        [Page 2]

Internet Drafts                                            January 2009

   Figure 1 depicts an all-optically switched network consisting of
   different vendor's optical network domains. Vendor A's network
   consists of ROADM or WXC, and vendor B's network consists of PXCs and
   DWDMs, otherwise both vendors' networks might be 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.





                                  |
      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             |

T. Otani et al.  Standard track - Expires July 19, 2009        [Page 3]

Internet Drafts                                            January 2009

      |                               |                             |
      |           +---+     lambda 1  |         +---+               |
      |           |   |---------------|---------|   |               |
      |       WDM | N |     lambda 2  |         | N | WDM           |
      |      =====| O |---------------|---------| O |=====          |
      |  O        | D |        .      |         | D |        O      |
      |  T    WDM | E |        .      |         | E | WDM    T      |
      |  H   =====| 2 |     lambda n  |         | 6 |=====   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 |=====          |
      |           |   |               |         |   |               |
      |           +---+               |         +---+               |
      +-------------------------------------------------------------+

           Figure 2 Interconnecting details between two domains.

   In the scenario of Figure 1, consider the setting up of a
   bidirectional LSP from ingress switch 1 to egress switch 9. 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 9 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 9 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.


T. Otani et al.  Standard track - Expires July 19, 2009        [Page 4]

Internet Drafts                                            January 2009


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.

   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 1471, 1491, etc. nm.

   The wavelength is calculated as follows

      Wavelength (nm) = 1471 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


T. Otani et al.  Standard track - Expires July 19, 2009        [Page 5]

Internet Drafts                                            January 2009

   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    |
      +----------+---------+
      |Future use|  3 - 7  |
      +----------+---------+

   (2) C.S.(channel spacing): 4 bits

   DWDM channel spacing is defined as follows.

      +----------+---------+
      | C.S(GHz) |  Value  |
      +----------+---------+
      |    100   |    1    |
      +----------+---------+
      |    50    |    2    |
      +----------+---------+
      |    25    |    3    |
      +----------+---------+
      |    12.5  |    4    |
      +----------+---------+
      |Future use|  5 - 15 |
      +----------+---------+

   (3) n: 16 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

T. Otani et al.  Standard track - Expires July 19, 2009        [Page 6]

Internet Drafts                                            January 2009

       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  |
      +----------+---------+

   (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: 16 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.












T. Otani et al.  Standard track - Expires July 19, 2009        [Page 7]

Internet Drafts                                            January 2009


5. Security Considerations

   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.  Standard track - Expires July 19, 2009        [Page 8]

Internet Drafts                                            January 2009


6. IANA Considerations

   This document has no actions for IANA.



















































T. Otani et al.  Standard track - Expires July 19, 2009        [Page 9]

Internet Drafts                                            January 2009


7. Acknowledgement

   The authors would like to thank Adrian Farrel, Lawrence Mao, Zafar
   Ali, Dan Li and Daniele Ceccarelli for the discussion and their
   comments.

















































T. Otani et al.  Standard track - Expires July 19, 2009       [Page 10]

Internet Drafts                                            January 2009


8. References

8.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.

8.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-08.txt, Feb.
   2008.

   [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.


Appendix A. DWDM Example

   Considering the network displayed in figure 1 it is possible to show
   an example of LSP set up using the lambda labels.

   Node 1 receives the request for establishing an LSP from itself to
   Node 9. The ITU-T grid to be used is the DWDM one, the channel
   spacing is 50Ghz and the wavelength to be used is 193,35 THz.

   Node 1 signals the LSP via a Path message including a Wavelength
   Label structured as defined in section 4.2:

       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                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


T. Otani et al.  Standard track - Expires July 19, 2009       [Page 11]

Internet Drafts                                            January 2009

   Where:

   Grid = 1 : ITU-T DWDM grid
   C.S. = 2 : 50 GHz channel spacing
   n    = 5 :

        Frequency (THz) = 193.1 THz + n * channel spacing (THz)

        193.35 (THz) = 193.1 (THz) + n* 0.05 (THz)

        n = (193.35-193.1)/0.05 = 5


Appendix B. CWDM Example

   The network displayed in figure 1 can be used also to display an
   example of signaling using the Wavelength Label in a CWDM
   environment.

   This time the signaling of an LSP from Node 4 to Node 7 is
   considered. Such LSP exploits the CWDM ITU-T grid with a 20nm
   channel spacing and is to established using wavelength equal to 1331
   nm.

   Node 4 signals the LSP via a Path message including a Wavelength
   Label structured as defined in section 4.3:

       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                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   Grid = 2 : ITU-T CWDM grid
   C.S. = 1 : 20 nm channel spacing
   n    = -7 :

        Wavelength (nm) = 1471 nm + n * 20 nm

        1331 (nm) = 1471 (nm) + n * 20 nm

        n = (1331-1471)/20 = -7











T. Otani et al.  Standard track - Expires July 19, 2009       [Page 12]

Internet Drafts                                            January 2009

Authors' address

   Tomohiro Otani
   KDDI Corporation
   2-3-2 Nishishinjuku Shinjuku-ku Tokyo, 163-8003, Japan
   Phone:  +81-3-3347-6006
   Email:  tm-otani@kddi.com


   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
   Email: hongxiang.guo@gmail.com


   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 July 19, 2009       [Page 13]

Internet Drafts                                            January 2009


Full Copyright Statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF Trust 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 any IETF 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.

   Copies of Intellectual Property 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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including


T. Otani et al.  Standard track - Expires July 19, 2009       [Page 14]

Internet Drafts                                            January 2009

   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.












































T. Otani et al.  Standard track - Expires July 19, 2009       [Page 15]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/