One document matched: draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Differences from draft-khuzema-ccamp-gmpls-signaling-g709-00.txt


 



CCAMP Working Group                                     Khuzema Pithewan
Internet-Draft                                                 Rajan Rao
Intended status: Proposed Standard                  Ashok Kunjidhapatham
Expires: September 15, 2011                                      Biao Lu
                                                             Mohit Misra
                                                                Infinera
                                                              Lyndon Ong
                                                                   Ciena
                                                          March 14, 2011

      Signaling Extensions for Generalized MPLS (GMPLS) Control of
                    G.709 Optical Transport Networks
            draft-khuzema-ccamp-gmpls-signaling-g709-01.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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2011 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. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
 


Khuzema, et al.        Expires September 15, 2011               [Page 1]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





   Abstract

   As OTN network capabilities continue to evolve, there is an increased
   need to support GMPLS control for the same. [RFC4328] introduced
   GMPLS signaling extensions for supporting early version of G.709
   [G.709-v1].The basic routing considerations from signaling
   perspective is also specified in [RFC4328].

   The recent revision of ITU-T Recommendation G.709 [G.709-v3] and
   [GSUP.43] have introduced new ODU containers (both fixed and
   flexible) and additional ODU multiplexing capabilities, enabling
   support for optimal service aggregation.

   This document extends [RFC4328] to provide GMPLS signaling support
   for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The
   signaling extensions described in this document caters to ODU layer
   switching only. Optical Channel Layer switching considerations in
   [RFC4328] are not modified in this document.























 


Khuzema, et al.        Expires September 15, 2011               [Page 2]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2. Conventions used in this document  . . . . . . . . . . . . . . . 5
   3. Overview of GMPLS Signaling Extensions required for the 
      Evolving OTN . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4. Extensions to G.709 Traffic Parameters . . . . . . . . . . . . . 6
      4.1. Usage of Bit_Rate and Tolerance for ODUflex Service . . . . 7
   5. New Generalized Label Format . . . . . . . . . . . . . . . . . . 8
      5.1 Multi-stage Label  . . . . . . . . . . . . . . . . . . . . . 8
      5.2. Label format for NVC or Multiplier > 1  . . . . . . . . .  10
   6. Usage of Multi-stage Label . . . . . . . . . . . . . . . . . .  10
   7. Label Distribution Rules . . . . . . . . . . . . . . . . . . .  12
   8. Interoperability Considerations  . . . . . . . . . . . . . . .  13
   9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
      12.1.  Normative References  . . . . . . . . . . . . . . . . .  16
      12.2.  Informative References  . . . . . . . . . . . . . . . .  17
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
   Appendix A:  Abbreviations & Terminology  . . . . . . . . . . . .  18
   Appendix B : RFC4328 and G.709v3  . . . . . . . . . . . . . . . .  20
























 


Khuzema, et al.        Expires September 15, 2011               [Page 3]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


1. Introduction

   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
   MPLS from supporting Packet Switching Capable (PSC) interfaces and
   switching to include support of four new classes of interfaces and 
   switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM),
   Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional
   description of the extensions to MPLS signaling that are needed to
   support these new classes of interfaces and switching is provided in
   [RFC3471].

   ITU-T Recommendations G.709 and G.872 provide specifications for OTN
   interface and network architecture respectively. As OTN network
   capabilities continue to evolve; there is an increased need to 
   support GMPLS control for the same.

   GMPLS signaling extensions to support [G.709-v1] OTN interfaces are
   specified in [RFC4328]. Further extensions are required to support
   the new capabilities introduced since [G.709-v1].  Following are the
   features added in OTN since the first version [G.709-v1].

   (a) OTU Containers:
       Pre-existing Containers: OTU1, OTU2 and OTU3
       New Containers introduced in [G.709-v3]: OTU2e and OTU4
       New Containers introduced in [GSUP.43]: OTU1e, OTU3e1 and OTU3e2

   (b) Fixed ODU Containers:
       Pre-existing Containers: ODU1, ODU2 and ODU3
       New Containers introduced in [G.709-v3]: ODU0, ODU2e and ODU4
       New Containers introduced in [GSUP.43]: ODU1e, ODU3e1 and ODU3e2

   (c) Flexible ODU Containers:
       ODUflex for CBR and GFP-F mapped services. ODUflex uses 'n'
       number of OPU Tributary Slots where 'n' is different from the
       number of OPU Tributary Slots used by the Fixed ODU Containers.

   (d) Tributary Slot Granularity:
       OPU2 and OPU3 support two Tributary Slot Granularities: (i)
       1.25Gbps and (ii) 2.5Gbps.

   (e) ODU Multiplexing Hierarchy:
       Multi-stage multiplexing of LO-ODUs into HO-ODU is supported.
       Also, multiplexing could be heterogeneous (meaning LO-ODUs of
       different rates can be multiplexed into the same HO-ODU). 

   OTN networks support switching at two layers: (i) ODU Layer - TDM
   Switching and (ii) OCH Layer - Lambda (LSC) Switching. The nodes on
   the network may support one or both the switching types. When
 


