Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-09

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (ccamp WG)
Author Dimitri Papadimitriou 
Last updated 2013-03-02 (latest revision 2005-01-17)
Stream Internet Engineering Task Force (IETF)
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4328 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Alex Zinin
Send notices to kireeti@juniper.net, adrian@olddog.co.uk
CCAMP Working Group                           D. Papadimitriou - Editor 
Internet Draft                                                (Alcatel) 
Updates RFC 3471                                                        
Category: Standard Track                                                
Expiration Date: June 2005                                 January 2005 
    
    
 
             Generalized MPLS (GMPLS) Signaling Extensions 
              for G.709 Optical Transport Networks Control 
                                     
                   draft-ietf-ccamp-gmpls-g709-09.txt 
    
    
    
Status of this Memo 
 
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668. 
    
   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. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2004). All Rights Reserved. 
 
 
Abstract 
    
   This document is a companion to the Generalized MPLS (GMPLS) 
   signaling documents. It describes the technology specific 
   information needed to extend GMPLS signaling to control Optical 
   Transport Networks (OTN); it also includes the so-called pre-OTN 
   developments.  
 
    
    
    
    
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  1 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
Table of Contents 
    
   Status of this Memo ............................................. 1 
   Abstract ........................................................ 1 
   Table of Contents ............................................... 2 
   Conventions used in this Document ............................... 2 
   1. Introduction ................................................. 3 
   2. GMPLS Extensions for G.709 - Overview ........................ 3 
   3. Generalized Label Request .................................... 5 
   3.1 Common Part ................................................. 5 
   3.1.1. LSP Encoding Type ........................................ 5 
   3.1.2. Switching-Type ........................................... 6 
   3.1.3. Generalized-PID (G-PID) .................................. 6 
   3.2. G.709 Traffic-Parameters ................................... 7 
   3.2.1. Signal Type (ST).......................................... 8 
   3.2.2. Number of Multiplexed Components (NMC) ................... 9 
   3.2.3. Number of Virtual Components (NVC) ....................... 9 
   3.2.4. Multiplier (MT) .......................................... 9 
   3.2.5. Reserved Fields ......................................... 10 
   4. Generalized Label ........................................... 10 
   4.1. ODUk Label Space .......................................... 10 
   4.2. Label Distribution Rules .................................. 12 
   4.3. OCh Label Space ........................................... 13 
   5. Examples .................................................... 13 
   6. RSVP-TE Signaling Protocol Extensions ....................... 15 
   7. Security Considerations ..................................... 15 
   8. IANA Considerations ......................................... 15 
   9. Acknowledgments ............................................. 16 
   10. References ................................................. 17 
   10.1 Normative References ...................................... 17 
   10.2 Informative References .................................... 17 
   11. Contributors ............................................... 18 
   12. Editor's Address ........................................... 19 
   Appendix 1 - Abbreviations ..................................... 20 
   Appendix 2 - G.709 Indexes ..................................... 20 
   Intellectual Property Statement ................................ 22 
   Disclaimer of Validity ......................................... 22 
   Copyright Statement ............................................ 22 
    
    
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. 
    
   In addition, the reader is assumed to be familiar with the 
   terminology used in ITU-T [ITUT-G709] as well as [RFC3471], and 
   [RFC3473]. Abbreviations used in this document are detailed in 
   Appendix 1. 
 
 
 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  2 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
1. Introduction 
    
   Generalized MPLS (GMPLS) 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 needed to support these new 
   classes of interfaces and switching is provided in [RFC3471]. 
   [RFC3473] describes the RSVP-TE specific formats and mechanisms 
   needed to support all four classes of interfaces.  
    
   This document presents the technology details that are specific to 
   G.709 Optical Transport Networks (OTN) as specified in the ITU-T 
   G.709 recommendation [ITUT-G709] (and referenced documents), 
   including pre-OTN developments. Per [RFC3471], G.709 technology 
   specific parameters are carried through the signaling protocol in 
   dedicated traffic parameter objects.  
    
   The G.709 traffic parameters defined hereafter (see Section 3.2) 
   MUST be used when the label is encoded as defined in this 
   document. Moreover, the label MUST be encoded as defined in 
   Section 4 when these G.709 traffic parameters are used. 
 
   In the context of this memo, by pre-OTN developments, one refers 
   to Optical Channel, Digital Wrapper and Forward Error Correction 
   (FEC) solutions that are not fully G.709 compliant. Details 
   concerning pre-OTN Synchronous Optical Network (SONET)/ 
   Synchronous Digital Hierarchy (SDH) based solutions including 
   Optical Sections (OS), Regenerator Section (RS)/Section and 
   Multiplex Section (MS)/ Line overhead transparency are covered in 
   [RFC3946]. 
    
   *** Note on ITU-T G.709 Recommendation *** 
    
   The views on the ITU-T G.709 OTN Recommendation presented in this 
   document are intentionally restricted to the GMPLS perspective 
   within the IETF CCAMP WG context. Hence, the objective of this 
   document is not to replicate the content of the ITU-T OTN 
   recommendations. Therefore, the reader interested in more details 
   concerning the corresponding technologies is strongly invited to 
   consult the corresponding ITU-T documents (also referenced in this 
   memo). 
    
