CCAMP Working Group                                      S. Belotti, Ed.
Internet-Draft                                                 P. Grandi
Intended status: Informational                            Alcatel-Lucent
Expires: March 24, 2012                               D. Ceccarelli, Ed.
                                                             D. Caviglia
                                                                Ericsson
                                                                F. Zhang
                                                                   D. Li
                                                     Huawei Technologies
                                                      September 21, 2011


      Information model for G.709 Optical Transport Networks (OTN)
                draft-ietf-ccamp-otn-g709-info-model-01

Abstract

   The recent revision of ITU-T recommendation G.709 [G.709-v3] has
   introduced new fixed and flexible ODU containers in Optical Transport
   Networks (OTNs), enabling optimized support for an increasingly
   abundant service mix.

   This document provides a model of information needed by the routing
   and signaling process in OTNs to support Generalized Multiprotocol
   Label Switching (GMPLS) control of all currently defined ODU
   containers.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

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

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Belotti, et al.          Expires March 24, 2012                 [Page 1]


Internet-Draft       Information model for G.709 OTN      September 2011


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  OSPF-TE requirements overview  . . . . . . . . . . . . . . . .  4
   3.  RSVP-TE requirements overview  . . . . . . . . . . . . . . . .  5
   4.  G.709 Digital Layer Info Model for Routing and Signaling . . .  5
     4.1.  Tributary Slot Granularity . . . . . . . . . . . . . . . .  8
       4.1.1.  Fall-back procedure  . . . . . . . . . . . . . . . . . 10
     4.2.  Tributary Port Number  . . . . . . . . . . . . . . . . . . 11
     4.3.  Signal type  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Bit rate and tolerance . . . . . . . . . . . . . . . . . . 13
     4.5.  Unreserved Resources . . . . . . . . . . . . . . . . . . . 13
     4.6.  Maximum LSP Bandwidth  . . . . . . . . . . . . . . . . . . 13
     4.7.  Distinction between terminating and switching
           capability . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.8.  Priority Support . . . . . . . . . . . . . . . . . . . . . 16
     4.9.  Multi-stage multiplexing . . . . . . . . . . . . . . . . . 16
     4.10. Generalized Label  . . . . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19













Belotti, et al.          Expires March 24, 2012                 [Page 2]


Internet-Draft       Information model for G.709 OTN      September 2011


1.  Introduction

   GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC),
   Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN),
   Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g.,
   incoming port or fiber to outgoing port or fiber).

   The establishment of LSPs that span only interfaces recognizing
   packet/cell boundaries is defined in [RFC3036, RFC3212, RFC3209].
   [RFC3471] presents a functional description of the extensions to
   Multi-Protocol Label Switching (MPLS) signaling required to support
   GMPLS.  ReSource reserVation Protocol-Traffic Engineering (RSVP-TE)
   -specific formats,mechanisms and technology specific details are
   defined in [RFC3473].

   From a routing perspective, Open Shortest Path First-Traffic
   Engineering (OSPF-TE) generates Link State Advertisements (LSAs)
   carrying application-specific information and floods them to other
   nodes as defined in [RFC5250].  Three types of opaque LSA are
   defined, i.e. type 9 - link-local flooding scope, type 10 - area-
   local flooding scope, type 11 - AS flooding scope.

   Type 10 LSAs are composed of a standard LSA header and a payload
   including one top-level TLV and possible several nested sub-TLVs.
   [RFC3630] defines two top-level TLVs: Router Address TLV and Link
   TLV; and nine possible sub-TLVs for the Link TLV, used to carry link
   related TE information.  The Link type sub-TLVs are enhanced by
   [RFC4203] in order to support GMPLS networks and related specific
   link information.  In GMPLS networks each node generates TE LSAs to
   advertise its TE information and capabilities (link-specific or node-
   specific)through the network.  The TE information carried in the LSAs
   are collected by the other nodes of the network and stored into their
   local Traffic Engineering Databases (TED).

   In a GMPLS enabled G.709 Optical Transport Networks (OTN), routing
   and signaling are fundamental in order to allow automatic calculation
   and establishment of routes for ODUk LSPs.  The recent revision of
   ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and
   flexible ODU containers that augment those specified in foundation
   OTN.  As a result, it is necessary to provide OSPF-TE and RSVP-TE
   extensions to allow GMPLS control of all currently defined ODU
   containers.

   This document provides the information model needed by the routing
   and signaling processses in OTNs to allow GMPLS control of all
   currently defined ODU containers.

   OSPF-TE and RSVP-tE requirements are defined in [OTN-FWK], while



