Skip to main content

Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-g709-framework-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7062.
Authors Dan Li , Daniele Ceccarelli , Fatai Zhang , Han Li , Sergio Belotti
Last updated 2011-09-08 (Latest revision 2011-03-11)
Replaces draft-zhang-ccamp-gmpls-g709-framework
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7062 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ccamp-gmpls-g709-framework-05
Network Working Group                                   Fatai Zhang, Ed. 
Internet Draft                                                    Dan Li 
Category: Informational                                           Huawei 
                                                                  Han Li 
                                                                    CMCC 
                                                               S.Belotti 
                                                          Alcatel-Lucent 
                                                           D. Ceccarelli 
                                                                Ericsson 
Expires: March 9, 2012                                 September 9, 2011 
                                                                        
                                    
                 Framework for GMPLS and PCE Control of  
                    G.709 Optical Transport Networks  
                                    
               draft-ietf-ccamp-gmpls-g709-framework-05.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months   
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference   
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

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

   This Internet-Draft will expire on March 9, 2012. 

    

Abstract 
 
   This document provides a framework to allow the development of 
   protocol extensions to support Generalized Multi-Protocol Label 
   Switching (GMPLS) and Path Computation Element (PCE) control of 

 
 
 
Zhang                    Expires March 2012                    [Page 1] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   Optical Transport Networks (OTN) as specified in ITU-T Recommendation 
   G.709 as consented in October 2009. 

Table of Contents 

    
   1. Introduction .................................................. 2 
   2. Terminology ................................................... 3 
   3. G.709 Optical Transport Network (OTN) ......................... 4 
      3.1. OTN Layer Network ........................................ 4 
         3.1.1. Client signal mapping ............................... 5 
         3.1.2. Multiplexing ODUj onto Links ........................ 7 
            3.1.2.1. Structure of MSI information ................... 8 
   4. Connection management in OTN .................................. 9 
      4.1. Connection management of the ODU ........................ 10 
   5. GMPLS/PCE Implications ....................................... 12 
      5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 
      5.2. Implications for GMPLS Signaling ........................ 13 
      5.3. Implications for GMPLS Routing .......................... 16 
      5.4. Implications for Link Management Protocol (LMP) ......... 18 
      5.5. Implications for Path Computation Elements .............. 19 
   6. Data Plane Backward Compatibility Considerations ............. 20 
   7. Security Considerations ...................................... 20 
   8. IANA Considerations .......................................... 21 
   9. Acknowledgments .............................................. 21 
   10. References .................................................. 21 
      10.1. Normative References ................................... 21 
      10.2. Informative References ................................. 22 
   11. Authors' Addresses .......................................... 23 
   12. Contributors ................................................ 24 
   APPENDIX A: ODU connection examples ............................. 25 
 
 
1. Introduction 

   OTN has become a mainstream layer 1 technology for the transport 
   network. Operators want to introduce control plane capabilities based 
   on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, 
   to realize the benefits associated with a high-function control plane 
   (e.g., improved network resiliency, resource usage efficiency, etc.). 

   GMPLS extends MPLS to encompass time division multiplexing (TDM) 
   networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda 
   switching optical networks, and spatial switching (e.g., incoming 
   port or fiber to outgoing port or fiber). The GMPLS architecture is 
   provided in [RFC3945], signaling function and Resource ReserVation 
   Protocol-Traffic Engineering (RSVP-TE) extensions are described in 
 
 
Zhang                    Expires March 2012                    [Page 2] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   [RFC3471] and [RFC3473], routing and OSPF extensions are described in 
   [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is 
   described in [RFC4204].  

   The GMPLS protocol suite including provision [RFC4328] provides the 
   mechanisms for basic GMPLS control of OTN networks based on the 2001 
   revision of the G.709 specification [G709-V1]. Later revisions of the 
   G.709 specification, including [G709-V3], have included some new 
   features; for example, various multiplexing structures, two types of 
   TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data 
   Unit (ODU) ODUj definition to include the ODUflex function. 

   This document reviews relevant aspects of OTN technology evolution 
   that affect the GMPLS control plane protocols and examines why and 
   how to update the mechanisms described in [RFC4328]. This document 
   additionally provides a framework for the GMPLS control of OTN 
   networks and includes a discussion of the implication for the use of 
   the Path Computation Element (PCE) [RFC4655].  

   For the purposes of the control plane the OTN can be considered as 
   being comprised of ODU and wavelength (OCh) layers. This document 
   focuses on the control of the ODU layer, with control of the 
   wavelength layer considered out of the scope. Please refer to 
   [RFC6163] for further information about the wavelength layer. 

    

2. Terminology 

   OTN: Optical Transport Network 

   ODU: Optical Channel Data Unit 

   OTU: Optical channel transport unit 

   OMS: Optical multiplex section 

   MSI: Multiplex Structure Identifier 

   TPN: Tributary Port Number 

   LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, 
   flex.) represents the container transporting a client of the OTN that 
   is either directly mapped into an OTUk (k = j) or multiplexed into a 
   server HO ODUk (k > j) container. 

 
 
Zhang                    Expires March 2012                    [Page 3] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 
   represents the entity transporting a multiplex of LO ODUj tributary 
   signals in its OPUk area. 

   ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 
   bit rate tolerance up to +/-100 ppm. 

    

3. G.709 Optical Transport Network (OTN) 

   This section provides an informative overview of those aspects of the 
   OTN impacting control plane protocols.  This overview is based on the 
   ITU-T Recommendations that contain the normative definition of the 
   OTN. Technical details regarding OTN architecture and interfaces are 
   provided in the relevant ITU-T Recommendations. 

   Specifically, [G872-2001] and [G872Am2] describe the functional 
   architecture of optical transport networks providing optical signal 
   transmission, multiplexing, routing, supervision, performance 
   assessment, and network survivability.  [G709-V1] defines the 
   interfaces of the optical transport network to be used within and 
   between subnetworks of the optical network.  With the evolution and 
   deployment of OTN technology many new features have been specified in 
   ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 
   and ODUflex containers as described in [G709-V3]. 