2. GMPLS Extensions for G.709 - Overview 
    
   [ITUT-G.709] defines several networking layers constituting the 
   optical transport hierarchy: 
      - with full functionality: 
        . Optical Transmission Section (OTS) 
        . Optical Multiplex Section (OMS)  
        . Optical Channel (OCh) 
      - with reduced functionality: 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  3 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
        . Optical Physical Section (OPS) 
        . Optical Channel with reduced functionality (OChr)  
    
   It also defines two layers constituting the digital transport 
   hierarchy: 
      - Optical Channel Data Unit (OTUk) 
      - Optical Channel Data Unit (ODUk)  
    
   However, only the OCh and the ODUk layers are defined as switching 
   layers. Both OCh (but not OChr) and ODUk layers include the overhead 
   for supervision and management. The OCh overhead is transported in a 
   non-associated manner (also referred to as the non-associated 
   overhead naOH) in the Optical Transport Module (OTM) Overhead Signal 
   (OOS), together with the OTS and OMS non-associated overhead. The 
   OOS is transported via a dedicated wavelength referred to as the 
   Optical Supervisory Channel (OSC). It should be noticed that the 
   naOH is only functionally specified and as such open to vendor 
   specific solutions. The ODUk overhead is transported in an 
   associated manner as part of the digital ODUk frame. 
    
   As described in [ITUT-G709], in addition to the support of ODUk 
   mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. 
   It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > 
   j) signal, in particular:  
      - ODU1 into ODU2 multiplexing   
      - ODU1 into ODU3 multiplexing 
      - ODU2 into ODU3 multiplexing 
      - ODU1 and ODU2 into ODU3 multiplexing 
 
   Adapting GMPLS to control G.709 OTN, can be achieved by creating: 
      - a Digital Path layer by extending the previously defined  
        "Digital Wrapper" in [RFC3471] corresponding to the ODUk    
        (digital) path layer.  
      - an Optical Path layer by extending the "Lambda" concept defined    
        in [RFC3471] to the OCh (optical) path layer.  
      - a label space structure by considering a tree whose root is an  
        OTUk signal and leaves the ODUj signals (k >= j); enabling to  
        identify the exact position of a particular ODUj signal in an  
        ODUk multiplexing structure.  
 
   Thus, the GMPLS signaling extensions for G.709 need to cover the 
   Generalized Label Request, the Generalized Label as well as the 
   specific technology dependent objects included in the so-called 
   traffic parameters as specified in [RFC3946] for SONET/SDH networks. 
   Moreover, since multiplexing in the digital domain (such as ODUk 
   multiplexing) has been specified in the amended version of the G.709 
   ITU-T recommendation (October 2001), this document also proposes a 
   label space definition suitable for that purpose. Notice also that 
   one uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e. Optical 
   Path) layers directly in order to define the corresponding label 
   spaces. 
    
    
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  4 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
3. Generalized Label Request 
    
   The Generalized Label Request as defined in [RFC3471], includes a 
   common part (i.e. used for any switching technology) and a 
   technology dependent part (i.e. the traffic parameters). In this 
   section, both parts are extended to accommodate GMPLS Signaling to 
   the G.709 transport plane recommendation (see [ITUT-G709]). 
    
3.1 Common Part  
    
   As defined in [RFC3471], the LSP Encoding Type, the Switching Type 
   and the Generalized Protocol Identifier (Generalized-PID) constitute 
   the common part of the Generalized Label Request. The encoding of 
   the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in 
   [RFC3473] Section 2.1. 
 
   As mentioned above, this document extends the LSP Encoding Type, the 
   Switching Type and G-PID (Generalized-PID) values to accommodate 
   G.709 Recommendation [ITUT-G709]. 
    
3.1.1 LSP Encoding Type 
    
   Since G.709 Recommendation defines two networking layers (ODUk 
   layers and OCh layer), the LSP Encoding Type code-points can reflect 
   these two layers defined in [RFC3471] Section 3.1 as "Digital 
   Wrapper" and "Lambda" code. The LSP Encoding Type is specified per 
   networking layer or more precisely per group of functional 
   networking layer: the ODUk layers and the OCh layer.  
    
   Therefore, an additional LSP Encoding Type code-point for the G.709 
   Digital Path layer is defined that enlarges the existing "Digital 
   Wrapper" code-point defined in [RFC3471]. The former MUST be 
   generated when the interface or tunnel on which the traffic will be 
   transmitted supports G.709 compliant Digital Path layer encoding. 
   The latter MUST only be used for non-G.709 compliant Digital Wrapper 
   layer(s) encoding. A transit or an egress node (receiving a Path 
   message containing a GENERALIZED_LABEL_REQUEST object) MUST generate 
   a PathErr message, with a "Routing problem/Unsupported Encoding" 
   indication, if the requested LSP Encoding Type cannot be supported 
   on the corresponding incoming interface. 
    
   In the same way, an additional LSP Encoding Type code-point for the 
   G.709 Optical Channel layer is defined that enlarges the existing 
   "Lambda" code-point defined in [RFC3471]. The former MUST be 
   generated when the interface or tunnel on which the traffic will be 
   transmitted supports G.709 compliant Optical Channel layer encoding. 
   The latter MUST only be used for non-G.709 compliant Lambda layer(s) 
   encoding. A transit or an egress node (receiving a Path message 
   containing a GENERALIZED_LABEL_REQUEST object) MUST generate a 
   PathErr message, with a "Routing problem/Unsupported Encoding" 
   indication, if the requested LSP Encoding Type cannot be supported 
   on the corresponding incoming interface. 
    
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  5 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   Consequently, the following additional code-points for the LSP 
   Encoding Type are defined: 
    
        Value           Type 
        -----           ---- 
        12             G.709 ODUk (Digital Path)        
        13             G.709 Optical Channel 
     
   Moreover, the code-point for the G.709 Optical Channel (OCh) layer 
   will indicate the requested capability of an end-system to use the 
   G.709 non-associated overhead (naOH) i.e. the OTM Overhead Signal 
   (OOS) multiplexed into the OTM-n.m interface signal. 
    