Khuzema, et al.        Expires September 15, 2011               [Page 4]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   multiple switching types are supported MLN based routing [RFC5339] is
   assumed.

   This document extends [RFC4328] to provide GMPLS signaling support
   for the new OTN capabilities defined in [G.709-v3] and [GSUP.43].
   This complies with the requirements outlined in the framework
   document [G.709-FRAME]. The signaling extensions described in this
   document caters to ODU layer switching only. Optical Channel Layer
   switching considerations in [RFC4328] are not modified in this
   document.

   Following are the extensions described in this document:

   (i) G.709 Traffic Parameters defined in [RFC4328] is extended to
   include Bit Rate (in bytes/second) and Tolerance (in ppm) fields for
   supporting ODUflex service.

   (ii) New Generalized Label Format is introduced to provide compact
   encoding of Tributary Slot information and support multi-stage ODU
   multiplexing.

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 is to be interpreted as described in RFC-2119 [RFC2119].

   In addition, the reader is assumed to be familiar with the
   terminology used in ITU-T [G.709-v3], [G.872] and [GSUP.43], as well
   as [RFC4201] and [RFC4203].

3. Overview of GMPLS Signaling Extensions required for the Evolving OTN

   The GMPLS signaling extensions introduced in [RFC4328] cover OTN
   switching requirement pertaining to [G.709-v1].  The signaling
   objects defined in [RFC4328] need to be further extended to cover the
   new capabilities added to OTN since the first version of G.709
   [G.709-v1]. A brief overview of the extensions required are captured
   below:

   (a) Support for the new ODU containers

   The new ODU containers added since [G.709-v1] are listed in the
   section-1. SignalType attribute defined in [RFC4328] need to be
   extended to cover the new signal types. This is captured in [OSPF-
   EXTN-FOR-OTN].

   (b) Support for ODUflex
 


Khuzema, et al.        Expires September 15, 2011               [Page 5]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   Unlike the other ODUj signal types, ODUflex requires an user
   specified bit-rate (together with a Tolerance value) to be mapped to
   'n' TSs of an higher-order container. Even within the same Tributary
   Slot Granularity, the Tributary Slot size varies among the ODU
   container of different rate. This results in ODUflex service of
   certain bit-rate and tolerance requiring different number of TSs on
   different higher order ODU containers. The present way of specifying
   bandwidth requirement (via NMC field in G.709 Traffic Parameters)
   will not work for ODUflex. G.709 Traffic Parameters object need to be
   extended to include Bit-Rate (in bytes/sec) and Tolerance (in ppm)
   fields as well.

   (c) Support for ODU multiplexing hierarchy

   The G.709 Traffic Parameter and Generalized Label Format defined in
   [RFC4328] supports single stage multiplexing only. A new Generalized
   Label Format need to be introduced to support specification of multi-
   stage label.

           ODUk-------------------ODUj-------------------ODUh
                TS/TPN for stage-1     TS/TPN for stage-2

                      Figure-1: Multi-stage Label

   (d) Support for different OPU Tributary Slot Granularities

   The G.709 Traffic Parameters and Generalized Label Format defined in
   [RFC4328] supports 2.5Gbps Tributary Slot Granularity only. With
   [G.709-v3], two types of tributary slots are supported - viz.,
   1.25Gbps and 2.5Gbps. The Generalized Label Format need to be
   equipped with Tributary Slot Type indicator to facilitate
   interpretation of the encoded TS information.

   (e) Exchange of Tributary Port Number

   A Tributary Port Number (TPN) in MSI field of OPU-OH is used to
   correlate the TSs used for mapping a LO-ODU on a HO-ODU. This needs
   to be exchanged along with the Label such that each neighbor on a
   span knows the TPN value to expect for a given ODUj mapping. This
   applies to each stage associated with a multi-stage label. The
   Generalized Label Format needs to be extended to include TPN value
   for each stage of multiplexing.

