Network Working Group                                        Fatai Zhang
Internet Draft                                                    Dan Li
Category: Informational                                           Huawei
                                                                  Han Li
                                                           D. Ceccarelli
Expires: January 12, April 21, 2011                                  July 12,                                 October 21, 2010

                 Framework for GMPLS and PCE Control of
                    G.709 Optical Transport Networks



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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 12, April 21, 2011.


   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
   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
   ODUj types and parameters......................6
         3.1.2. Multiplexing ODUj onto Links........................7
   Link Parameters................................8
   Tributary Port Number Assignment...............9 Structure of MSI information...................8
   4. Connection management in OTN.................................10 OTN..................................9
      4.1. Connection management of the ODU........................10
   5. GMPLS/PCE Implications.......................................13 Implications.......................................12
      5.1. Implications for LSP Hierarchy with GMPLS TE............13 TE............12
      5.2. Implications for GMPLS Signaling........................13
         5.2.1. Identifying OTN signals............................14
         5.2.2. Tributary Port Number..............................15
         5.2.3. Support for constraint signaling...................15
      5.3. Implications for GMPLS Routing..........................15
      5.4. Implications for Link Management Protocol (LMP).........17 (LMP).........18
         5.4.1. Correlating the Granularity of the TS..............18
         5.4.2. Correlating the Supported LO ODU Signal Types......18
      5.5. Implications for Path Computation Elements..............18 Elements..............19
   6. Security Considerations......................................19 Data Plane Backward Compatibility Considerations.............19
   7. IANA Considerations..........................................19 Security Considerations......................................20
   8. Acknowledgments..............................................19 IANA Considerations..........................................20
   9. References...................................................19
      9.1. Acknowledgments..............................................20
   10. References..................................................20
      10.1. Normative References....................................19
      9.2. References...................................20
      10.2. Informative References..................................21
   10. Authors' Addresses..........................................21 References.................................21
   11. Contributors................................................22 Authors' Addresses..........................................22
   12. Contributors................................................23
   APPENDIX A: ODU connection examples.............................23 examples.............................24

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
   [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]. No additional Switching
   Type and LSP Encoding Type are required to support the control of the
   evolved OTN, because the Switching Type and LSP Encoding Type defined
   in [RFC4328] are still applicable.

   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 [WSON-
   Frame] 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.

   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

                               Client signal

                   Figure 1 - Basic OTN signal hierarchy

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


   |      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   | client signal bit rate tolerance, |
   |   Client signals      |    with a maximum of+-100 ppm     |
   |                       |                                   |
   |  ODUflex for GFP-F    |                                   |
   | Mapped client signal  |            +- 20 ppm              |
   |      signal       |                                      |
                     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 +/- 20ppm, and
      the bit rate should be determined by the node that performs the
      mapping. ODUj types and parameters

   When ODUj connections are setup, two types

   [Editors' Note: As outcome of information should be
   conveyed ITU SG15/q11 expert meeting held in
   Vimercate in September 2010 it was decided that a connection request:

   (a) End to end:
   Client payload type (e.g. STM64; Ethernet etc.)
   Bit rate and tolerance:  Note for j = 0, 1, 2, 2e, 3, 4 this
   information may be carried as an enumerated type.  For resizable
   ODUflex(GFP) occupies the ODUflex same number of TS on every link of the actual bit rate and tolerance must be provided.

   (b) Hop by hop: path
   (independently of the High Order (HO) OPUk TS assignment rate). Please see WD07
   and port number carried by the Multiplex Structure
   Identifier (MSI) bytes meeting report of this meeting for more information.

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

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 OPU.  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 OTUk.  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

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

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

   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]. Link Parameters

   Per [RFC4201], each OTU can be treated as a component link Structure of MSI information

   When multiplexing an ODUj into a link
   bundle. The available capacity between nodes is the sum of the
   available capacity on HO ODUk (k>j), G.709 specifies the OTUs
   information that interconnect the nodes. has to be transported in-band in order to allow for
   correct demultiplexing. This
   total capacity is represented information, known as Multiplex
   Structure Information (MSI), is transported in the capacity OPUk overhead and
   is local to each link. In case of a link bundle.

   Note that there will typically be more than one OTU bidirectional paths the association
   between a pair of
   nodes so that TPN and TS MUST be the available capacity will typically be distributed
   across multiple OTUs. Thus, same in order to be able to determine the
   maximum payload that can be carried on a bundled link, the link state
   advertisement must also provide the largest number of TSes available
   on any one component OTU.

   In order to compute the lowest cost path for a ODUj connection
   request the critical parameters that need to be provided (for the
   purposes of routing) are:

   -  Number of TS

   -  Maximum number of TS available for a LSP (i.e., Maximum LSP

   -  Bit rate of the TS. (Note: This may be efficiently encoded as a
      two integers representing the value of k and the granularity.) Tributary Port Number Assignment

   When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the both directions.

   The MSI 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 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.

   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 OPU3 OPU (e.g., OPU3) overhead by the
     source of the HO ODUk trail is checked by the sink of the HO ODUk trail. G.709 default
   behavior requires
     The expectedMSI information that is used to check the multiplexing structure of acceptedMSI
     information. The acceptedMSI information is the HO ODUk be
   provided by means of pre-provisioned MSI information, termed
   expectedMSI. valued received
     in-band, after a 3 frames integration

   The sink of the HO ODU trail checks the complete content of the MSI
   acceptedMSI information (including the TPN) that was received in-band,
   termed acceptedMSI, against (against the expectedMSI.
   If the acceptedMSI is different from the expectedMSI, then the
   traffic is dropped and a payload mismatch alarm is generated.

   Note that the values

   Provisioning of the TPN MUST can be performed either agreed between the
   source and the sink of by network management
   system or control plane. In the HO ODU trail either via last case, control plane
   signaling or provisioning by is also
   responsible for negotiating the management plane. provisioned values on a link by link

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 [WSON-FRAME].

   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

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

   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
           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 to 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 framework 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 [RFC4206bis] define the
   mechanisms to accomplish creating the hierarchy of LSPs. The LSP
   management of multiple layers in OTN can follow the procedures
   defined in [RFC4206], [RFC4206bis] and related MLN drafts.

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

   For the ODU layers, in order 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), it may be needed to consider introducing multi-stage
   multiplexing capability in specific network transition scenarios. One
   method for enabling multi-stage multiplexing 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 connection, which
   forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis]
   and [MLN-EXT] (including related modifications, if needed) are
   relevant to connection set up.

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 2, 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.