3.1.2 Switching Type 
    
   The Switching Type indicates the type of switching that should be 
   performed at the termination of a particular link (see [GMPLS-RTG]).  
    
   No additional Switching Type values are to be considered in order to 
   accommodate G.709 switching types since an ODUk switching (and so 
   LSPs) belongs to the TDM class while an OCh switching (and so LSPs) 
   to the Lambda class (i.e. LSC).  
    
   Intermediate and egress nodes MUST verify that the value indicated 
   in the Switching Type field is supported on the corresponding 
   incoming interface. If the requested value can not be supported, the 
   node MUST generate a PathErr message with a "Routing problem/ 
   Switching Type" indication. 
 
3.1.3 Generalized-PID (G-PID) 
    
   The G-PID (16 bits field) as defined in [RFC3471], identifies the 
   payload carried by an LSP, i.e. an identifier of the client layer of 
   that LSP. This identifier is used by the endpoints of the G.709 LSP. 
 
   The G-PID can take one of the following values when the client 
   payload is transported over the Digital Path layer, in addition to 
   the payload identifiers defined in [RFC3471]: 
    
   - CBRa:  asynchronous Constant Bit Rate i.e. mapping of STM-16/OC- 
            48, STM-64/OC-192 and STM-256/OC-768 
   - CBRb:  bit synchronous Constant Bit Rate i.e. mapping of STM- 
            16/OC-48, STM-64/OC-192 and STM-256/OC-768 
   - ATM:   mapping at 2.5, 10 and 40 Gbps  
   - BSOT:  non-specific client Bit Stream with Octet Timing i.e.   
            Mapping of 2.5, 10 and 40 Gbps Bit Stream 
   - BSNT:  non-specific client Bit Stream without Octet Timing i.e.  
            Mapping of 2.5, 10 and 40 Gbps Bit Stream 
   - ODUk:  transport of Digital Paths at 2.5, 10 and 40 Gbps 
   - ESCON: Enterprise Systems Connection  
   - FICON: Fiber Connection 
 

  
D.Papadimitriou (Editor) et al. - Expires June 2005                  6 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   The G-PID can take one of the following values when the client 
   payload is transported over the Optical Channel layer, in addition 
   to the payload identifiers defined in [RFC3471]: 
   - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192  
          and STM-256/OC-768 
   - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps 
 
   Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are 
   encapsulated through the Generic Framing Procedure (GFP) as 
   described in ITU-T G.7041, dedicated G-PID values are defined.  
 
   In order to include pre-OTN developments, the G-PID field can take 
   one of the values (currently defined in [RFC3471]) when the 
   following client payloads are transported over a so-called lambda 
   LSP: 
   - Ethernet PHY (1 Gbps and 10 Gbps) 
   - Fiber Channel  
    
   The following table summarizes the G-PID with respect to the LSP 
   Encoding Type: 
    
   Value     G-PID Type                       LSP Encoding Type 
   -----     ----------                       ----------------- 
    47       G.709 ODUj                       G.709 ODUk (with k > j) 
    48       G.709 OTUk(v)                    G.709 OCh   
                                              ODUk mapped into OTUk(v) 
    49       CBR/CBRa                         G.709 ODUk, G.709 OCh 
    50       CBRb                             G.709 ODUk 
    51       BSOT                             G.709 ODUk 
    52       BSNT                             G.709 ODUk 
    53       IP/PPP (GFP)                     G.709 ODUk (and SDH) 
    54       Ethernet MAC (framed GFP)        G.709 ODUk (and SDH) 
    55       Ethernet PHY (transparent GFP)   G.709 ODUk (and SDH)  
    56       ESCON                            G.709 ODUk, Lambda, Fiber 
    57       FICON                            G.709 ODUk, Lambda, Fiber 
    58       Fiber Channel                    G.709 ODUk, Lambda, Fiber 
    
   Note: Values 49 and 50 include mapping of SDH. 
    
   The following table summarizes the update of the G-PID values 
   defined in [RFC3471]: 
    
   Value     G-PID Type                 LSP Encoding Type 
   -----     ----------                 ----------------- 
    32       ATM Mapping                SDH, G.709 ODUk  
    33       Ethernet PHY               SDH, G.709 OCh, Lambda, Fiber 
    34       Sonet/SDH                  G.709 OCh, Lambda, Fiber 
    35       Reserved (SONET Dep.)      G.709 OCh, Lambda, Fiber 
 
3.2 G.709 Traffic Parameters 
 
   When G.709 Digital Path Layer or G.709 Optical Channel Layer is 
   specified in the LSP Encoding Type field, the information referred 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  7 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   to as technology dependent (or simply traffic parameters) is carried 
   additionally to the one included in the Generalized Label Request.  
    
   The G.709 traffic parameters are defined 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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |  Signal Type  |   Reserved    |              NMC              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |              NVC              |        Multiplier (MT)        | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                           Reserved                            | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   In this frame, NMC stands for Number of Multiplexed Components, NVC 
   for Number of Virtual Components and MT for Multiplier. Each of 
   these fields is tailored to support G.709 LSP requests.  
    
   The RSVP-TE encoding of the G.709 traffic-parameters is detailed in 
   Section 6. 
 