4. Extensions to G.709 Traffic Parameters

   G.709 Traffic Parameters defined in [RFC4328] is extended to include
   additional fields in support of ODUflex service as explained in the
   previous section. The modified object format is captured below:
 


Khuzema, et al.        Expires September 15, 2011               [Page 6]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Signal Type  |   Reserved    |           NMC/Tolerance       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              NVC              |        Multiplier (MT)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Bit_Rate                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Signal Type

   As explained in the previous section, Signal Type attribute needs to
   be extended to cover the new ODU containers defined in more recent
   G.709 specification [G.709-v3].

         Value     Type
         -----     ----
           4       ODU4 (100Gbps)
           5       ODU0 (1.25Gbps)
           10      ODUflex
           11      ODU1e (10Gbps Ethernet [GSUP.43])
           12      ODU2e (10Gbps Ethernet)
           13      ODU3e1 (40Gbps Ethernet [GSUP.43])
           14      ODU3e2 (40Gbps Ethernet [GSUP.43])
           15-255  Reserved (for future)

   NMC/Tolerance

   This field is redefined from the original definition in [RFC4328].
   NMC field defined in [RFC4328] can not be fixed value for an end-to-
   end circuit involving dissimilar OTN link types. For example, ODU2e
   requires 9 TS on ODU3 and 8 TS on ODU4. Usage of NMC field is
   deprecated and should be used only with [RFC4328] generalized label
   format for backwards compatibility reasons.

   For the new generalized label format as defined in this document this
   field is interpreted as Tolerance. The unit of tolerance is ppm and
   is encoded as unsigned integer. For signal types other than ODUflex,
   Tolerance field should be coded as 0.

   Bit_Rate

   Bit_Rate is used when signal Type is ODUFlex. For all the other
   signal types, this field should be coded as zero.

4.1. Usage of Bit_Rate and Tolerance for ODUflex Service

 


Khuzema, et al.        Expires September 15, 2011               [Page 7]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   Bit_Rate and Tolerance are used together to compute number of
   Tributary slots required for ODUFlex(CBR) traffic on a given higher
   order ODU container. The computation of Number of Tributary Slot (n)
   is as follows.

                  Ceiling of Bit_Rate * (1 + Tolerance)
     n =    --------------------------------------------------
          ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)

5. New Generalized Label Format

   As explained in section 3, the Generalized Label format defined in
   [RFC4328] can not accommodate the new features added in [G.709v3].
   Further the label format as defined in [RFC4328] is not scalable for
   large number of Tributary Slots (at 1.25G granularity) associated
   with bigger containers such as ODU3 and ODU4.

   The Generalized Label for G.709 may contain one or more multi-stage
   Label.

5.1 Multi-stage Label

   A multi-stage label includes TS and TPN information for all the
   stages of a multi-stage multiplexing hierarchy.

   The format of a multi-stage label is explained below.
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num MUX Stages|  OD(T)Uk (ST) |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-1)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              . . .                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-n)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Num MUX Stages

   This field indicates the number of multiplexing stages specified by
   the label.

   OD(T)Uk

   This field encodes the signal type of HO OD(T)Uk container.
 