Belotti, et al.          Expires March 24, 2012                 [Page 3]


Internet-Draft       Information model for G.709 OTN      September 2011


   protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  OSPF-TE requirements overview

   [OTN-FWK] provides a set of functional routing requirements
   summarized below :

      - Support for link multiplexing capability advertisement: The
      routing protocol has to be able to carry information regarding the
      capability of an OTU link to support different type of ODUs

      - Support of any ODUk and ODUflex: The routing protocol must be
      capable of carrying the required link bandwidth information for
      performing accurate route computation for any of the fixed rate
      ODUs as well as ODUflex.

      - Support for differentiation between switching and terminating
      capacity

      - Support for the client server mappings as required by
      [G.7715.1].  The list of different mappings methods is reported in
      [G.709-v3].  Since different methods exist for how the same client
      layer is mapped into a server layer, this needs to be captured in
      order to avoid the set-up of connections that fail due to
      incompatible mappings.

      - Support different priorities for resource reservation.  How many
      priorities levels should be supported depends on operator
      policies.  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 of component links at the same line rate
      and with same muxing hierarchy.

      - Support for Tributary Slot Granularity (TSG) advertisement.








Belotti, et al.          Expires March 24, 2012                 [Page 4]


Internet-Draft       Information model for G.709 OTN      September 2011


3.  RSVP-TE requirements overview

   [OTN-FWK] also provides a set of functional signaling requirements
   summarized below :

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

      - Support for LSP setup using different Tributary Slot granularity

      - Support for Tributary Port Number allocation and negoziation

      - Support for constraint signaling

      - Support for TSG signaling


4.  G.709 Digital Layer Info Model for Routing and Signaling

   The digital OTN layered structure is comprised of digital path layer
   networks (ODU) and digital section layer networks (OTU).  An OTU
   section layer supports one ODU path layer as client and provides
   monitoring capability for the OCh.  An ODU path layer may transport a
   heterogeneous assembly of ODU clients.  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.  ITU-T G.872
   recommendation provides two tables defining mapping and multiplexing
   capabilities of OTNs, which are reproduced below.























Belotti, et al.          Expires March 24, 2012                 [Page 5]


Internet-Draft       Information model for G.709 OTN      September 2011


         +--------------------+--------------------+
         |     ODU client     |     OTU server     |
         +--------------------+--------------------+
         |        ODU 0       |          -         |
         +--------------------+--------------------+
         |        ODU 1       |        OTU 1       |
         +--------------------+--------------------+
         |        ODU 2       |        OTU 2       |
         +--------------------+--------------------+
         |        ODU 2e      |          -         |
         +--------------------+--------------------+
         |        ODU 3       |        OTU 3       |
         +--------------------+--------------------+
         |        ODU 4       |        OTU 4       |
         +--------------------+--------------------+
         |        ODU flex    |          -         |
         +--------------------+--------------------+


                     Figure 1: OTN mapping capability































Belotti, et al.          Expires March 24, 2012                 [Page 6]