5.2.1. Identifying OTN signals

   [RFC4328] defines the LSP Encoding Type, the Switching Type and the
   Generalized Protocol Identifier (Generalized-PID) constituting the
   common part of the Generalized Label Request. The G.709 Traffic
   Parameters are also defined in [RFC4328].  The following new signal
   types have been added signaling
   aspects should be considered additionally since [RFC4328] was

   (1) New

   -  Support for specifying the new signal types of sub-lambda layer

      Optical and the related
      traffic information
      THE traffic parameters should be extended in signaling message to
      support the new optical Channel Data Unit (ODUj): (ODUj) including:

         -  ODU0
         -  ODU2e
         -  ODU4
         -  ODUflex

   (2) A new TS granularity (i.e., 1.25 Gbps)

   (3) Signal type with variable bandwidth:


      For ODUflex, since it has a variable bandwidth/bit rate BR and a
      bit rate tolerance T. As described above 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.

   (4) Extended multiplexing hierarchy (For example, ODU0 into OTU2
       multiplexing (with 1,25Gbps TS granularity).)

   So the encoding provided in [RFC4328] needs to be extended to support
   all the

      For other ODU signal types and related mapping types, the bit rates and multiplexing with all
   kinds tolerances of TSs. Moreover, them
      are fixed and can be deduced from the extensions signal types.

   -  Support for LSP setup using different Tributary Slot granularity

      New label should consider the
   extensibility be defined to match future evolvement identify the type of OTN.

   For item (1) TS (i.e., the
      2.5 Gbps TS granularity and (3), the new traffic parameters may need to be extended
   in signaling message;
   For item (2) and (4), 1.25 Gbps TS granularity).

   -  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

5.2.2. (with 1,25Gbps
      TS granularity)), in order to setting up the ODU connection.

   -  Support for Tributary Port Number

   The tributary port number may allocation and negotiation

      Tributary Port Number needs to be assigned locally by the node at the
   (traffic) ingress end configured as part of the link and MSI
      information (See more information in this case as described above
   must Section A new
      extension object has to be conveyed defined to the far end of the link as a "transparent"
   parameter i.e. the carry TPN information if
      control plane does not need is used to understand this configure MSI information. The TPN may also be assigned by the control plane when
   establishing LSP.


   -  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.HAO] has been created in ITU-T to specify hitless adjustment of
      ODUflex (GFP) (HAO) that is used to increase or decrease the
      bandwidth of an ODUflex (GFP) that is transported in an OTN

      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.HAO] 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 a
   ODUj connection request. In order to compute the lowest cost path it
   must evaluate the number (and availability) of TSs available bandwidth on each candidate link.  The
   routing protocol should be extended to convey some information to
   represent ODU TE topology.  As described above the
   number of TSs (on a link bundle), the bandwidth of the TS and the
   maximum number that are available to convey a single ODUj must be

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

   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. So routing protocol should be
   extended when TDM is ODU type to support representation of ODU
   switching information, especially 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
       more types of ODUj signals. The routing protocol should be
       capable of carrying this multiplexing capability.

   -  Support for carrying the TS granularity that the interface can

       One type of ODUj can be multiplexed to an OTUk using different TS
       granularity. For example, ODU1 can be multiplexed into ODU2 with
       either 2.5Gbps TS granularity or 1.25G TS granularity. The
       routing protocol should be capable of carrying the TS granularity
       supported by the ODU interface.

   -  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

       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 link multiplexing capacity and
      link rate capacity
       When a network operator receives a request for a particular ODU
       connection service, the operator governs the manner in which the
       request is fulfilled in their network. Considerations include
       deployed network infrastructure capabilities, associated policies
       (e.g., at what link fill threshold should a particular higher-
       rate ODUk be utilized), etc. Thus, for example, an ODU2
       connection service request could be supported by: OTU2 links
       (here the connection service rate is the same as the link rate),
       a combination of OTU2 and OTU3 links, OTU3 links, etc.

       Therefore, to allow the required flexibility, the routing
       protocol should be capable of differentiating between these two
       types of link capacity. routing
       protocol should clearly distinguish the capacity that is
       multiplexed in an ODUk that in turn is adapted in an OTUk from
       the ODUk capacity that is switched in matrix and directly adapted
       in an OTUk without further multiplexing.

   -  Support different priorities for resource reservation

       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 or different line rates, 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) (HAO) are for
       further study.

   As mentioned in Section 5.1, one method of enabling multi-stage
   multiplexing 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

   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.