3.2.1 Signal Type (ST) 
 
   This field (8 bits) indicates the type of G.709 Elementary Signal 
   that comprises the requested LSP. The permitted values are: 
    
      Value     Type 
      -----     ---- 
        0       Not significant 
        1       ODU1 (i.e. 2.5 Gbps)  
        2       ODU2 (i.e. 10  Gbps)    
        3       ODU3 (i.e. 40  Gbps) 
        4       Reserved (for future use)  
        5       Reserved (for future use) 
        6       OCh at 2.5 Gbps 
        7       OCh at 10  Gbps  
        8       OCh at 40  Gbps 
        9-255   Reserved (for future use) 
    
   The value of the Signal Type field depends on LSP Encoding Type 
   value defined in Section 3.1.1 and [RFC3471]: 
    - if the LSP Encoding Type value is the G.709 Digital Path layer  
      then the valid values are the ODUk signals (k = 1, 2 or 3)   
    - if the LSP Encoding Type value is the G.709 Optical Channel layer  
      then the valid values are the OCh at 2.5, 10 or 40 Gbps 
    - if the LSP Encoding Type is "Lambda" (which includes the  
      pre-OTN Optical Channel layer) then the valid value is irrelevant 
      (Signal Type = 0) 
    - if the LSP Encoding Type is "Digital Wrapper", then the valid   
      value is irrelevant (Signal Type = 0) 
    

  
D.Papadimitriou (Editor) et al. - Expires June 2005                  8 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   Several transforms can be sequentially applied on the Elementary 
   Signal to build the Final Signal being actually requested for the 
   LSP. Each transform application is optional and must be ignored if 
   zero, except the Multiplier (MT) that cannot be zero and must be 
   ignored if equal to one. Transforms must be applied strictly in the 
   following order:  
   - First, virtual concatenation (by using the NVC field) can  
     be optionally applied directly on the Elementary Signal to form a  
     Composed Signal 
   - Second, a multiplication (by using the Multiplier field) can be  
     optionally applied either directly on the Elementary Signal, or  
     on the virtually concatenated signal obtained from the first  
     phase. The resulting signal is referred to as Final Signal. 
    
3.2.2 Number of Multiplexed Components (NMC) 
    
   The NMC field (16 bits) indicates the number of ODU tributary slots 
   used by an ODUj when multiplexed into an ODUk (k > j) for the 
   requested LSP. This field is not applicable when an ODUk is mapped 
   into an OTUk and irrelevant at the Optical Channel layer. In both 
   cases, it MUST be set to zero (NMC = 0) when sent and should be 
   ignored when received. 
 
   When applied at the Digital Path layer, in particular for ODU2 
   connections multiplexed into one ODU3 payload, the NMC field 
   specifies the number of individual tributary slots (NMC = 4) 
   constituting the requested connection. These components are still 
   processed within the context of a single connection entity. For all 
   other currently defined multiplexing cases (see Section 2), the NMC 
   field is set to 1. 
 