Internet-Draft       Information model for G.709 OTN      September 2011


       +=================================+=========================+
       |           ODU client            |       ODU server        |
       +---------------------------------+-------------------------+
       |        1,25 Gbps client         |                         |
       +---------------------------------+          ODU 0          |
       |                 -               |                         |
       +=================================+=========================+
       |         2,5 Gbps client         |                         |
       +---------------------------------+          ODU 1          |
       |              ODU 0              |                         |
       +=================================+=========================+
       |         10 Gbps client          |                         |
       +---------------------------------+          ODU 2          |
       |        ODU0,ODU1,ODUflex        |                         |
       +=================================+=========================+
       |        10,3125 Gbps client      |                         |
       +---------------------------------+          ODU 2e         |
       |                 -               |                         |
       +=================================+=========================+
       |         40 Gbps client          |                         |
       +---------------------------------+          ODU 3          |
       |  ODU0,ODU1,ODU2,ODU2e,ODUflex   |                         |
       +=================================+=========================+
       |        100 Gbps client          |                         |
       +---------------------------------+          ODU 4          |
       |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex|                         |
       +=================================+=========================+
       |CBR clients from greater than    |                         |
       |2.5 Gbit/s to 100 Gbit/s: or     |                         |
       |GFP-F mapped packet clients from |          ODUflex        |
       |1.25 Gbit/s to 100 Gbit/s.       |                         |
       +---------------------------------+                         |
       |                 -               |                         |
       +=================================+=========================+



                   Figure 2: OTN multiplexing capability

   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 (see Table 1).  In this case, an
   entire lambda of capacity is consumed in transporting the ODUk
   connection service.  On the other hand, the operator might exploit
   different multiplexing capabilities in the network to improve
   infrastructure efficiencies within any given networking domain.  In



Belotti, et al.          Expires March 24, 2012                 [Page 7]


Internet-Draft       Information model for G.709 OTN      September 2011


   this case, ODUk multiplexing may be performed prior to transport over
   various rate ODU servers (as per Table 2) over associated OTU
   sections.

   From the perspective of multiplexing relationships, a given ODUk may
   play different roles as it traverses various networking domains.

   As detailed in [OTN-FWK], client ODUk connection services can be
   transported over:

      o Case A) one or more wavelength sub-networks connected by optical
      links or

      o Case B) one or more ODU links (having sub-lambda and/or lambda
      bandwidth granularity)

      o Case C) a mix of ODU links and wavelength sub-networks.

   This document considers the TE information needed for ODU path
   computation and parameters needed to be signaled for LSP setup.

   The following sections list and analyze each type of data that needs
   to be advertised and signaled in order to support path computation
   and LSP setup.

4.1.  Tributary Slot Granularity

   ITU-T recommendations define two types of TS but each link can only
   support a single type at a given time.  The rules to be followed when
   selecting the TS to be used are:

      - If both ends of a link can support both 2.5Gbps TS and 1.25Gbps
      TS, then the link will work with 1.25Gbps TS.

      - If one end can support the 1.25Gbps TS, and another end the
      2.5Gbps TS, the link will work with 2.5Gbps TS.

   The tributary slot type information is one of the parameters needed
   to correctly configure physical interfaces.  When setting up and HO-
   ODUk/OTUk LSP or an H-LSP/FA, the penultimate node of the path might
   need to choose among interfaces supporting 1,25 Gbps or 2,5 Gbps.
   The choice depends on the type of client signal (e.g. an ODU0 can
   only be supported by 1.25Gbps TSG) and this information needs to be
   carried in the signaling messages.

   In order to carry the tributary slot granularity information, an
   object that can be examinded by the penultimate hop and terminated
   just by the end nodes of the path is needed.  The utilization of the



Belotti, et al.          Expires March 24, 2012                 [Page 8]


