[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/