3.2.3 Number of Virtual Components (NVC)  
 
   The NVC field (16 bits) is dedicated to ODUk virtual concatenation 
   (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number 
   of ODU1, ODU2 or ODU3 Elementary Signals that are requested to be 
   virtually concatenated to form an ODUk-Xv signal. By definition, 
   these signals MUST be of the same type.  
    
   This field is set to 0 (default value) to indicate that no virtual 
   concatenation is requested.  
    
   Note that the current usage of this field only applies for G.709 
   ODUk LSPs i.e. values greater than zero, are only acceptable for 
   ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and 
   should be ignored when received, when a G.709 OCh LSP is requested. 
    
3.2.4 Multiplier (MT) 
 
   The Multiplier field (16 bits) indicates the number of identical 
   Elementary Signals or Composed Signals requested for the LSP i.e. 
   that form the Final Signal. A Composed Signal is the resulting 
   signal from the application of the NMC and NVC fields to an 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                  9 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   elementary Signal Type. GMPLS signaling currently implies that all 
   the Composed Signals must be part of the same LSP. 
    
   This field is set to one (default value) to indicate that exactly 
   one instance of a signal is being requested. Intermediate and egress 
   nodes MUST verify that the node itself and the interfaces on which 
   the LSP will be established can support the requested multiplier 
   value. If the requested values can not be supported, the receiver 
   node MUST generate a PathErr message (see Section 6). 
    
   Zero is an invalid value for the MT field. If received, the node 
   MUST generate a PathErr message (see Section 6). 
    
3.2.5 Reserved Fields 
    
   The reserved fields (8 bits in row 1 and 32 bits in row 3) are 
   dedicated for future use. Reserved bits SHOULD be set to zero when 
   sent and MUST be ignored when received. 
 
4. Generalized Label 
    
   This section describes the Generalized Label value space for Digital 
   Paths and Optical Channels. The Generalized Label is defined in 
   [RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL 
   object is specified in [RFC3473] Section 2.2. 
    
   The label distribution rules detailed in Section 4.2 follow (when 
   applicable) the ones defined in [RFC3946]. 
    
4.1 ODUk Label Space 
    
   At the Digital Path layer (i.e. ODUk layers), G.709 defines three 
   different client payload bit rates. An Optical Data Unit (ODU) frame 
   has been defined for each of these bit rates. ODUk refers to the 
   frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 
   3 (for 40 Gbps). 
    
   In addition to the support of ODUk mapping into OTUk, the G.709 
   label space supports the sub-levels of ODUk multiplexing. ODUk 
   multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 
   (k > j), in particular:  
      - ODU1 into ODU2 multiplexing  
      - ODU1 into ODU3 multiplexing 
      - ODU2 into ODU3 multiplexing 
      - ODU1 and ODU2 into ODU3 multiplexing 
    
   More precisely, ODUj into ODUk multiplexing (k > j) is defined when 
   an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 
   ODTUG constituted by ODU tributary slots) which is mapped into an 
   OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 
   mapped into an OTUk.  
    

  
D.Papadimitriou (Editor) et al. - Expires June 2005                 10 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   Therefore, the label space structure is a tree whose root is an OTUk 
   signal and leaves the ODUj signals (k >= j) that can be transported 
   via the tributary slots and switched between these slots. A G.709 
   Digital Path layer label identifies the exact position of a 
   particular ODUj signal in an ODUk multiplexing structure.  
    
   The G.709 Digital Path Layer label or ODUk label has the following 
   format: 
    
     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                   Reserved                |     t3    | t2  |t1| 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
   Reserved bits MUST be set to zero when sent and SHOULD be ignored 
   when received.  
    
   The specification of the fields t1, t2 and t3 self-consistently 
   characterizes the ODUk label space. The value space for the t1, t2 
   and t3 fields is defined as follows: 
    
   1. t1 (1-bit):  
        - t1=1 indicates an ODU1 signal. 
        - t1 is not significant for the other ODUk signal types (i.e.  
          t1 value MUST be set to 0 and ignored). 
 
   2. t2 (3-bit):  
        - t2=1 indicates an ODU2 signal that is not further sub- 
          divided. 
        - t2=[2..5] indicates the tributary slot (t2th-2) used by the  
          ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 
        - t2 is not significant for an ODU3 (i.e. t2 value MUST be  
          set to 0 and ignored). 
         
   3. t3 (6-bit):  
        - t3=1 indicates an ODU3 signal that is not further sub- 
          divided. 
        - t3=[2..17] indicates the tributary slot (t3th-1) used by the  
          ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 
        - t3=[18..33] indicates the tributary slot (t3th-17) used by  
          the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 
    
   Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 
   to identify the 4 tributary slots used by the ODU2; these tributary 
   time slots have to be allocated in ascending order. 
    
   If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 
   > i), the corresponding ODUk signal ODU[i] is directly mapped into 
   the corresponding OTUk signal (k=i). This is referred to as the 
   mapping of an ODUk signal into an OTUk of the same order. Therefore, 
   the numbering starts at 1; zero is used to indicate a non-
   significant field. A label field equal to zero is an invalid value. 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 11 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
    
   Examples: 
    
   - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1  
   - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 
   - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 
   - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot  
     of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 
   - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot  
     of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 
    
4.2 Label Distribution Rules 
    
   In case of ODUk in OTUk mapping, only one label can appear in the 
   Generalized Label. The unique label is encoded as a single 32 bit 
   label value (as defined in Section 4.1) of the GENERALIZED_LABEL 
   object (Class-Num = 16, C-Type = 2) 
    
   In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 
   list of the labels in the multiplex is given (this list can be 
   restricted to only one label when NMC = 1). Each label indicates a 
   component (ODUj tributary slot) of the multiplexed signal. The order 
   of the labels must reflect the order of the ODUj into the multiplex 
   (not the physical order of tributary slots). This ordered list of 
   labels is encoded as a sequence of 32 bit label values (as defined 
   in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-
   Type = 2). 
    
   In case of ODUk virtual concatenation, the explicit ordered list of 
   all labels in the concatenation is given. Each label indicates a 
   component of the virtually concatenated signal. The order of the 
   labels must reflect the order of the ODUk to concatenate (not the 
   physical order of time-slots). This representation limits virtual 
   concatenation to remain within a single (component) link. In case of 
   multiplexed virtually concatenated signals, the first set of labels 
   indicates the components (ODUj tributary slots) of the first 
   virtually concatenated signal, the second set of labels indicates 
   the components (ODUj tributary slots) of the second virtually 
   concatenated signal, and so on. This ordered list of labels is 
   encoded as a sequence of 32 bit label values (as defined in Section 
   4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). 
   In case of ODUk virtual concatenation, the number of label values is 
   determined by the NVC value. Multiplexed ODUk virtual concatenation 
   additionally uses the NMC value to determine the number of labels 
   per set (equal in size). 
    
   In case of multiplication (i.e. when using the MT field), the 
   explicit ordered list of all labels taking part in the composed 
   signal is given. The above representation limits multiplication to 
   remain within a single (component) link. In case of multiplication 
   of multiplexed virtually concatenated signals, the first set of 
   labels indicates the components of the first multiplexed virtually 
   concatenated signal, the second set of labels indicates components 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 12 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   of the second multiplexed virtually concatenated signal, and so on. 
   This ordered list of labels is encoded as a sequence of 32 bit label  
   values (as defined in Section 4.1) of the GENERALIZED_LABEL object  
   (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) 
   ODUk virtual concatenated signals, the number of label values per 
   signal is determined by the NVC value. Multiplication of multiplexed 
   (equal) ODUk virtual concatenation additionally uses the NMC value 
   to determine the number of labels per set (equal in size). 
    