Khuzema, et al.        Expires September 15, 2011               [Page 8]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   Tributary Slot Info

   Tributary Slot Information for a single stage is encoded as follows.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ODUj (ST)  | T |  Length   |      Tributary Port Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Variable Length Bit Map (4-byte boundary aligned)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ODUj

   This field indicates the signal type of a LO-ODU being multiplexed
   into its immediate HO-ODU.

   T

   This is a 2 bit field, which defines the granularity of tributary
   slots for this multiplexing stage. It can take following values

      T field      TS Granularity type
      -------      -------------------
        0          1.25Gbps
        1          2.5Gbps
        2-3        Reserved (for future use)



   Length

   This field indicates the number of valid Bits in the of Bit Map
   excluding the filler bits.

   Tributary Port Number(TPN)

   This field is encoded with TPN value assigned for a ODTUjk or
   ODTUk.ts on a OPUk. TPN assignment could be fixed or flexible. 

   For fixed TPN assignment scheme, TPN value need not be specified. In
   this case, TPN value should be coded as 0xFFFFFFFF.

   For flexible TPN assignment scheme, TPN value should contain the
   assigned logical value. Not all the bits of TPN are used. Only a
   subset of bits are used depending on the ODTU type. 

   Bit Map
 


Khuzema, et al.        Expires September 15, 2011               [Page 9]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   This is a multi-byte bit map field. The length of this field varies
   depending on the number of TSs associated with the immediate HO-ODU
   pertaining to the stage. Each bit represents one TS. Bit values are
   interpreted as follows

         Bit Value      Meaning
         ---------      -------
            0            Not Used
            1            Used

   This field must be 4 byte aligned using filler bytes.


5.2. Label format for NVC or Multiplier > 1

   For NVC or Multiplier field value > 1, the label format defined in
   section 5 needs to be repeated NVC/multiplier times.

    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 Instance #1                        |
   |                      (Variable Length)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Label Instance #n                        |
   |                     (n = NVC/Multiplier)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Usage of Multi-stage Label 

   Multi-stage Label is needed when switching of an ODU Layer requires
   termination of more than one HO-ODUs on a given OTU/ODU Link. This
   eliminates the need for creating FA TE-Links whose span matches its
   parent TE-Link.

   Example-1:

   Assume on an OTU3 Link, a restrictive MUX hierarchy (as shown in
   figure below) is supported on the associated interfaces. In order to
   switch ODU1 on this Link, ODU3 and ODU2 need to be terminated on the
   same span as the OTU3 link. If multi-stage Label is not supported, FA
   TELinks need to be created for ODU3 and ODU2 layers (or just ODU2
   layer at the minimum) inorder to support ODU1 LSP. Creation of ODU3
   and ODU2 FA LSPs/TELinks on top of OTU3 Link on the same span is not
   really required as bandwidth management for all ODU layers can still
   be managed on the OTU3 Link itself. 

 


Khuzema, et al.        Expires September 15, 2011              [Page 10]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   Multi-stage Label helps in implicit creation of ODU3 and ODU2 layers
   as part of ODU1 LSP setup and thus eliminates the need for the
   creation of the FA LSPs/TELinks. 

                                 ODU0
                                  |
                                 ODU1  ODU0
                                   \    /
                                    ODU2  
                                     |
             ----------             ODU3            ----------
             |        |              |              |        |
             |  Node  |             OTU3            |  Node  |
             |        |-----------------------------|        |
             |   A    |                             |    B   |
             |        |                             |        |
             ----------                             ----------
                       |<----- OTU3 TE-Link ------->|

             Label Format:  
                 Stage-1: ODU3<-ODU2/TPN/Trib Slots
                 Stage-2: ODU2<-ODU1/TPN/Trib Slots

                Figure-2: Multi-stage Label on OTUk Link
   Example-2:

   Assume on an ODU3 FA LSP/TE-Link (B-C-D), signaling of ODU1 LSP
   requires termination of ODU2. Multi-stage Label helps in implicit
   creation of ODU2 layer as part of ODU1 LSP setup (A-B-D-E). 

                       ODU1              ODU1
                        |                 |
                       ODU2              ODU2
                        |                 |
                       ODU3              ODU3
                        |                 |
                       OTU3              OTU3
                       /                   \ 
   ------        -----/        ------       \------        ------
   |    |        |    |        |    |        |    |        |    |
   |Node|        |Node|        |Node|        |Node|        |Node|
   |    |--------|    |--------|    |--------|    |--------|    |
   |  A |        |  B |        |  C |        |  D |        |  E |
   |    |        |    |        |    |        |    |        |    |
   ------        ------        ------        ------        ------
        |<-OTU2->|    |<-OTU3->|    |<-OTU3->|    |<-OTU2->|
                      |                      |
                      |<-ODU3 FA LSP/TELink->|
 