5.4.1. 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 that both ends of the link
   advertise consistent capabilities (for routing) and ensures that
   viable connections are established.

5.4.2.  Correlating the Supported LO ODU Signal Types

   Many new ODU signal types have been introduced [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. If one end of a link can not support a certain LO ODU
   signal type, the link cannot be selected to carry such type of LO ODU

   Therefore, it is necessary for the two ends of an HO ODU link to
   correlate which types of LO ODU can be supported by the link. After
   correlating, the capability information can be flooded by IGP, so
   that the correct path for an ODU connection can be calculated.

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,

   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

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.

            +----------+   ------------>    +----------+
            |     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],
   [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


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.

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

   [RFC4206bis] K. Shiomoto, A. Farrel, "Procedures for Dynamically
               Signaled Hierarchical Label Switched Paths", draft-ietf-
               ccamp-lsp-hierarchy-bis-08.txt, February 2010.

   [MLN-EXT]   Dimitri Papadimitriou et al, "Generalized Multi-Protocol
               Label Switching (GMPLS) Protocol Extensions for Multi-
               Layer and Multi-Region Networks (MLN/MRN)", draft-ietf-
               ccamp-gmpls-mln-extensions-12.txt, February 21, 2010.

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

   [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

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

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

   [G.HAO]    TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary
               Meeting in Geneva, Initial draft G.hao "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.

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

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

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


11. Authors' Addresses

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

   Phone: +86-755-28972912

   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
   Han Li
   China Mobile Communications Corporation
   53 A Xibianmennei Ave. Xuanwu District
   Beijing 100053 P.R. China

   Phone: +86-10-66006688

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



   Daniele Ceccarelli
   Via A. Negrone 1/A
   Genova - Sestri Ponente

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

   Malcolm Betts
   Huawei Technologies Co., Ltd.


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


   Eve Varma
   1A-261, 600-700 Mountain Av
   PO Box 636
   Murray Hill, NJ  07974-0636

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

   (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 5 6
   give an example of this kind of LO ODU connection.

   In Figure 5, 6, The LO ODUj is switched at the intermediate ODXC node.
   OCh and OTUk are associated with each other. From the viewpoint of
   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                         |
      |      |      OCh/OTUk      |     |    OCh/OTUk        |     |
      |      +--------(a)---------+     +--------(a)---------+     |
      |      |                    |     |                    |     |
     +------++-+                +--+---+--+                +-++------+
     |      |EO|                |OE|   |EO|                |OE|      |
     |      +--+----------------+--+   +--+----------------+--+      |
     |  ODXC   |                |  ODXC   |                |  ODXC   |
     +---------+                +---------+                +---------+
      Node A                     Node B                     Node C

                  Figure 5 6 - Connection of LO ODUj (1)

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

   In Figure 6, 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

   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,
   demultiplexed from HO ODU3 at Node C and switched to its LO ODU1
   terminating port at Node C.

       |                         LO ODUj                            |
       |      |  OCh/OTUk/HO ODUk  |     | OCh/OTUk/HO ODUk   |     |
       |      +--------(c)---------+     +---------(c)--------+     |
       |      |                    |     |                    |     |
      +------++-+                +--+---+--+                +-++------+
      |      |EO|                |OE|   |EO|                |OE|      |
      |      +--+----------------+--+   +--+----------------+--+      |
      |  ODXC   |                |  ODXC   |                |  ODXC   |
      +---------+                +---------+                +---------+
        Node A                     Node B                     Node C

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

   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

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

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