4.3 Optical Channel Label Space 
    
   At the Optical Channel layer, the label space must be consistently 
   defined as a flat space whose values reflect the local assignment of 
   OCh identifiers corresponding to the OTM-n.m sub-interface signals 
   (m = 1, 2 or 3). Note that these identifiers do not cover OChr since 
   the corresponding Connection Function (OChr-CF) between OTM-
   nr.m/OTM-0r.m is not defined in [ITUT-G798]. 
    
   The OCh label space values are defined by either absolute values 
   (i.e. channel identifiers or Channel ID also referred to as 
   wavelength identifiers) or relative values (channel spacing also 
   referred to as inter-wavelength spacing). The latter is strictly 
   confined to a per-port label space while the former could be defined 
   as a local or a global (per node) label space. Such an OCh label 
   space is applicable to both OTN Optical Channel layer and pre-OTN 
   Optical Channel layer.   
    
   Optical Channel label encoding (and distribution) rules are defined 
   in [RFC3471]. They MUST be used for the Upstream Label, the 
   Suggested Label and the Generalized Label. 
    
5. Examples 
    
   The following examples are given in order to illustrate the 
   processing described in the previous sections of this document. 
    
   1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is  
      directly transported in an OTU1 (OTU2 or OTU3), the upstream node  
      requests results simply in an ODU1 (ODU2 or ODU3) signal request.  
 
      In such conditions, the downstream node has to return a unique  
      label since the ODU1 (ODU2 or ODU3) is directly mapped into the  
      corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is  
      requested (Signal Type = 1, 2 or 3), the downstream node has to  
      return a single ODUk label which can be for instance one of the  
      following when the Signal Type = 1: 
    
      - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 
      - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 
      - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 
    
       
   2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 13 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
      into the payload of a structured ODU2 (or ODU3), the upstream    
      node requests results simply in a ODU1 signal request. 
    
      In such conditions, the downstream node has to return a unique  
      label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).  
      The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or  
      OPU3) and then mapped into the corresponding OTU2 (or OTU3).  
      Since a single ODU1 multiplexed signal is requested (Signal Type  
      = 1 and NMC = 1), the downstream node has to return a single ODU1  
      label which can take for instance one of the following values: 
       
      - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2   
      - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 
      - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 
    
   3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is  
      multiplexed into the payload of a structured ODU3, the upstream  
      node requests results simply in a ODU2 signal request. 
    
      In such conditions, the downstream node has to return four labels   
      since the ODU2 is multiplexed into one ODTUG3. The latter is   
      mapped into an ODU3 (via OPU3) and then mapped into an OTU3.   
      Since an ODU2 multiplexed signal is requested (Signal Type = 2, 
      and NMC = 4), the downstream node has to return four ODU labels  
      which can take for instance the following values: 
       
      - t3=18, t2=0, t1=0 (first  part of ODU2 in first TS of ODTUG3)   
      - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) 
      - t3=23, t2=0, t1=0 (third  part of ODU2 in sixth TS of ODTUG3) 
      - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 
 
   4. When a single OCh signal of 40 Gbps is requested (Signal Type =  
      8), the downstream node must return a single wavelength  
      label as specified in [RFC3471]. 
    
   5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT)  
      value > 1), an explicit list of labels is returned to the  
      requestor node.  
       
      When the downstream node receives a request for a 4 x ODU1 signal  
      (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it  
      returns an ordered list of four labels to the upstream node: the  
      first ODU1 label corresponding to the first signal of the LSP,  
      the second ODU1 label corresponding to the second signal of the  
      LSP, etc. For instance, the corresponding labels can take the  
      following values:   
    
      - First  ODU1: t3=2,  t2=0, t1=0 (in first TS of ODTUG3) 
      - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) 
      - Third  ODU1: t3=7,  t2=0, t1=0 (in sixth TS of ODTUG3) 
      - Fourth ODU1: t3=6,  t2=0, t1=0 (in fifth TS of ODTUG3)  
 
 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 14 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
6. RSVP-TE Signaling Protocol Extensions 
    
   This section specifies the [RFC3473] protocol extensions needed to 
   accommodate G.709 traffic parameters. 
    
   The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC 
   and FLOWSPEC objects. The same format is used both for 
   SENDER_TSPEC object and FLOWSPEC objects. The content of the 
   objects is defined above in Section 3.2. The objects have the 
   following class and type for G.709: 
   - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA  
   - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA 
    
   There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 
   Either the Adspec is omitted or an Int-serv Adspec with the 
   Default General Characterization Parameters and Guaranteed Service 
   fragment is used, see [RFC2210].  
    
   For a particular sender in a session the contents of the FLOWSPEC 
   object received in a Resv message SHOULD be identical to the 
   contents of the SENDER_TSPEC object received in the corresponding 
   Path message. If the objects do not match, a ResvErr message with 
   a "Traffic Control Error/Bad Flowspec value" error SHOULD be 
   generated. 
    
   Intermediate and egress nodes MUST verify that the node itself and 
   the interfaces on which the LSP will be established can support 
   the requested Signal Type, NMC and NVC values (as defined in 
   Section 3.2). If the requested value(s) can not be supported, the 
   receiver node MUST generate a PathErr message with a "Traffic 
   Control Error/Service unsupported" indication (see [RFC2205]). 
    
   In addition, if the MT field is received with a zero value, the 
   node MUST generate a PathErr message with a "Traffic Control 
   Error/Bad Tspec value" indication (see [RFC2205]). 
 