Khuzema, et al.        Expires September 15, 2011              [Page 11]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


             Figure-3: Multi-stage Label on ODUk Link


   Note: Multi-stage Label is NOT intended to facilitate the creation of
   FA-LSP or Hierarchical LSP. It is basically used to eliminate the
   need for FA-LSP in some obvious scenarios. 


7. Label Distribution Rules

   This document does not change the existing label distribution
   procedures defined in [RFC4328] except that the new ODU label should
   be processed as follows.

   A. Sending Side

   When Generalized Label Request is received on given node for setting
   up an ODU LSP from its upstream neighbor, it reserves the bandwidth
   required for the ODU Layer being switched and also the terminating
   HO-ODUs layers involved. It sends upstream label and suggested label
   (if applicable) to the downstream node and downstream label via PATH
   Message and downstream label to the upstream node via RESV Message. 

   Note that Label can also be explicitly specified by source node.

   The encoding of Generalized Label is as follows:

   Case-1: ODUk mapping into OTUk
   Number of MUX stages = 0
   Tributary Slot information is not included. 

   Case-2: ODUj mux into ODUk
   Number of MUX Stages = 1. 
   Stage-1: Length = <number of TSs on ODUk>. 
            TPN = <specified as per Section 5>
            TS BitMap = <TSs reserved for ODUj are set to 1>

   Case-3 ODUh mux into ODUj into ODUk 
   Number of MUX Stages = 2. 
   Stage-1: Length = <number of TSs on ODUk>. 
            TPN = <specified as per Section 5>
            TS BitMap = <TSs reserved for ODUj are set to 1>
   Stage-2: Length = <number of TSs on ODUj>. 
            TPN = <specified as per Section 5>
            TS BitMap = <TSs reserved for ODUh are set to 1>

   B. Receiving Side

 


Khuzema, et al.        Expires September 15, 2011              [Page 12]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   The decoding of the Generalized Label is as follows:

   Case-1: ODUk mapping into OTUk
   For ODUk to OTUk mapping, the Tributary Slot Information is not
   expected.

   Case-2: ODUj mux into ODUk
   For ODUj to ODUk multiplexing, one MUX stage Label is expected. The
   node extracts the Bit Map field in Tributary Slot Info using the
   Length field. The position of Bit in the Bitmap interpreted as the
   Tributary Slot Number. The value stored in the bit indicates if it is
   reserved for the ODUj.

   Case-3: ODUh mux into ODUj into ODUk
   For ODUh mux into ODUj into ODUk, two MUX stage Label is expected.
   Each stage is further decoded as explained in case-2 above. 

8. Interoperability Considerations

   The neighbor nodes on a TE-Link span should exchange the signaling
   stack versions (via some link discovery mechanism) in order to
   determine the Generalized Label Format to use.  

   In the following example, Switch B and C are running the newer
   version of signaling stack (that support the new G.709 Traffic
   Parameters and Generalized Label Format) while Switch A is running
   the older version. 

      +-------+               +-------+               +-------+ 
      | OTN   |               |  OTN  |               |  OTN  |
      |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
      |   A   |               |   B   |               |   C   |
      +-------+               +-------+               +-------+

              |<-- Legacy -->|       |<-- New TE-Link -->|

                        Figure-4: OTUk TE-Link

   Link A-B: G.709-v1 version (2001) based OTUk link
   TSG: 2.5G;
   Label format: as per RFC 4328

   Link B-C: G.709-v3 version based OTUk link (12/09)
   TSG: 1.25G;
   Label format: new label format proposed in this draft. 

   For an ODU2 connection going from A-C,
   On link A-B :  NMC is set to 4 & [RFC4328] label format is used. 
 


Khuzema, et al.        Expires September 15, 2011              [Page 13]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   On link B-C :  NMC is not used & new label format is used. 