Internet-Draft       Information model for G.709 OTN      September 2011


   label is not the correct choice as it can be changed hop by hop.  One
   possible solution is the G-PID field of the GENERALIZED LABEL REQUEST
   Object.  The following table shows the different mapping
   possibilities depending on the TSG types.  The client types are shown
   in the left column, while the different OPUk server and related TSGs
   are listed in the top row.


                 +------------------------------------------------+
                 |    2.5G TS    ||          1.25G TS             |
                 | OPU2  | OPU3  || OPU1  | OPU2  | OPU3  | OPU4  |
         +-------+------------------------------------------------+
         |       |   -   |   -   ||  AMP  |  GMP  |  GMP  |  GMP  |
         | ODU0  |       |       || PT=20 | PT=21 | PT=21 | PT=21 |
         +-------+------------------------------------------------+
         |       |  AMP  |  AMP  ||   -   |  AMP  |  AMP  |  GMP  |
         | ODU1  | PT=20 | PT=20 ||       | PT=21 | PT=21 | PT=21 |
         +-------+------------------------------------------------+
         |       |   -   |  AMP  ||   -   |   -   |  AMP  |  GMP  |
         | ODU2  |       | PT=20 ||       |       | PT=21 | PT=21 |
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |   -   |  GMP  |  GMP  |
         | ODU2e |       |       ||       |       | PT=21 | PT=21 |
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |   -   |   -   |  GMP  |
         | ODU3  |       |       ||       |       |       | PT=21 |
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |  GMP  |  GMP  |  GMP  |
         | ODUfl |       |       ||       | PT=21 | PT=21 | PT=21 |
         +-------+------------------------------------------------+


                  Figure 3: ODUj into OPUk mapping types

   The G-PID value defined in [RFC 4328] is associated to the mapping
   with 2.5Gbps TSG type (G-PID = 47).  A new G-PID value has to be
   defined (TBA by IANA) in order to cover the mapping on 1.25Gbps TSG
   type.

   The G-PID information is not enough to have a complete choice since
   the penultimate hop node has to distinguish between interfaces with
   the same TSG (e.g. 1.25Gbps) whether the interface is able to support
   the right hierarchy, i.e. it is possible to have two interfaces both
   at 1.25 TSG but only one is supporting ODU0.

   A dedicated optional object should to be defined in order to carry
   the multiplexing hierarchy and have a more precise choice capability.
   In this way, when the penultimate node receives the GENERALIZED LABEL



Belotti, et al.          Expires March 24, 2012                 [Page 9]


Internet-Draft       Information model for G.709 OTN      September 2011


   REQUEST Object, the G-PID value together with the ODU bandwdith
   included into the Traffic Parameters Object allow desuming the
   correct TSG value.

   As an example it is possible to consider the setup of an ODU3 path
   that is going to carry an ODU0.  In this case it is needed the
   support of 1,25 GBps TS.  The information related to the TSG is
   carried via the G-PID and node C, having two different interfaces
   toward D with different TSG, can choose the right one as depicted in
   the following figure.


                                ODU0
               ________________________________________
               |                                      |
      +--------+      +--------+      +--------+      +--------+
      |        |      |        |      |        | 1.25 |        |
      |  Node  |      |  Node  |      |  Node  +------+  Node  |
      |   A    +------+   B    +------+   C    | ODU3 |   D    |
      |        | ODU3 |        | ODU3 |        +------+        |
      +--------+ 1.25 +--------+ 1.25 +--------+ 2.5  +--------+



                        Figure 4: TSG in signaling

   The TSG information is needed also in the routing protocol as the
   ingress node (A in the previous example) needs to know if the
   interfaces between C and D can support the required TSG.  In case
   they cannot, A will compute an alternate path from itself to D.

   In a multi-stage multiplexing environment any layer can have a
   different TSG structure, e.g. in a multiplexing hierarchy like
   ODU0->ODU2->ODU3, the ODU3 can be structured at TSG=2.5 in order to
   support an ODU2 connection, but this ODU2 connection can be a tunnel
   for ODU0, and hence structured with 1.25 TSG.  Therefore any
   multiplexing level has to advertise his TSG capabilities in order to
   allow a correct path computation by the end nodes (both of the ODUk
   trail and of the H-LSP/FA).

4.1.1.  Fall-back procedure

   SG15 ITU-T G.798 recommendation describes the so called PT=21-to-
   PT=20 interworking process that explains how two equipments with
   interfaces with different PayloadType, and hence different TS
   granularity (1.25Gbps vs. 2.5Gbps), can be coordinated so to permit
   the equipment with 1.25 TS granularity to adapt his TS allocation
   accordingly to the different TS granularity (2.5Gbps) of a neighbour.



Belotti, et al.          Expires March 24, 2012                [Page 10]