3.1. OTN Layer Network 

   The simplified signal hierarchy of OTN is shown in Figure 1, which 
   illustrates the layers that are of interest to the control plane. 
   Other layers below OCh (e.g. Optical Transmission Section - OTS) are 
   not included in this Figure. The full signal hierarchy is provided in 
   [G709-V3].  

                               Client signal 
                                    | 
                                   ODUj 
                                    | 
                                 OTU/OCh 
                                   OMS 

                   Figure 1 - Basic OTN signal hierarchy 
    

 
 
Zhang                    Expires March 2012                    [Page 4] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   Client signals are mapped into ODUj containers. These ODUj containers 
   are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are 
   combined in the Optical Multiplex Section (OMS) using WDM 
   multiplexing, and this aggregated signal provides the link between 
   the nodes. 

3.1.1. Client signal mapping 

    
   The client signals are mapped into a Low Order (LO) ODUj. Appendix A 
   gives more information about LO ODU. 

   The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, 
   Flex. The approximate bit rates of these signals are defined in 
   [G709-V3] and are reproduced in Tables 1 and 2. 

 
   +-----------------------+-----------------------------------+ 
   |       ODU Type        |       ODU nominal bit rate        | 
   +-----------------------+-----------------------------------+ 
   |         ODU0          |         1 244 160 kbits/s         | 
   |         ODU1          |    239/238 x 2 488 320 kbit/s     | 
   |         ODU2          |    239/237 x 9 953 280 kbit/s     | 
   |         ODU3          |    239/236 x 39 813 120 kbit/s    | 
   |         ODU4          |    239/227 x 99 532 800 kbit/s    | 
   |         ODU2e         |    239/237 x 10 312 500 kbit/s    | 
   |                       |                                   | 
   |    ODUflex for CBR    |                                   | 
   |    Client signals     | 239/238 x client signal bit rate  | 
   |                       |                                   | 
   |   ODUflex for GFP-F   |                                   | 
   | Mapped client signal  |        Configured bit rate        | 
   +-----------------------+-----------------------------------+ 
 
                     Table 1 - ODU types and bit rates 
                                      
   NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s 
   (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 
   104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 
    
    
    
    
 
 
Zhang                    Expires March 2012                    [Page 5] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   +-----------------------+-----------------------------------+ 
   |      ODU Type         |       ODU bit-rate tolerance      | 
   +-----------------------+-----------------------------------+ 
   |        ODU0           |            +- 20 ppm              | 
   |        ODU1           |            +- 20 ppm              | 
   |        ODU2           |            +- 20 ppm              | 
   |        ODU3           |            +- 20 ppm              | 
   |        ODU4           |            +- 20 ppm              | 
   |        ODU2e          |            +- 100 ppm             | 
   |                       |                                   | 
   |   ODUflex for CBR     |                                   | 
   |   Client signals      |            +- 100 ppm             | 
   |                       |                                   | 
   |  ODUflex for GFP-F    |                                   | 
   | Mapped client signal  |            +- 100 ppm             | 
   +-----------------------+-----------------------------------+ 
                     Table 2 - ODU types and tolerance 
    
   One of two options is for mapping client signals into ODUflex 
   depending on the client signal type:  

   -  Circuit clients are proportionally wrapped. Thus the bit rate and 
      tolerance are defined by the client signal. 

   -  Packet clients are mapped using the Generic Framing Procedure 
      (GFP). [G709-V3] recommends that the bit rate should be set to an 
      integer multiplier of the High Order (HO) Optical Channel Physical 
      Unit (OPU) OPUk TS rate, the tolerance should be +/-100ppm, and 
      the bit rate should be determined by the node that performs the 
      mapping. 

   [Editors' Note: As outcome of ITU SG15/q11 expert meeting held in 
   Vimercate in September 2010 it was decided that a resizable 
   ODUflex(GFP) occupies the same number of TS on every link of the path 
   (independently of the High Order (HO) OPUk TS rate). Please see WD07 
   and the meeting report of this meeting for more information. 

   The authors will update the above text related to Packet client 
   mapping as soon as new version of G.709 will be updated accordingly 
   with expert meeting decision reported here.] 

    

 
 
Zhang                    Expires March 2012                    [Page 6] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

3.1.2. Multiplexing ODUj onto Links 

   The links between the switching nodes are provided by one or more 
   wavelengths.  Each wavelength carries one OCh, which carries one OTU, 
   which carries one ODU.  Since all of these signals have a 1:1:1 
   relationship, we only refer to the OTU for clarity.  The ODUjs are 
   mapped into the TS of the OPUk.  Note that in the case where j=k the 
   ODUj is mapped into the OTU/OCh without multiplexing.   

   The initial versions of G.709 [G709-V1] only provided a single TS 
   granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an 
   additional TS granularity, nominally 1.25Gb/s. The number and type of 
   TSs provided by each of the currently identified OTUk is provided 
   below: 

                2.5Gb/s     1.25Gb/s           Nominal Bit rate  
     OTU1         1             2                  2.5Gb/s 
     OTU2         4             8                   10Gb/s 
     OTU3        16            32                   40Gb/s 
     OTU4        --            80                  100Gb/s 
    
   To maintain backwards compatibility while providing the ability to 
   interconnect nodes that support 1.25Gb/s TS at one end of a link and 
   2.5Gb/s TS at the other, the 'new' equipment will fall back to the 
   use of a 2.5Gb/s TS if connected to legacy equipment.  This 
   information is carried in band by the payload type. 

   The actual bit rate of the TS in an OTUk depends on the value of k.  
   Thus the number of TS occupied by an ODUj may vary depending on the 
   values of j and k.  For example an ODU2e uses 9 TS in an OTU3 but 
   only 8 in an OTU4. Examples of the number of TS used for various 
   cases are provided below: 

   -  ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 
      granularity  
      o  ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 
         or ODU4  
   -  ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 
      granularity  
      o  ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4  
    
   -  ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity  
      o  ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3  
    
 
 
Zhang                    Expires March 2012                    [Page 7] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   -  ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity  
      o  ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 
    
   -  ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity  
      o  ODU2 occupies 4 of the 16 TS for ODU3  
    
   -  ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity  
      o  ODU3 occupies 31 of the 80 TS for ODU4  
    
   -  ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS 
      granularity  
      o  ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 
         (n <= Total TS numbers of ODUk)  
    
   -  ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity  
      o  ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for 
         ODU4 
    
   In general the mapping of an ODUj (including ODUflex) into the OTUk 
   TSs is determined locally, and it can also be explicitly controlled 
   by a specific entity (e.g., head end, NMS) through Explicit Label 
   Control [RFC3473]. 

    

3.1.2.1. Structure of MSI information 

   When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the    
   information that has to be transported in-band in order to allow for    
   correct demultiplexing. This information, known as Multiplex 
   Structure Information (MSI), is transported in the OPUk overhead and 
   is local to each link. In case of bidirectional paths the association 
   between TPN and TS MUST be the same in both directions.  

   The MSI information is organized as a set of entries, with one entry 
   for each HO ODUj TS. The information carried by each entry is:  

       Payload Type:  the type of the transported payload.   

       Tributary Port Number (TPN):  the port number of the ODUj        
       transported by the HO ODUk. The TPN is the same for all the TSs        
       assigned to the transport of the same ODUj instance.  

 
 
Zhang                    Expires March 2012                    [Page 8] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   For example, an ODU2 carried by a HO ODU3 is described by 4 entries 
   in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries    
   when the TS size is 1.25 Gbit/s.  

 
   On each node and on every link, two MSI values have to be provisioned:    

     The TxMSI information inserted in OPU (e.g., OPU3) overhead by the 
     source of the HO ODUk trail. 
     The expectedMSI information that is used to check the acceptedMSI 
     information. The acceptedMSI information is the MSI valued received 
     in-band, after a 3 frames integration. 
   
   The sink of the HO ODU trail checks the complete content of the 
   acceptedMSI information (against the expectedMSI.  
   If the acceptedMSI is different from the expectedMSI, then the 
   traffic is dropped and a payload mismatch alarm is generated.   

   Provisioning of TPN can be performed either by network management 
   system or control plane. In the last case, control plane is also 
   responsible for negotiating the provisioned values on a link by link 
   base. 

4. Connection management in OTN  

   OTN-based connection management is concerned with controlling the 
   connectivity of ODU paths and optical channels (OCh). This document 
   focuses on the connection management of ODU paths.  The management of 
   OCh paths is described in [RFC6163]. 

   While [G872-2001] considered the ODU as a set of layers in the same 
   way as SDH has been modeled, recent ITU-T OTN architecture progress 
   [G872-Am2] includes an agreement to model the ODU as a single layer 
   network with the bit rate as a parameter of links and connections. 
   This allows the links and nodes to be viewed in a single topology as 
   a common set of resources that are available to provide ODUj 
   connections independent of the value of j. Note that when the bit 
   rate of ODUj is less than the server bit rate, ODUj connections are 
   supported by HO-ODU (which has a one-to-one relationship with the 
   OTU).  

   From an ITU-T perspective, the ODU connection topology is represented 
   by that of the OTU link layer, which has the same topology as that of 
   the OCh layer (independent of whether the OTU supports HO-ODU, where 
   multiplexing is utilized, or LO-ODU in the case of direct mapping). 
   Thus, the OTU and OCh layers should be visible in a single 
 
 
Zhang                    Expires March 2012                    [Page 9] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   topological representation of the network, and from a logical 
   perspective, the OTU and OCh may be considered as the same logical, 
   switchable entity.   

   Note that the OTU link layer topology may be provided via various 
   infrastructure alternatives, including point-to-point optical 
   connections, flexible optical connections fully in the optical domain, 
   flexible optical connections involving hybrid sub-lambda/lambda nodes 
   involving 3R, etc.   

   The document will be updated to maintain consistency with G.872 
   progress when it is consented for publication. 

4.1. Connection management of the ODU 

   LO ODUj can be either mapped into the OTUk signal (j = k), or 
   multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is 
   mapped into an OCh. See Appendix A for more information. 

   From the perspective of control plane, there are two kinds of network 
   topology to be considered. 

    

   (1) ODU layer  

   In this case, the ODU links are presented between adjacent OTN nodes, 
   which is illustrated in Figure 2. In this layer there are ODU links 
   with a variety of TSs available, and nodes that are ODXCs. Lo ODU 
   connections can be setup based on the network topology.  

                  Link #5       +--+---+--+        Link #4 
     +--------------------------|         |--------------------------+ 
     |                          |  ODXC   |                          | 
     |                          +---------+                          | 
     |                             Node E                            | 
     |                                                               | 
   +-++---+--+        +--+---+--+        +--+---+--+        +--+---+-++ 
   |         |Link #1 |         |Link #2 |         |Link #3 |         | 
   |         |--------|         |--------|         |--------|         | 
   |  ODXC   |        |  ODXC   |        |  ODXC   |        |  ODXC   | 
   +---------+        +---------+        +---------+        +---------+ 
      Node A             Node B              Node C            Node D 
    
        Figure 2 - Example Topology for LO ODU connection management 

 
 
Zhang                    Expires March 2012                   [Page 10] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   If an ODUj connection is requested between Node C and Node E 
   routing/path computation must select a path that has the required 
   number of TS available and that offers the lowest cost.  Signaling is 
   then invoked to set up the path and to provide the information (e.g., 
   selected TS) required by each transit node to allow the configuration 
   of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and 
   demapping (j = k) or demultiplexing (j < k).     

   (2) ODU layer with OCh switching capability 

   In this case, the OTN nodes interconnect with wavelength switched 
   node (e.g., ROADM,OXC) that are capable of OCh switching, which is 
   illustrated in Figure 3 and Figure 4. There are ODU layer and OCh 
   layer, so it is simply a MLN. OCh connections may be created on 
   demand, which is described in section 5.1. 

   In this case, an operator may choose to allow the underlined OCh 
   layer to be visible to the ODU routing/path computation process in 
   which case the topology would be as shown in Figure 4. In Figure 3 
   below, instead, a cloud representing OCH capable switching nodes is 
   represented. In Figure 3, the operator choice is to hide the real RWA 
   network topology. 

    

                                Node E 
         Link #5              +--------+       Link #4 
     +------------------------|        |------------------------+ 
     |                          ------                          | 
     |                       //        \\                       | 
     |                      ||          ||                      | 
     |                      | RWA domain |                      | 
   +-+-----+        +----+- ||          || ------+        +-----+-+ 
   |       |        |        \\        //        |        |       | 
   |       |Link #1 |          --------          |Link #3 |       | 
   |       +--------+         |        |         +--------+       + 
   | ODXC  |        |  ODXC   +--------+  ODXC   |        | ODXC  | 
   +-------+        +---------+Link #2 +---------+        +-------+ 
     Node A            Node B             Node C            Node D 

    

      Figure 3 - RWA Hidden Topology for LO ODU connection management 

    

    
 
 
Zhang                    Expires March 2012                   [Page 11] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

           Link #5            +---------+            Link #4 
     +------------------------|         |-----------------------+ 
     |                   +----| ODXC    |----+                  | 
     |                 +-++   +---------+   ++-+                | 
     |         Node f  |  |     Node E      |  |  Node g        | 
     |                 +-++                 ++-+                | 
     |                   |       +--+        |                  | 
   +-+-----+        +----+----+--|  |--+-----+---+        +-----+-+ 
   |       |Link #1 |         |  +--+  |         |Link #3 |       | 
   |       +--------+         | Node h |         +--------+       + 
   | ODXC  |        | ODXC    +--------+ ODXC    |        | ODXC  | 
   +-------+        +---------+ Link #2+---------+        +-------+ 
     Node A            Node B            Node C             Node D 

    
     Figure 4 - RWA Visible Topology for LO ODUj connection management 

    

   In Figure 4, the cloud of previous figure is substitute by the real 
   topology. The nodes f, g, h are nodes with OCH switching capability. 

   In the examples (i.e., Figure 3 and Figure 4), we have considered the 
   case in which LO-ODUj connections are supported by OCh connection, 
   and the case in which the supporting underlying connection can be 
   also made by a combination of HO-ODU/OCh connections.  

   In this case, the ODU routing/path selection process will request an 
   HO-ODU/OCh connection between node C and node E from the RWA domain. 
   The connection will appear at ODU level as a Forwarding Adjacency, 
   which will be used to create the ODU connection. 

 
5. GMPLS/PCE Implications 

   The purpose of this section is to provide a set of requirements to be 
   evaluated for extensions of the current GMPLS protocol suite and the 
   PCE applications and protocols to encompass OTN enhancements and 
   connection management. 

5.1. Implications for LSP Hierarchy with GMPLS TE 

   The path computation for ODU connection request is based on the 
   topology of ODU layer, including OCh layer visibility.  

   The OTN path computation can be divided into two layers. One layer is 
   OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the 
 
 
Zhang                    Expires March 2012                   [Page 12] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   mechanisms to accomplish creating the hierarchy of LSPs. The LSP 
   management of multiple layers in OTN can follow the procedures 
   defined in [RFC4206], [RFC6107] and related MLN drafts. 

   As discussed in section 4, the route path computation for OCh is in 
   the scope of WSON [RFC6163]. Therefore, this document only considers 
   ODU layer for ODU connection request. 

   LSP hierarchy can also be applied within the ODU layers. One of the 
   typical scenarios for ODU layer hierarchy is to maintain 
   compatibility with introducing new [G709-V3] services (e.g., ODU0, 
   ODUflex) into a legacy network configuration (containing [G709-V1] or 
   [G709-V2] OTN equipment). In this scenario, it may be needed to 
   consider introducing hierarchical multiplexing capability in specific 
   network transition scenarios. One method for enabling multiplexing 
   hierarchy is by introducing dedicated boards in a few specific places 
   in the network and tunneling these new services through [G709-V1] or 
   [G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to 
   upgrade every network element to [G709-V3] capabilities.  

   In such case, one ODUj connection can be nested into another ODUk 
   (j<k) connection, which forms the LSP hierarchy in ODU layer. The 
   creation of the outer ODUk connection can be triggered via network 
   planning, or by the signaling of the inner ODUj connection. For the 
   former case, the outer ODUk connection can be created in advance 
   based on network planning. For the latter case, the multi-layer 
   network signaling described in [RFC4206], [RFC6107] and [RFC6001] 
   (including related modifications, if needed) are relevant to create 
   the ODU connections with multiplexing hierarchy. In both cases, the 
   outer ODUk connection is advertised as a Forwarding Adjacency (FA). 

5.2. Implications for GMPLS Signaling 

   The signaling function and Resource reSerVation Protocol-Traffic 
   Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC 
   3473]. For OTN-specific control, [RFC4328] defines signaling 
   extensions to support G.709 Optical Transport Networks Control as 
   defined in [G709-V1].  

   As described in Section 3, [G709-V3] introduced some new features 
   that include the ODU0, ODU2e, ODU4 and ODUflex containers. The 
   mechanisms defined in [RFC4328] do not support such new OTN features, 
   and protocol extensions will be necessary to allow them to be 
   controlled by a GMPLS control plane. 

   [RFC4328] defines the LSP Encoding Type, the Switching Type and the 
   Generalized Protocol Identifier (Generalized-PID) constituting the 
 
 
Zhang                    Expires March 2012                   [Page 13] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   common part of the Generalized Label Request. The G.709 Traffic 
   Parameters are also defined in [RFC4328].  The following signaling 
   aspects should be considered additionally since [RFC4328] was 
   published: 

   -  Support for backward compatibility with [RFC4328] 

      A new Switching Capability type needs to be defined for control of 
      [G709-V3] in the routing, so the Switching Type used when 
      signalling of LSPs for [G709-V3] should be consistent with the 
      Switching Type in the routing information. 

      Assume [RFC4328] has been deployed to control the OTN networks 
      supporting [G709-V1], control plane backward compatibility needs 
      to be taken into consideration when interworking with legacy nodes 
      only supporting [RFC4328] and [G709-V1].  

   -  Support for specifying the new signal types and the related 
      traffic information 

      The traffic parameters should be extended in signaling message to 
      support the new optical Channel Data Unit (ODUj) including: 

         -  ODU0 
         -  ODU2e 
         -  ODU4 
         -  ODUflex 

      For ODUflex, since it has a variable bandwidth/bit rate BR and a 
      bit rate tolerance T, the (node local) mapping process must be 
      aware of the bit rate and tolerance of the ODUj being multiplexed 
      in order to select the correct number of TS and the fixed/variable 
      stuffing bytes. Therefore, bit rate and bit rate tolerance should 
      also be carried in the Traffic Parameter in the signaling of 
      connection setup request. 

      For other ODU signal types, the bit rates and tolerances of them 
      are fixed and can be deduced from the signal types. 

   -  Support for LSP setup using different Tributary Slot granularity 

      The signaling protocol should be able to identify the type of TS 
      (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS 
      granularity) to be used for establishing an H-LSP which will be 
      used to carry service LSP(s) requiring specific TS type. 

 
 
Zhang                    Expires March 2012                   [Page 14] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   -  Support for LSP setup of new ODUk/ODUflex containers with related 
      mapping and multiplexing capabilities 

      New label should be defined to carry the exact TS allocation 
      information related to the extended mapping and multiplexing 
      hierarchy (For example, ODU0 into ODU2 multiplexing (with 1,25Gbps 
      TS granularity)), in order to setting up the ODU connection. 

   -  Support for Tributary Port Number allocation and negotiation 

      Tributary Port Number needs to be configured as part of the MSI 
      information (See more information in Section 3.1.2.1). A new 
      extension object has to be defined to carry TPN information if 
      control plane is used to configure MSI information. 

   -  Support for ODU Virtual Concatenation (VCAT) and Link Capacity 
      Adjustment Scheme (LCAS) 

      GMPLS signaling should support the creation of Virtual 
      Concatenation of ODUk signal with k=1, 2, 3. The signaling should 
      also support the control of dynamic capacity changing of a VCAT 
      container using LCAS ([G.7042]). [RFC6344] has a clear description 
      of VCAT and LCAS control in SONET/SDH and OTN networks. 

   -  Support for constraint signaling 

      How an ODUk connection service is transported within an operator 
      network is governed by operator policy. For example, the ODUk 
      connection service might be transported over an ODUk path over an 
      OTUk section, with the path and section being at the same rate as 
      that of the connection service. In this case, an entire lambda of 
      capacity is consumed in transporting the ODUk connection service. 
      On the other hand, the operator might leverage sub-lambda 
      multiplexing capabilities in the network to improve infrastructure 
      efficiencies within any given networking domain. In this case, 
      ODUk multiplexing may be performed prior to transport over various 
      rate ODU servers over associated OTU sections. 

      The identification of constraints and associated encoding in the 
      signaling for differentiating full lambda LSP or sub lambda LSP is 
      for further study.  

   -  Support for Control of Hitless Adjustment of ODUflex (GFP) 

      [G.7044] has been created in ITU-T to specify hitless adjustment 
      of ODUflex (GFP) (HAO) that is used to increase or decrease the 

 
 
Zhang                    Expires March 2012                   [Page 15] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

      bandwidth of an ODUflex (GFP) that is transported in an OTN 
      network. 

      The procedure of ODUflex (GFP) adjustment requires the 
      participation of every node along the path. Therefore, it is 
      recommended to use the control plane signaling to initiate the 
      adjustment procedure in order to avoid the manual configuration at 
      each node along the path. 

      Since the [G.7044] is being developed currently, the control of 
      HAO is for further study. 

   All the extensions above should consider the extensibility to match 
   future evolvement of OTN.  

    

5.3. Implications for GMPLS Routing 

   The path computation process should select a suitable route for an 
   ODUj connection request. In order to perform the path computation, it 
   must evaluate the available bandwidth on each candidate link.  The 
   routing protocol should be extended to convey some information to 
   represent ODU TE topology.   

   GMPLS Routing [RFC4202] defines Interface Switching Capability 
   Descriptor of TDM which can be used for ODU. However, some issues 
   discussed below, should also be considered. 

   Interface Switching Capability Descriptors present a new constraint   
   for LSP path computation. [RFC4203] defines the switching capability 
   and related Maximum LSP Bandwidth and the Switching Capability 
   specific information. When the Switching Capability field is TDM the 
   Switching Capability Specific Information field includes Minimum LSP 
   Bandwidth, an indication whether the interface supports Standard or 
   Arbitrary SONET/SDH, and padding. Hence a new Switching Capability 
   value needs to be defined for [G709-V3] ODU switching in order to 
   allow the definition of a new Switching Capability Specific 
   Information field definition. The following requirements should be 
   considered: 

   -  Support for carrying the link multiplexing capability 

       As discussed in section 3.1.2, many different types of ODUj can 
       be multiplexed into the same OTUk. For example, both ODU0 and 
       ODU1 may be multiplexed into ODU2. An OTU link may support one or 

 
 
Zhang                    Expires March 2012                   [Page 16] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

       more types of ODUj signals. The routing protocol should be 
       capable of carrying this multiplexing capability.  

   -  Support any ODU and ODUflex 

       The bit rate (i.e., bandwidth) of TS is dependent on the TS 
       granularity and the signal type of the link. For example, the 
       bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps, 
       while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729 
       Gbps.  

       One LO ODU may need different number of TSs when multiplexed into 
       different HO ODUs. For example, for ODU2e, 9 TSs are needed when 
       multiplexed into an ODU3, while only 8 TSs are needed when 
       multiplexed into an ODU4. For ODUflex, the total number of TSs to 
       be reserved in a HO ODU equals the maximum of [bandwidth of 
       ODUflex / bandwidth of TS of the HO ODU]. 

       Therefore, the routing protocol must be capable of carrying the 
       necessary and sufficient link bandwidth information for 
       performing accurate route computation for any of the fixed rate 
       ODUs as well as ODUflex. 

   -  Support for differentiating between terminating and switching 
      capability 

       Due to internal constraints and/or limitations, the type of 
       signal being advertised by an interface could be just switched 
       (i.e. forwarded to switching matrix without 
       multiplexing/demultiplexing actions), just terminated (demuxed) 
       or both of them. The capability advertised by an interface needs 
       further distinction in order to separate termination and 
       switching capabilities. 

       Therefore, to allow the required flexibility, the routing 
       protocol should clearly distinguish the terminating and switching 
       capability. 

   -  Support for Tributary Slot Granularity advertisement 

       [G709-V3] defines two types of TS but each link can only support a 
       single type at a given time. In order to perform a correct path 
       computation (i.e. the LSP end points have matching Tributary Slot 
       Granularity values) the Tributary Slot Granularity needs to be 
       advertised. 

   -  Support different priorities for resource reservation 
 
 
Zhang                    Expires March 2012                   [Page 17] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

       How many priorities levels should be supported depends on the 
       operator's policy. Therefore, the routing protocol should be 
       capable of supporting either no priorities or up to 8 priority 
       levels as defined in [RFC4202]. 

   -  Support link bundling 

       Link bundling can improve routing scalability by reducing the 
       amount of TE links that has to be handled by routing protocol. The 
       routing protocol must be capable of supporting bundling multiple 
       OTU links, at the same line rate and muxing hierarchy, between a 
       pair of nodes as a TE link. Note that link bundling is optional 
       and is implementation dependent. 

   -  Support for Control of Hitless Adjustment of ODUflex (GFP) 

       As described in Section 5.2, the routing requirements for 
       supporting hitless adjustment of ODUflex (GFP) (G.7044) are for 
       further study. 

   As mentioned in Section 5.1, one method of enabling multiplexing 
   hierarchy is via usage of dedicated boards to allow tunneling of new 
   services through legacy ODU1, ODU2, ODU3 containers. Such dedicated 
   boards may have some constraints with respect to switching matrix 
   access; detection and representation of such constraints is for 
   further study. 

5.4. Implications for Link Management Protocol (LMP) 

   As discussed in section 5.3, Path computation needs to know the 
   interface switching capability of links. The switching capability of 
   two ends of the link may be different, so the link capability of two 
   ends should be correlated.  

   The Link Management Protocol (LMP) [RFC4204] provides a control plane   
   protocol for exchanging and correlating link capabilities. 

   It is not necessary to use LMP to correlate link-end capabilities if 
   the information is available from another source such as management 
   configuration or automatic discovery/negotiation within the data 
   plane. 

   Note that LO ODU type information can be, in principle, discovered by 
   routing. Since in certain case, routing is not present (e.g. UNI case) 
   we need to extend link management protocol capabilities to cover this 
   aspect. In case of routing presence, the discovering procedure by LMP 
   could also be optional.  
 
 
Zhang                    Expires March 2012                   [Page 18] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   -  Correlating the granularity of the TS 

       As discussed in section 3.1.2, the two ends of a link may support 
       different TS granularity. In order to allow interconnection the 
       node with 1.25Gb/s granularity must fall back to 2.5Gb/s 
       granularity. 

       Therefore, it is necessary for the two ends of a link to 
       correlate the granularity of the TS. This ensures the correct use 
       and of the TE link. 

   -  Correlating the supported LO ODU signal types and multiplexing 
      hierarchy capability 

       Many new ODU signal types have been introduced in [G709-V3], such 
       as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment 
       does not support all the LO ODU signal types introduced by those 
       new standards or drafts. Furthermore, since multiplexing 
       hierarchy is not allowed before [G709-V3], it is possible that 
       only one end of an ODU link can support multiplexing hierarchy 
       capability, or the two ends of the link support different 
       multiplexing hierarchy capabilities (e.g., one end of the link 
       supports ODU0 into ODU1 into ODU3 multiplexing while the other 
       end supports ODU0 into ODU2 into ODU3 multiplexing). 

       For the control and management consideration, it is necessary for 
       the two ends of an HO ODU link to correlate which types of LO ODU 
       can be supported and what multiplexing hierarchy capabilities can 
       be provided by the other end.  

5.5. Implications for Path Computation Elements 

   [PCE-APS] describes the requirements for GMPLS applications of PCE in 
   order to establish GMPLS LSP. PCE needs to consider the GMPLS TE 
   attributes appropriately once a PCC or another PCE requests a path 
   computation. The TE attributes which can be contained in the path 
   calculation request message from the PCC or the PCE defined in 
   [RFC5440] includes switching capability, encoding type, signal type, 
   etc. 

   As described in section 5.2.1, new signal types and new signals with 
   variable bandwidth information need to be carried in the extended 
   signaling message of path setup. For the same consideration, PCECP 
   also has a desire to be extended to carry the new signal type and 
   related variable bandwidth information when a PCC requests a path 
   computation.  

 
 
Zhang                    Expires March 2012                   [Page 19] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

    

6. Data Plane Backward Compatibility Considerations  

   The node supporting 1.25Gbps TS can interwork with the other nodes 
   that supporting 2.5Gbps TS by combining Specific TSs together in data 
   plane. The control plane MUST support this TS combination.  

   Take Figure 5 as an example. Assume that there is an ODU2 link 
   between node A and B, where node A only supports the 2.5Gbps TS while 
   node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4 
   (where i<=4) of node B are combined together. When creating an ODU1 
   service in this ODU2 link, node B reserves the TS#i and TS#i+4 with 
   the granularity of 1.25Gbps. But in the label sent from B to A, it is 
   indicated that the TS#i with the granularity of 2.5Gbps is reserved. 
    

                                Path  
            +----------+   ------------>    +----------+  
            |     TS1==|===========\--------+--TS1     |  
            |     TS2==|=========\--\-------+--TS2     |  
            |     TS3==|=======\--\--\------+--TS3     |  
            |     TS4==|=====\--\--\--\-----+--TS4     |  
            |          |      \  \  \  \----+--TS5     |  
            |          |       \  \  \------+--TS6     |  
            |          |        \  \--------+--TS7     |  
            |          |         \----------+--TS8     |  
            +----------+   <------------    +----------+  
               node A           Resv           node B  
    
         Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS 
                                      
   In the contrary direction, when receiving a label from node A    
   indicating that the TS#i with the granularity of 2.5Gbps is reserved,    
   node B will reserved the TS#i and TS#i+4 with the granularity of    
   1.25Gbps in its control plane. 

7. Security Considerations 

   The use of control plane protocols for signaling, routing, and path 
   computation opens an OTN to security threats through attacks on those 
   protocols. The data plane technology for an OTN does not introduce 
   any specific vulnerabilities, and so the control plane may be secured 
   using the mechanisms defined for the protocols discussed. 

   For further details of the specific security measures refer to the 
   documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 
 
 
Zhang                    Expires March 2012                   [Page 20] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 
   security vulnerabilities and protection mechanisms for the GMPLS 
   control plane. 

8. IANA Considerations 

   This document makes not requests for IANA action. 

9. Acknowledgments 

   We would like to thank Maarten Vissers for his review and useful 
   comments. 

10. References 

10.1. Normative References 

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

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

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label 
               Switching (GMPLS) Signaling Resource ReserVation 
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 
               3473, January 2003. 

   [RFC4201]   K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS 
               Traffic Engineering (TE)", RFC 4201, October 2005. 

   [RFC4202]   K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 
               Support of Generalized Multi-Protocol Label Switching 
               (GMPLS)", RFC 4202, October 2005. 

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

   [RFC4205]   K. Kompella, Y. Rekhter, Ed., "Intermediate System to 
               Intermediate System (IS-IS) Extensions in Support of 
               Generalized Multi-Protocol Label Switching (GMPLS)", RFC 
               4205, October 2005. 

 
 
Zhang                    Expires March 2012                   [Page 21] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

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

   [RFC4206]   K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) 
               Hierarchy with Generalized Multi-Protocol Label Switching 
               (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 

   [RFC6107]   K. Shiomoto, A. Farrel, "Procedures for Dynamically 
               Signaled Hierarchical Label Switched Paths", RFC6107, 
               February 2011. 

   [RFC6001]   Dimitri Papadimitriou et al, "Generalized Multi-Protocol 
               Label Switching (GMPLS) Protocol Extensions for Multi-
               Layer and Multi-Region Networks (MLN/MRN)", RFC6001, 
               February 21, 2010. 

   [RFC5440]   JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 
               (PCE) Communication Protocol (PCEP)", RFC 5440, March 
               2009. 

   [RFC6344]   G. Bernstein et al, "Operating Virtual Concatenation 
               (VCAT) and the Link Capacity Adjustment Scheme (LCAS) 
               with Generalized Multi-Protocol Label Switching (GMPLS)", 
               RFC6344, August, 2011. 

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

10.2. Informative References 

   [G709-V1]   ITU-T, "Interface for the Optical Transport Network 
               (OTN)," G.709 Recommendation and Amendment1, November 
               2001. 

   [G709-V2]   ITU-T, "Interface for the Optical Transport Network 
               (OTN)," G.709 Recommendation, March 2003. 

   [G7042]     ITU-T G.7042/Y.1305, "Link capacity adjustment scheme 
               (LCAS) for virtual concatenated signals", March 2006. 

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

   [G872-Am2]  Draft Amendment 2, ITU-T, "Architecture of optical 
               transport networks". 

 
 
Zhang                    Expires March 2012                   [Page 22] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   [G.7044]    TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary 
               Meeting in Geneva, Initial draft G.7044 "Hitless 
               Adjustment of ODUflex (HAO)". 

   [HZang00]   H. Zang, J. Jue and B. Mukherjeee, "A review of routing 
               and wavelength assignment approaches for wavelength-
               routed optical WDM networks", Optical Networks Magazine, 
               January 2000. 

   [RFC6163]   Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 
               and PCE Control of Wavelength Switched Optical Networks 
               (WSON)", RFC6163, April 2011.  

   [PCE-APS]   Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 
               Zhang, "Requirements for GMPLS applications of PCE", 
               draft-ietf-pce-gmpls-aps-req-04.txt, May 30,2011. 

   [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS 
               Networks", Work in Progress, October 2009. 

    

    

11. Authors' Addresses 

   Fatai Zhang (editor)
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: huawei.danli@huawei.com

   Han Li
   China Mobile Communications Corporation
   53 A Xibianmennei Ave. Xuanwu District

Zhang                    Expires March 2012                   [Page 23] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 

   Beijing 100053 P.R. China

   Phone: +86-10-66006688
   Email: lihan@chinamobile.com

   Sergio Belotti
   Alcatel-Lucent
   Optics CTO
   Via Trento 30 20059 Vimercate (Milano) Italy
   +39 039 6863033

   Email: sergio.belotti@alcatel-lucent.it

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy
   Email: daniele.ceccarelli@ericsson.com

12. Contributors 

   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972913
   Email: hanjianrui@huawei.com

   Malcolm Betts
   Huawei Technologies Co., Ltd.

   Email: malcolm.betts@huawei.com

   Pietro Grandi
   Alcatel-Lucent
   Optics CTO
   Via Trento 30 20059 Vimercate (Milano) Italy
   +39 039 6864930

Zhang                    Expires March 2012                   [Page 24] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 

   Email: pietro_vittorio.grandi@alcatel-lucent.it

   Eve Varma
   Alcatel-Lucent
   1A-261, 600-700 Mountain Av
   PO Box 636
   Murray Hill, NJ  07974-0636
   USA
   Email: eve.varma@alcatel-lucent.com

APPENDIX A: ODU connection examples 

   This appendix provides a description of ODU terminology and 
   connection examples. This section is not normative, and is just 
   intended to facilitate understanding. 

   In order to transmit a client signal, an ODU connection must first be 
   created. From the perspective of [G709-V3] and [G872-Am2], some types 
   of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or 
   server role within the context of a particular networking domain:   

   (1) An ODUj client that is mapped into an OTUk server. For example, 
   if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is 
   mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing 
   perspective).  

   (2) An ODUj client that is mapped into an ODUk (j < k) server 
   occupying several TSs. For example, if ODU1 is multiplexed into ODU2, 
   and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a 
   HO ODU (from a multiplexing perspective).  

   Thus, a LO ODUj represents the container transporting a client of the 
   OTN that is either directly mapped into an OTUk (k = j) or 
   multiplexed into a server HO ODUk (k > j) container. Consequently, 
   the HO ODUk represents the entity transporting a multiplex of LO ODUj 
   tributary signals in its OPUk area. 

   In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 6 
   give an example of this kind of LO ODU connection. 

   In Figure 6, The LO ODUj is switched at the intermediate ODXC node. 
   OCh and OTUk are associated with each other. From the viewpoint of 

 
 
Zhang                    Expires March 2012                   [Page 25] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   connection management, the management of OTUk is similar with OCh. LO 
   ODUj and OCh/OTUk have client/server relationships.  

   For example, one LO ODU1 connection can be setup between Node A and 
   Node C. This LO ODU1 connection is to be supported by OCh/OTU1 
   connections, which are to be set up between Node A and Node B and 
   between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, 
   demapped from it in Node B, switched at Node B, and then mapped into 
   the next OTU1 and demapped from this OTU1 at Node C. 

    
      |                            LO ODUj                         | 
      +------------------------------(b)---------------------------+ 
      |      |      OCh/OTUk      |     |    OCh/OTUk        |     | 
      |      +--------(a)---------+     +--------(a)---------+     | 
      |      |                    |     |                    |     | 
     +------++-+                +--+---+--+                +-++------+ 
     |      |EO|                |OE|   |EO|                |OE|      | 
     |      +--+----------------+--+   +--+----------------+--+      | 
     |  ODXC   |                |  ODXC   |                |  ODXC   | 
     +---------+                +---------+                +---------+ 
      Node A                     Node B                     Node C 
    
                  Figure 6 - Connection of LO ODUj (1) 

   In the case of LO ODUj multiplexing into HO ODUk, Figure 7 gives an 
   example of this kind of LO ODU connection. 

   In Figure 7, OCh, OTUk, HO ODUk are associated with each other. The 
   LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 
   ODXC node and switched at each ODXC node (i.e. trib port to line port, 
   line card to line port, line port to trib port). From the viewpoint 
   of connection management, the management of these HO ODUk and OTUk 
   are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server 
   relationships. When a LO ODU connection is setup, it will be using 
   the existing HO ODUk (/OTUk/OCh) connections which have been set up. 
   Those HO ODUk connections provide LO ODU links, of which the LO ODU 
   connection manager requests a link connection to support the LO ODU 
   connection.  

   For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 
   Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be 
   setup between Node B and Node C. LO ODU1 can be generated at Node A, 
   switched to one of the 10G line ports and multiplexed into a HO ODU2 
   at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node 
   B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, 

 
 
Zhang                    Expires March 2012                   [Page 26] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

   demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 
   terminating port at Node C. 

       |                         LO ODUj                            | 
       +----------------------------(b)-----------------------------+ 
       |      |  OCh/OTUk/HO ODUk  |     | OCh/OTUk/HO ODUk   |     | 
       |      +--------(c)---------+     +---------(c)--------+     | 
       |      |                    |     |                    |     | 
      +------++-+                +--+---+--+                +-++------+ 
      |      |EO|                |OE|   |EO|                |OE|      | 
      |      +--+----------------+--+   +--+----------------+--+      | 
      |  ODXC   |                |  ODXC   |                |  ODXC   | 
      +---------+                +---------+                +---------+ 
        Node A                     Node B                     Node C 
      
                  Figure 7 - Connection of LO ODUj (2) 

    
    
 Intellectual Property 
 
   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr@ietf.org. 

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

 
 
Zhang                    Expires March 2012                   [Page 27] 


draft-ietf-ccamp-gmpls-g709-framework-05.txt             September 2011 
    

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

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

 
Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

 
Copyright Notice 
 
   Copyright (c) 2010 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 
   the Trust Legal Provisions and are provided without warranty as 
   described in the Simplified BSD License. 

 

 
 
Zhang                    Expires March 2012                   [Page 28]