9. Examples

   Example-1 : ODUj LSP over OTUk Links

   Consider the network topology shown in the Figure-5 below:

   +-----+             +-----+             +-----+             +-----+
   | OTN |             | OTN |             | OTN |             | OTN |
   | SW  |<-OTU2 Link->| SW  |<-OTU3 Link->| SW  |<-OTU2 Link->| SW  |
   |  A  |             |  B  |             |  C  |             |  D  |
   +-----+             +-----+             +-----+             +-----+

                    Figure-5: OTN Signaling Example

   Assumptions:

   (1) ODU2 links between OTN-Switches A & B and C & D support 1.25Gbps
   TS Granularity. 

   (2) ODU3 link between OTN-Switches B & C supports TS Granularity of
   2.5Gbps only. Hence, ODU0 switching on this link is possible only
   through ODU3-ODU2-ODU0 or ODU3-ODU1-ODU0 multiplexing hierarchies. 

   G.709 Traffic Parameters and Generalized Label for ODU0 LSP from node
   A to D is captured below:

   A. G.709 Traffic Parameters 
     Signal Type = ODU0
     NMC/Tolerance = 0    // NMC is not used. 
     NVC = 0
     Multiplier (MT) = 1
     Bit_Rate = 0














 


Khuzema, et al.        Expires September 15, 2011              [Page 14]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


     B. Generalized Label Format:
          +=============+==============+==============+==============+
          |             |    A to B    |    B to C    |     C to D   |           
          +=============+==============+==============+==============+
          | # of Stages |       1      |       2      |       1      |           
          +-------------+--------------+--------------+--------------+
          |   Stage-1   | ODU2<--ODU0  | ODU3<--ODU2  | ODU2<--ODU0  |
          |             | TSG = 1.25G  | TSG = 2.5G   | TSG = 1.25G  |
          |             | #TSs =  8    | #TSs = 16    | #TSs = 8     |
          |             | TPN = <1..8> | TPN = <1..4> | TPN = <1..8> |
          |             | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes| 
          +-------------+--------------+--------------+--------------+
          |   Stage-2   |     N/A      | ODU2<--ODU0  |     N/A      |
          |             |              | TSG = 1.25G  |              |
          |             |              | #TSs = 8     |              |
          |             |              | TPN = <1..8> |              |
          |             |              | BMap = 4bytes|              |
          +-------------+--------------+--------------+--------------+
  Example 2: ODUj LSP over ODUk FA-LSP/TE-Link

  Refer to Figure-3 in section 6. The G.709 Traffic Parameters and
  Generalized Label for ODU1 LSP from Node A to E is captured below:

     A. G.709 Traffic Parameters: 
          Signal Type = ODU1
          NMC/Tolerance = 0    // NMC is not used. 
          NVC = 0
          Multiplier (MT) = 1
          Bit_Rate = 0
     B. Generalized Label Format:
          +=============+==============+==============+==============+
          |             |    A to B    |    B to D    |     D to E   |           
          +=============+==============+==============+==============+
          | # of Stages |       1      |       2      |       1      |           
          +-------------+--------------+--------------+--------------+
          |   Stage-1   | ODU2<--ODU1  | ODU3<--ODU2  | ODU2<--ODU1  |
          |             | TSG = 1.25G  | TSG = 2.5G   | TSG = 1.25G  |
          |             | #TSs =  8    | #TSs = 16    | #TSs = 8     |
          |             | TPN = <1..4> | TPN = <1..4> | TPN = <1..4> |
          |             | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes| 
          +-------------+--------------+--------------+--------------+
          |   Stage-2   |     N/A      | ODU2<--ODU1  |     N/A      |
          |             |              | TSG = 1.25G  |              |
          |             |              | #TSs = 8     |              |
          |             |              | TPN = <1..4> |              |
          |             |              | BMap = 4bytes|              |
          +-------------+--------------+--------------+--------------+

 


Khuzema, et al.        Expires September 15, 2011              [Page 15]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


10. Security Considerations

          There are no additional security implications to Signaling
          protocol due to the extensions captured in this document.

11. IANA Considerations

          TBD

12.  References