Internet-Draft       Information model for G.709 OTN      September 2011


   Therefore, in order to let the NE change TS granularity accordingly
   to the nieghbour requirements, the AUTOpayloadtype needs to be set.
   When both the neighbors (link or trail) have been configured as
   structured, the payload type received in the overhead is compared to
   the transmitted PT.  If they are different and the transmitted PT=21,
   the node must fallback to PT=20.  In this case the fall-back process
   makes the system self consistent and the only reason for signaling
   the TS granularity is to provide the correct label (i.e. label for
   PT=21 has twice the TS number of PT=20).  On the other side, if the
   AUTOpayloadtype is not configured, the RSVP-TE consequent actions in
   case of TS mismatch need to be defined.

4.2.  Tributary Port Number

   [RFC4328] supports only the deprecated auto-MSI mode which assumes
   that the Tributary Port Number is automatically assigned in the
   transmit direction and not checked in the receive direction.

   As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk
   frame contains n (n = the total number of TSs of the ODUk) MSI
   (Multiplex Structure Identifier) bytes (in the form of multi-frame),
   each of which is used to indicate the association between tributary
   port number and tributary slot of the ODUk.

   The association between TPN and TS has to be configured by the
   control plane and checked by the data plane on each side of the link.
   (Please refer to [OTN-FWK] for further details).  As a consequence,
   the RSVP-TE signaling needs to be extended to support the TPN
   assignment function.

4.3.  Signal type

   From a routing perspetive, [RFC 4203] allows advertising foundation
   G.709 (single TS type) without the capability of providing precise
   information about bandwidth specific allocation.  For example, in
   case of link bundling, dividing the unreserved bandwidth by the MAX
   LSP bandwidth it is not possible to know the exact number of LSPs at
   MAX LSP bandwidth size that can be set up. (see example fig. 3)

   The lack of spatial allocation heavily impacts the restoration
   process, because the lack of information of free resources highly
   increases the number of crank-backs affecting network convergence
   time.

   Moreover actual tools provided by OSPF-TE only allow advertising
   signal types with fixed bandwidth and implicit hierarchy (e.g.  SDH/
   SONET networks) or variable bandwidth with no hierarchy (e.g. packet
   switching networks) but do not provide the means for advertising



Belotti, et al.          Expires March 24, 2012                [Page 11]


Internet-Draft       Information model for G.709 OTN      September 2011


   networks with mixed approach (e.g.  ODUflex CBR and ODUflex packet).

   For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX
   LSP bandwidth it is not possible to state whether the advertised link
   supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and
   ODUflex.  Such ambiguity is not present in SDH networks where the
   hierarchy is implicit and flexible containers like ODUFlex do not
   exist.  The issue could be resolved by declaring 1 ISCD for each
   signal type actually supported by the link.

   Supposing for example to have an equivalent ODU2 unreserved bandwidth
   in a TE-link (with bundling capability) distributed on 4 ODU1, it
   would be advertised via the ISCD in this way:

      MAX LSP Bw: ODU1

      MIN LSP Bw: ODU1

      - Maximum Reservable Bandwidth (of the bundle) set to ODU2

      - Unreserved Bandwidth (of the bundle) set to ODU2

   Moreover with the current IETF solutions, ([RFC4202], [RFC4203]) as
   soon as no bandwidth is available for a certain signal type it is not
   advertised into the related ISCD, losing also the related capability
   until bandwidth is freed.

   In conclusion, the OSPF-TE extensions defined in [RFC4203] require a
   different ISCD per signal type in order to advertise each supported
   container.  This motivates attempting to look for a more optimized
   solution, without proliferations of the number of ISCD advertised.
   The OSPF LSA is required to stay within a single IP PDU;
   fragmentation is not allowed.  In a conforming Ethernet environment,
   this limits the LSA to 1432 bytes (Packet_MTU (1500 Bytes) -
   IP_Header (20 bytes) - OSPF_Header (28 bytes) - LSA_Header (20
   bytes)).

   With respect to link bundling, the utilization of the ISCD as it is,
   would not allow precise advertising of spatial bandwidth allocation
   information unless using only one component link per TE link.

   On the other hand, from a singaling point of view, [RFC4328]
   describes GMPLS signaling extensions to support the control for G.709
   OTNs [G709-V1].  However,[RFC4328] needs to be updated because it
   does not provide the means to signal all the new signal types and
   related mapping and multiplexing functionalities.