7. Security Considerations 
    
   This draft introduces no new security considerations to [RFC3473].  
 
8. IANA Considerations 
    
   Two values have to be defined by IANA for this document: 
    
   Two RSVP C-Types in registry: 
    
             http://www.iana.org/assignments/rsvp-parameters 
    
             - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5  
               (Suggested value, TBA) - see Section 6. 
    
             - A G.709 FLOWSPEC object: Class = 9, C-Type = 5  
               (Suggested value, TBA) - see Section 6. 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 15 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
    
   IANA is also requested to track the code-point spaces extended 
   and/or updated by this document. For this purpose, the following 
   new registry entries are requested in the newly requested registry 
   entry: http://www.iana.org/assignments/gmpls 
    
   - LSP Encoding Type:  
        http://www.iana.org/assignments/gmpls/lsp-encoding-type 
     Name: LSP Encoding Type 
     Format: 8-bit number 
     Values:  
        [1..11]         defined in [RFC3471]   
        12              defined in Section 3.1.1  
        13              defined in Section 3.1.1 
     Allocation Policy:  
        [0..239]        Assigned by IANA via IETF Standards Track RFC 
                        Action. 
        [240..255]      Assigned temporarily for Experimental Usage.  
                        these will not be registered with IANA 
    
   - Switching Type:  
        http://www.iana.org/assignments/gmpls/switching-type 
     Name: Switching Type 
     Format: 8-bit number 
     Values: defined in [RFC3471] 
     Allocation Policy:  
        [0..255]        Assigned by IANA via IETF Standards Track RFC 
                        Action. 
    
   - Generalized PID (G-PID):  
        http://www.iana.org/assignments/gmpls/generalized-pid 
     Name: G-PID 
     Format: 16-bit number 
     Values:  
        [0..31]         defined in [RFC3471] 
        [32..35]        defined in [RFC3471] and updated by Section 
                        3.1.3 
        [36..46]        defined in [RFC3471]             
        [47..58]        defined in Section 3.1.3 
     Allocation Policy: 
        [0..31743]      Assigned by IANA via IETF Standards Track RFC 
                        Action. 
        [31744..32767]  Assigned temporarily for Experimental Usage   
        [32768..65535]  Not assigned. Before any assignments can be  
                        made in this range, there MUST be a Standards  
                        Track RFC that specifies IANA Considerations 
                        that covers the range being assigned. 
    
9. Acknowledgments 
    
   The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, 
   Massimo Canali, Germano Gasparini and Fong Liaw for their 
   constructive comments and inputs as well as James Fu, Siva 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 16 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   Sankaranarayanan and Yangguang Xu for their useful feedback. Many 
   thanks to Adrian Farrel for having thoroughly reviewing this 
   document.  
    
   This draft incorporates (upon agreement) material and ideas from 
   draft-lin-ccamp-ipo-common-label-request-00.txt. 
    
10. References 
    