12.1.  Normative References

      [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
                Requirement Levels". 

      [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 
                (TE) Extensions to OSPF Version 2", RFC 3630  

      [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Functional Description", RFC 3471,
                January 2003.

      [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 
                MPLS Traffic Engineering (TE)" 

      [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of 
                Generalized Multi-Protocol Label Switching (GMPLS)" 

      [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 
                4204, October 2005. 

      [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Extensions for G.709 Optical
                Transport Networks Control", RFC 4328, January 2006.

      [RFC5339]  Le Roux, JL. and D. Papadimitriou, "Evaluation of
                 Existing GMPLS Protocols against Multi-Layer and
                 Multi-Region Networks (MLN/MRN)", RFC 5339, September
                 2008.

      [VCAT-LCAS] G. Bernstein (ed.), D. Caviglia, R. Rabbat and H. van
                  Helvoort, "Operating Virtual Concatenation (VCAT) and
                  the Link Capacity Adjustment Scheme (LCAS) with
                  Generalized Multi-Protocol Label Switching (GMPLS)",
                  draft-bernstein-ccamp-gmpls-vcat-lcas-11.txt, 
                  March 09, 2011 

 


Khuzema, et al.        Expires September 15, 2011              [Page 16]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


      [G.709-v3] ITU-T, "Interfaces for the Optical Transport Network 
                 (OTN)", G.709 Recommendation, December 2009. 

12.2.  Informative References

      [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
                (GMPLS) Architecture", RFC 3945, October 2004.

      [G.709-v1] ITU-T, "Interface for the Optical Transport Network
                 (OTN)," G.709 Recommendation (and Amendment 1), February
                 2001 (October 2001).

      [G.872] ITU-T, "Architecture of optical transport networks", 
              November 2001 (11 2001). 

      [G.709-FRAME] F. Zhang, D. Li, H. Li, S. Belotti, "Framework for 
                    GMPLS and PCE Control of  G.709 Optical Transport 
                    Networks", draft-zhang-ccamp-gmpls-g709-framework-02, 
                    work in progress. 

      [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 
                   and PCE Control of Wavelength Switched Optical Networks 
                   (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in 
                   progress.  

      [OSPF-EXTN-FOR-OTN] S. Bardalai, R. Rao, A. Kunjidhapatham, 
                          K. Pithewan,  "OSPF TE Extensions for GMPLS
                          Control of G.709 Optical Transport Networks", 
                          draft-ashok-ccamp-gmpls-ospf-g709-02,
                          work in progress.


13. Acknowledgements

   Authors would like to thank Lou Berger, Steve Balls and Radhakrishna
   Valiveti for review comments and suggestions.

Author's Addresses

      Khuzema Pithewan
      Infinera Corporation
      169, Java Drive
      Sunnyvale, CA-94089,  USA
      Email: kpithewan@infinera.com

      Mohit Misra
      Infinera Corporation
      169, Java Drive
 


Khuzema, et al.        Expires September 15, 2011              [Page 17]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


      Sunnyvale, CA-94089, USA
      Email: mmisra@infinera.com

      Rajan Rao
      Infinera Corporation
      169, Java Drive
      Sunnyvale, CA-94089, USA
      Email: rrao@infinera.com

      Ashok Kunjidhapatham
      Infinera Corporation
      169, Java Drive
      Sunnyvale, CA-94089, USA
      Email: akunjidhapatham@infinera.com

      Biao Lu
      Infinera Corporation
      169, Java Drive
      Sunnyvale, CA-94089, USA
      Email: blu@infinera.com

      Lyndon Ong
      Ciena
      10480 Ridgeview Court
      Cupertino, CA 95014, USA
      EMail: lyong@ciena.com



Appendix A:  Abbreviations & Terminology

   A.1 Abbreviations:
         CBR          Constant Bit Rate
         GFP          Generic Framing Procedure
         HO-ODU       Higher Order ODU
         LSC          Lambda Switch Capable
         LSP          Label Switched Path
         LO-ODU       Lower Order ODU
         ISCD         Interface Switch Capability Descriptor 
         OCC          Optical Channel Carrier
         OCG          Optical Carrier Group
         OCh          Optical Channel (with full functionality)
         OChr         Optical Channel (with reduced functionality)
         ODTUG        Optical Date Tributary Unit Group
         ODU          Optical Channel Data Unit
         OMS          Optical Multiplex Section
         OMU          Optical Multiplex Unit
         OPS          Optical Physical Section
 


Khuzema, et al.        Expires September 15, 2011              [Page 18]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


         OPU          Optical Channel Payload Unit
         OSC          Optical Supervisory Channel
         OTH          Optical Transport Hierarchy
         OTM          Optical Transport Module
         OTN          Optical Transport Network
         OTS          Optical Transmission Section
         OTU          Optical Channel Transport Unit
         OTUkV        Functionally Standardized OTUk
         SCSI         Switch Capability Specific Information 
         TDM          Time Division Multiplex
         TPN          Tributary Port Number
         TS           Tributary Slot or Time Slot 

   A.2 Terminology

   1. ODUk and ODUj

   ODUk refers to the ODU container that is directly mapped to an OTU
   container. ODUj refers to the lower order ODU container that is
   mapped to an higher order ODU container via multiplexing. 

   2. LO-ODU and HO-ODU

   LO-ODU refers to the ODU client layer of lower rate that is mapped to
   an ODU server layer of higher rate via multiplexing. HO-ODU refers to
   the ODU server layer of higher rate that supports mapping of one or
   more ODU client layers of lower rate. 

   In multi-stage multiplexing case, a given ODU layer can be a client
   for one stage (interpreted as LO-ODU) and at the same time server for
   another stage (interpreted as HO-ODU). In this case, the notion of
   LO-ODU and HO-ODU needs to be interpreted in a recursive manner. 

                              ODU3   | (HO-ODU)
                                ^    |           
                                |    | Stage #1  
                                |    |
                  (HO-ODU) |  ODU2   | (LO-ODU)
                           |    ^
                  Stage #2 |    |
                           |    |
                  (LO-ODU) |  ODU1   | (HO-ODU)
                                ^    |
                                |    | Stage #3
                                |    |
                              ODU0   | (LO-ODU)

                     Figure-6 : LO-ODU and HO-ODU
 


Khuzema, et al.        Expires September 15, 2011              [Page 19]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   3. Single Stage Multiplexing 

   When ODU multiplexing hierarchy involves only two levels (ODUk and
   ODUj), it is referred as single stage multiplexing. 


                              ODU3    | Level-1
                                ^     |
                                |     |
                                |     |
                              ODU1    | Level-2

                   Figure-7: Single Stage Multiplexing

   4. Multi Stage Multiplexing 

   When ODU multiplexing hierarchy involves more than two levels, it is
   referred as multi-stage multiplexing. Two adjoining levels form a
   multiplexing stage. 

                              ODU3   | Level-1
                                ^    |           
                                |    | Stage #1  
                                |    |
                   Level-2 |  ODU2   | Level-2
                           |    ^
                  Stage #2 |    |
                           |    |
                   Level-3 |  ODU1   | Level-3
                                ^    |
                                |    | Stage #3
                                |    |
                              ODU0   | Level-4

                     Figure-8 : Multi Stage Multiplexing

Appendix B : RFC4328 and G.709v3

   B.1 G.709 Traffic Parameters

   The G.709 Traffic Parameters defined in [RFC4328] does not work well
   for the new features introduced in [G.709-v3]. The basic draw-backs
   are:

   (a) NMC attribute defined in G.709 Traffic Parameters does not apply
   end-to-end especially when links with different TSG are involved in
   the path of a LSP. 

 


Khuzema, et al.        Expires September 15, 2011              [Page 20]

Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-01.txt  March 14, 2011


   (b) ODUflex needs absolute nominal rate and tolerance to be
   specified.

   B.2 Label Format

   The Label format defined in [RFC4328] is not scalable/extensible to
   cover the new ODU rates defined in [G.709-v3]. Some of the
   limitations are captured below:

   (a) The bit-fields defined to represent TSs for specific ODU rates
   are not future proof. The reserved bits are not sufficient to cover
   the future ODU types. 

   (b) The label format assumes 2.5G Tributary Slot Granularity. It
   needs to be redefined for 1.25G Tributary Slot Granularity. 

   (c) One Tributary Slot information is coded in 4 bytes. ODU3 and ODU4
   requires 32 and 80 TSs respectively. This would dramatically increase
   the label size and thus impact the scalability.  
































Khuzema, et al.        Expires September 15, 2011              [Page 21]

PAFTECH AB 2003-20262026-04-24 09:11:07