Belotti, et al.          Expires March 24, 2012                [Page 12]


Internet-Draft       Information model for G.709 OTN      September 2011


4.4.  Bit rate and tolerance

   In the current traffic parameters signaling, bit rate and tolerance
   are implicitly defined by the signal type.  ODUflex CBR and Packet
   can have variable bit rates and tolerances (please refer to [OTN-FWK]
   table 2); it is thus needed to upgrade the signaling traffic
   patameters so to specify requested bit rates and tolerance values
   during LSP setup.

4.5.  Unreserved Resources

   Unreserved resources need to be advertised per priority and per
   signal type in order to allow the correct functioning of the
   restoration process.  [RFC4203] only allows advertising unreserved
   resources per priority, this leads not to know how many LSPs of a
   specific signal type can be restored.  As example it is possible to
   consider the scenario depicted in the following figure.


                  +------+ component link 1 +------+
                  |      +------------------+      |
                  |      | component link 2 |      |
                  |  N1  +------------------+  N2  |
                  |      | component link 3 |      |
                  |      +------------------+      |
                  +------+                  +---+--+


                   Figure 5: Concurrent path computation

   Suppose to have a TE link comprising 3 ODU3 component links with
   32TSs available on the first one, 24TSs on the second, 24TSs on the
   third and supporting ODU2 and ODU3 signal types.  The node would
   advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX
   LSP bandwidth equal to 32 TSs.  In case of restoration the network
   could try to restore 2 ODU3 (64TSs) in such TE-link while only a
   single ODU3 can be set up and a crank-back would be originated.  In
   more complex network scenarios the number of crank-backs can be much
   higher.

4.6.  Maximum LSP Bandwidth

   Maximum LSP bandwidth is currently advertised in the common part of
   the ISCD and advertised per priority, while in OTN networks it is
   only required for ODUflex advertising.  This leads to a significant
   waste of bits inside each LSA.





Belotti, et al.          Expires March 24, 2012                [Page 13]


Internet-Draft       Information model for G.709 OTN      September 2011


4.7.  Distinction between terminating and switching capability

   The capability advertised by an interface needs further distinction
   in order to separate termination and switching capabilities.  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 following figures help
   explainig the switching and terminating capabilities.



             MATRIX                   LINE INTERFACE
       +-----------------+          +-----------------+
       |    +-------+    |   ODU2   |                 |
      ----->| ODU-2 |----|----------|--------\        |
       |    +-------+    |          |      +----+     |
       |                 |          |       \__/      |
       |                 |          |        \/       |
       |    +-------+    |   ODU3   |         | ODU3  |
      ----->| ODU-3 |----|----------|------\  |       |
       |    +-------+    |          |       \ |       |
       |                 |          |        \|       |
       |                 |          |      +----+     |
       |                 |          |       \__/      |
       |                 |          |        \/       |
       |                 |          |         ---------> OTU-3
       +-----------------+          +-----------------+


             Figure 6: Switching and Terminating capabilities

   The figure in the example shows a line interface able to:

      - Multiplex an ODU2 coming from the switching matrix into and ODU3
      and map it into an OTU3

      - Map an ODU3 coming from the switching matrix into an OTU3

   In this case the interface bandwidth advertised is ODU2 with
   switching capability and ODU3 with both switching and terminating
   capabilities.

   This piece of information needs to be advertised together with the
   related unreserved bandwidth and signal type.  As a consequence
   signaling must have the possibility to setup an LSP allowing the
   local selection of resources consistent with the limitations
   considered during the path computation.



Belotti, et al.          Expires March 24, 2012                [Page 14]