10.1 Normative References 
 
   [GMPLS-RTG]  Kompella, K. (Editor) et al., "Routing Extensions in 
                Support of Generalized MPLS," Internet Draft (work in 
                progress), draft-ietf-ccamp-gmpls-routing-09.txt, 
                October 2003. 
    
   [RFC2026]    Bradner, S., "The Internet Standards Process -- 
                Revision  3," BCP 9, RFC 2026, October 1996. 
    
   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate 
                Requirement Levels," BCP 14, RFC 2119, March 1997. 
   
   [RFC2205]    Braden, R., et al., "Resource ReSerVation Protocol 
                (RSVP) -- Version 1 Functional Specification," RFC 
                2205, September 1997. 
   
   [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated  
                Services," RFC 2210, September 1997. 
 
   [RFC3209]    Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP 
                Tunnels," RFC 3209, December 2001. 
 
   [RFC3471]    Berger, L. (Editor) et al., "Generalized Multi-
                Protocol Label Switching (GMPLS) Signaling - 
                Functional Description," RFC 3471, January 2003. 
    
   [RFC3473]    Berger, L. (Editor) et al., "Generalized Multi-
                Protocol Label Switching (GMPLS) Signaling Resource 
                ReserVation Protocol-Traffic Engineering (RSVP-TE) 
                Extensions," RFC 3473, January 2003. 
    
   [RFC3667]    Bradner, S., "IETF Rights in Contributions", BCP 78, 
                RFC 3667, February 2004. 
                 
   [RFC3668]    Bradner, S., Ed., "Intellectual Property Rights in IETF 
                Technology", BCP 79, RFC 3668, February 2004.  
      
   [RFC3946]    Mannie, E. and Papadimitriou, D. (Editors) et al., 
                "Generalized Multiprotocol Label Switching Extensions 
                for SONET and SDH Control," RFC 3946, October 2004. 
 
10.2 Informative References 
 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 17 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
   [RFC3945]    Mannie, E. (Editor) et al., "Generalized Multi-Protocol 
                Label Switching (GMPLS) Architecture," RFC 3945, 
                October 2004. 
    
   For information on the availability of the following documents, 
   please see http://www.itu.int 
    
   [ITUT-G707]  ITU-T, "Network node interface for the synchronous 
                digital hierarchy (SDH)," G.707 Recommendation, October 
                2000. 
    
   [ITUT-G709]  ITU-T, "Interface for the Optical Transport Network 
                (OTN)," G.709 Recommendation (and Amendment 1), 
                February 2001 (October 2001). 
    
   [ITUT-G798]  ITU-T, "Characteristics of Optical Transport Network 
                Hierarchy Equipment Functional Blocks," G.798 
                Recommendation, October 2001. 
    
11. Contributors 
    
   Alberto Bellato (Alcatel) 
   Via Trento 30,  
   I-20059 Vimercate, Italy 
   Email: alberto.bellato@alcatel.it  
    
   Sudheer Dharanikota (Consult) 
   Email: sudheer@ieee.org 
    
   Michele Fontana (Alcatel) 
   Via Trento 30,  
   I-20059 Vimercate, Italy 
   Email: michele.fontana@alcatel.it 
 
   Nasir Ghani (Sorrento Networks) 
   9990 Mesa Rim Road,  
   San Diego, CA 92121, USA 
   Email: nghani@sorrentonet.com 
 
   Gert Grammel (Alcatel) 
   Lorenzstrasse, 10,  
   70435 Stuttgart, Germany  
   Email: gert.grammel@alcatel.de 
 
   Dan Guo (Turin Networks)  
   1415 N. McDowell Blvd,  
   Petaluma, CA 94954, USA 
   Email: dguo@turinnetworks.com 
    
   Juergen Heiles (Siemens)  
   Hofmannstr. 51,  
   D-81379 Munich, Germany 
   Email: juergen.heiles@siemens.com 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 18 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
    
   Jim Jones (Alcatel)   
   3400 W. Plano Parkway,  
   Plano, TX 75075, USA 
   Email: jim.d.jones@alcatel.com 
    
   Zhi-Wei Lin (Lucent)  
   101 Crawfords Corner Rd, Rm 3C-512  
   Holmdel, New Jersey 07733-3030, USA 
   Email: zwlin@lucent.com 
    
   Eric Mannie (Consult) 
   Email: eric_mannie@hotmail.com 
 
   Maarten Vissers (Alcatel) 
   Lorenzstrasse, 10,  
   70435 Stuttgart, Germany  
   Email: maarten.vissers@alcalel.de 
    
   Yong Xue (WorldCom) 
   22001 Loudoun County Parkway,  
   Ashburn, VA 20147, USA 
   Email: yong.xue@wcom.com 
 
12. Editor's Address 
    
   Dimitri Papadimitriou (Alcatel) 
   Francis Wellesplein 1,  
   B-2018 Antwerpen, Belgium 
   Phone: +32 3 240-8491 
   Email: dimitri.papadimitriou@alcatel.be 

  
D.Papadimitriou (Editor) et al. - Expires June 2005                 19 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
Appendix 1 - Abbreviations 
    
   BSNT         Bit Stream without Octet Timing 
   BSOT         Bit Stream with Octet Timing 
   CBR          Constant Bit Rate 
   ESCON        Enterprise Systems Connection 
   FC           Fiber Channel 
   FEC          Forward Error Correction 
   FICON        Fiber Connection 
   FSC          Fiber Switch Capable 
   GCC          General Communication Channel 
   GFP          Generic Framing Procedure 
   LSC          Lambda Switch Capable 
   LSP          Label Switched Path 
   MS           Multiplex Section 
   naOH         non-associated Overhead 
   NMC          Number of Multiplexed Components 
   NVC          Number of Virtual Components 
   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 
   OH           Overhead 
   OMS          Optical Multiplex Section 
   OMU          Optical Multiplex Unit 
   OOS          OTM Overhead Signal 
   OPS          Optical Physical Section 
   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 
   PPP          Point to Point Protocol 
   PSC          Packet Switch Capable 
   RES          Reserved 
   RS           Regenerator Section 
   TTI          Trail Trace Identifier 
   TDM          Time Division Multiplex 
 
Appendix 2 - G.709 Indexes 
    
   - Index k: The index "k" is used to represent a supported bit rate 
   and the different versions of OPUk, ODUk and OTUk. k=1 represents an 
   approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 
   bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 
   and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 
   The exact bit-rate values are in kbits/s: 
    . OPU: k=1: 2 488 320.000, k=2:  9 995 276.962, k=3: 40 150 519.322 
  
D.Papadimitriou (Editor) et al. - Expires June 2005                 20 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
    . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 
    . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 
    
   - Index m: The index "m" is used to represent the bit rate or set of 
   bit rates supported on the interface. This is a one or more digit 
   "k", where each "k" represents a particular bit rate. The valid 
   values for m are (1, 2, 3, 12, 23, 123). 
    
   - Index n: The index "n" is used to represent the order of the OTM, 
   OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 
   of wavelengths that can be supported at the lowest bit rate 
   supported on the wavelength. It is possible that a reduced number of 
   higher bit rate wavelengths are supported. The case n=0 represents a 
   single channel without a specific wavelength assigned to the 
   channel. 
    
   - Index r: The index "r", if present, is used to indicate a reduced 
   functionality OTM, OCG, OCC and OCh (non-associated overhead is not 
   supported). Note that for n=0 the index r is not required as it 
   implies always reduced functionality. 
    

  
D.Papadimitriou (Editor) et al. - Expires June 2005                 21 


draft-ietf-ccamp-gmpls-g709-09.txt                        January 2005 
 
 
Intellectual Property Statement 
    
   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. 
    
Disclaimer of Validity 
    
   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 AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2004). 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. 
 
Acknowledgment 
 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
    
    
    
    
    

  
D.Papadimitriou (Editor) et al. - Expires June 2005                 22