Internet-Draft       Information model for G.709 OTN      September 2011


   In figures 6 and 7 there are two examples of the need of termination/
   switching capability differentiation.  In both examples all nodes are
   supposed to support single-stage capability.  The figure 6 addresses
   a scenario in which a failure on link B-C forces node A to calculate
   another ODU2 LSP path carrying ODU0 service along the nodes B-E-D.
   Being D a single stage capable node, it is able to extract ODU0
   service only from ODU2 interface.  Node A has to know that from E to
   D exists an available OTU2 link from which node D can extract the
   ODU0 service.  This information is required in order to avoid that
   the OTU3 link is considered in the path computation.



               ODU0 transparently transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service                  |
       |       |'''''''''''''''''''''''''''''''''''''''''''|       |
       |       |                                           |       |
       |  +----++  OTU2   +-----+   OTU2  +-----+  OTU2   ++----+  |
     ODU0 |     |  Link   |     |   Link  |     |  Link   |     | ODU0
     ---->|  A  |_________|  B  |_________|  C  |_________|  D  |---->
          |     |         |     |         |     |         |     |
          +-----+         +--+--+         +-----+         ++--+-+
                             |                             |  |
                         OTU3|                             |  |
                         Link|    +-----+__________________|  |
                             |    |     |    OTU3 Link        |
                             |____|  E  |                     |
                                  |     |_____________________|
                                  +-----+    OTU2 Link



       Figure 7: Switching and Terminating capabilities - Example 1

   Figure 7 addresses the scenario in which the restoration of the ODU2
   LSP (ABCD) is required.  The two bundled component links between B
   and E could be used, but the ODU2 over the OTU2 component link can
   only be terminated and not switched.  This implies that it cannot be
   used to restore the ODU2 LSP (ABCD).  However such ODU2 unreserved
   bandwidth must be advertised since it can be used for a different
   ODU2 LSP terminating on E, e.g.  (FBE).  Node A has to know that the
   ODU2 capability on the OTU2 link can only be terminated and that the
   restoration of (ABCD) can only be performed using the ODU2 bandwidth
   available on the OTU3 link.






Belotti, et al.          Expires March 24, 2012                [Page 15]


Internet-Draft       Information model for G.709 OTN      September 2011


               ODU0 transparently transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service                  |
       |       |'''''''''''''''''''''''''''''''''''''''''''|       |
       |       |                                           |       |
       |  +----++  OTU2   +-----+   OTU2  +-----+  OTU2   ++----+  |
     ODU0 |     |  Link   |     |   Link  |     |  Link   |     | ODU0
     ---->|  A  |_________|  B  |_________|  C  |_________|  D  |---->
          |     |         |     |         |     |         |     |
          +-----+         ++-+-++         +-----+         +--+--+
                           | | |                             |
                       OTU2| | |                             |
             +-----+   Link| | |   OTU3    +-----+           |
             |     |       | | |   Link    |     |           |
             |  F  |_______| | |___________|  E  |___________|
             |     |         |_____________|     | OTU2 Link
             +-----+            OTU2 Link  +-----+



       Figure 8: Switching and Terminating capabilities - Example 2

4.8.  Priority Support

   The IETF foresees that up to eight priorities must be supported and
   that all of them have to be advertised independently on the number of
   priorities supported by the implementation.  Considering that the
   advertisement of all the different supported signal types will
   originate large LSAs, it is advised to advertise only the information
   related to the really supported priorities.

4.9.  Multi-stage multiplexing

   With reference to the [OTN-FWK], introduction of multi-stage
   multiplexing implies the advertisement of cascaded adaptation
   capabilities together with the matrix access constraints.  The
   structure defined by IETF for the advertisement of adaptation
   capabilities is ISCD/IACD as in [RFC4202] and [RFC5339].
   Modifications to ISCD/IACD, if needed, have to be addressed in the
   releted encoding documents.

   With respect to the routing, please note that in case of multi stage
   muxing hierarchy (e.g.  ODU1->ODU2->ODU3), not only the ODUk/OTUk
   bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but
   also the intermediate one (ODU2).  This is a typical case of spatial
   allocation problem.

   Suppose in this scenario to have the following advertisement:



Belotti, et al.          Expires March 24, 2012                [Page 16]


Internet-Draft       Information model for G.709 OTN      September 2011


      Hierarchy: ODU1->ODU2->ODU3

      Number of ODU1==5

   The number of ODU1 suggests that it is possible to have an ODU2 FA,
   but it depends on the spatial allocation of such ODU1s.

   It is possible that 2 links are bundled together and 3
   ODU1->ODU2->ODU3 are available on a component link and 2 on the other
   one, in such a case no ODU2 FA could be set up.  The advertisement of
   the ODU2 is needed because in case of ODU1 spatial allocation (3+2),
   the ODU2 available bandwidth would be 0 (no ODU2 FA can be created),
   while in case of ODU1 spatial allocation (4+1) the ODU2 available
   bandwidth would be 1 (1 ODU2 FA can be created).

4.10.  Generalized Label

   The ODUk label format defined in [RFC4328] could be updated to
   support new signal types defined in [G709-V3] but would hardly be
   further enhanced to support possible new signal types.

   Furthermore such label format may have scalability issues due to the
   high number of labels needed when signaling large LSPs.  For example,
   when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it
   would require the utilization of thirty-one labels (31*4*8=992 bits)
   to be allocated while an ODUflex into an ODU4 may need up to eighty
   labels (80*4*8=2560 bits).

   A new flexible and scalable ODUk label format needs to be defined.


5.  Security Considerations

   TBD


6.  IANA Considerations

   TBD


7.  Contributors

      Jonathan Sadler, Tellabs

      EMail: jonathan.sadler@tellabs.com





Belotti, et al.          Expires March 24, 2012                [Page 17]


Internet-Draft       Information model for G.709 OTN      September 2011




      John Drake, Juniper

      EMail: jdrake@juniper.net








8.  Acknowledgements

   The authors would like to thank Eve Varma and Sergio Lanzone for
   their precious collaboration and review.


9.  References

9.1.  Normative References

   [HIER-BIS]
              K.Shiomoto, A.Farrel, "Procedure for Dynamically Signaled
              Hierarchical Label Switched Paths", work in
              progress draft-ietf-lsp-hierarchy-bis-08, February 2010.

   [OTN-OSPF]
              D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot
              ti, "Traffic Engineering Extensions to OSPF for
              Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN
              Networks", work in
              progress draft-ceccarelli-ccamp-gmpls-ospf-g709-03, August
              2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support



Belotti, et al.          Expires March 24, 2012                [Page 18]


Internet-Draft       Information model for G.709 OTN      September 2011


              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 4203, October 2005.

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

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, July 2008.

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

9.2.  Informative References

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

   [G.709-v2]
              ITU-T, "Interface for the Optical Transport Network
              (OTN)", G.709 Recommendation (and Amendment 1),
              March 2003.

   [G.709-v3]
              ITU-T, "Rec G.709, version 3", approved by ITU-T on
              December 2009.

   [G.872-am2]
              ITU-T, "Amendment 2 of G.872 Architecture of optical
              transport networks for consent", consented by ITU-T on
              June 2010.

   [OTN-FWK]  F.Zhang, D.Li, H.Li, S.Belotti, "Framework for GMPLS and
              PCE Control of G.709 Optical Transport Networks", work in
              progress draft-ietf-ccamp-gmpls-g709-framework-00, April
              2010.












Belotti, et al.          Expires March 24, 2012                [Page 19]


Internet-Draft       Information model for G.709 OTN      September 2011


Authors' Addresses

   Sergio Belotti (editor)
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email: sergio.belotti@alcatel-lucent.com


   Pietro Vittorio Grandi
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email: pietro_vittorio.grandi@alcatel-lucent.com


   Daniele Ceccarelli (editor)
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com


   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: diego.caviglia@ericsson.com


   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28972912

   Email: zhangfatai@huawei.com






Belotti, et al.          Expires March 24, 2012                [Page 20]


Internet-Draft       Information model for G.709 OTN      September 2011


   Dan Li
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28973237

   Email: danli@huawei.com












































Belotti, et al.          Expires March 24, 2012                [Page 21]