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

CCAMP Working Group                                           S. Belotti
Internet-Draft                                                 P. Grandi
Intended status: Informational                            Alcatel-Lucent
Expires: January 9, 2011                                   D. Ceccarelli
                                                             D. Caviglia
                                                                Ericsson
                                                                F. Zhang
                                                                   D. Li
                                                     Huawei Technologies
                                                           July 08, 2010


      Information model for G.709 Optical Transport Networks (OTN)
                draft-bccg-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
   process in OTNs to support Generalized Multiprotocol Label Switching
   (GMPLS) control of all currently defined ODU containers both at sub-
   lambdas and lambda level granularity.

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 January 9, 2011.

Copyright Notice

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



Belotti, et al.          Expires January 9, 2011                [Page 1]


Internet-Draft       Information model for G.709 OTN           July 2010


   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
   2.  OSPF requirements overview . . . . . . . . . . . . . . . . . .  3
   3.  G.709 Digital Layer TE Information and Requirement Analysis  .  5
     3.1.  Tributary Slot type  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Signal type  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Unreserved Resources . . . . . . . . . . . . . . . . . . .  8
     3.4.  Maximum LSP Bandwidth  . . . . . . . . . . . . . . . . . .  9
     3.5.  Distinction between link multiplexing capacity and
           link rate capacity . . . . . . . . . . . . . . . . . . . .  9
     3.6.  Priority Support . . . . . . . . . . . . . . . . . . . . . 10
     3.7.  Multi-stage multiplexing . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




















Belotti, et al.          Expires January 9, 2011                [Page 2]


Internet-Draft       Information model for G.709 OTN           July 2010


1.  Introduction

   An Opaque OSPF (Open Shortest Path First) LSA (Link State
   Advertisements) carrying application-specific information can be
   generated and advertised to other nodes following the flooding
   procedures 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.

   Traffic Engineering(TE) LSA using type 10 opaque LSA is defined in
   [RFC3630] for TE purpose.  This type of LSA is 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 is
   fundamental in order to allow automatic calculation of routes for
   ODUk LSPs signaled via RSVP-TE protocol.  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 routing protocol
   extensions to allow Generalized MPLS (GMPLS) control of all currently
   defined ODU containers, in support of sub-lambda and lambda level
   routing granularity.

   This document provides a model of information needed by the routing
   process in OTNs to support Generalized Multiprotocol Label Switching
   (GMPLS) control of all currently defined ODU containers both at sub-
   lambdas and lambda level granularity.

   OSPF requirements are defined in [OTN-FWK], while protocol extensions
   are defined in [OTN-OSPF].


2.  OSPF requirements overview

   OTN serves as the convergence layer for transporting a wide range of
   services, including those whose bit rates do not allow efficient
   usage of the entire bandwidth associated with a single lambda.  In
   such a case OTN allows aggregation (and recovery) of traffic to



Belotti, et al.          Expires January 9, 2011                [Page 3]


Internet-Draft       Information model for G.709 OTN           July 2010


   support optimization of overall network bandwidth allocation; i.e.,
   OTN allows the aggregated service rate to be decoupled from the OTN
   line system capacity.  The heterogeneous multiplexing hierarchy
   additionally supports various network architectures, including those
   optimized to minimize stranded capacity, minimize managed entities,
   support carrier's carrier scenarios, and/or enable ODU0/ODUflex
   traffic to transit a region of the network that does not support
   these capabilities.

   Thus, it is necessary to define a scalable control plane solution
   that is able to fully exploit OTN flexibility (both in terms of
   architecture, aggregation and survivability).

   [Ed note] (could be part of Framework but for the moment can provide
   introduction to the overview).

   In this scope, Section 5.3 of the [draft-fwk] provides a set of
   functional routing requirements.  These requirements are 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 for TS granularity advertisement: Each ODUj can be
      multiplexed into an OTUk using different TS granularities.  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 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 link multiplexing capacity
      and link rate capacity

      - 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 either at the same line rate or different
      line rates (e.g. 40G and 10G).  Bundling links at different rates
      makes the control plane more scalable and permits better



Belotti, et al.          Expires January 9, 2011                [Page 4]


Internet-Draft       Information model for G.709 OTN           July 2010


      networking flexibility.


3.  G.709 Digital Layer TE Information and Requirement Analysis

   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 amendment
   2 provides two tables defining mapping and multiplexing capabilities
   of OTNs, which are reproduced below.



         +--------------------+--------------------+
         |     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 January 9, 2011                [Page 5]


Internet-Draft       Information model for G.709 OTN           July 2010


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



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




Belotti, et al.          Expires January 9, 2011                [Page 6]


Internet-Draft       Information model for G.709 OTN           July 2010


   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 only considers the TE information needed for ODU path
   computation.

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

3.1.  Tributary Slot type

   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

   In addition, the bandwidth accounting depends on the type of TS.
   Therefore, the type of the TS should be known during LO ODUk path
   computation.  Currently such information is not provided by the
   routing protocol.

3.2.  Signal type

   [RFC 4328] 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.




Belotti, et al.          Expires January 9, 2011                [Page 7]


Internet-Draft       Information model for G.709 OTN           July 2010


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

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




Belotti, et al.          Expires January 9, 2011                [Page 8]


Internet-Draft       Information model for G.709 OTN           July 2010


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


                   Figure 3: 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.

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

3.5.  Distinction between link multiplexing capacity and link rate
      capacity

   As mentioned earlier, to enable optimization of overall network
   bandwidth allocation, it is necessary to decouple the connection
   service rate from the OTN link rate capacity, so as to support sub-
   lambda switching agility.  Thus, it is needed to provide the
   possibility to separately advertise the bandwidth available at lambda
   granularity from the bandwidth available at sub-lambda granularity.

   For example consider a bundle link consisting of 5 OTU4 and 4 OTU3,
   no support for ODUflex.  The bandwidth advertised at full lambda
   granularity should be :

      -5 Full-lambda ODU4

      -4 Full-lambda ODU3

   The bandwidth advertised at sub-lambda granularity should be:




Belotti, et al.          Expires January 9, 2011                [Page 9]


Internet-Draft       Information model for G.709 OTN           July 2010


      -10 sub-lambda ODU3 (they are all from OTU4 link)

      -66 sub-lambda ODU2 (5x10 ODU2 from 5xODU4 + 4x4 ODU2 from 4xODU3)

      -264 sub-lambda ODU1 (5x40 ODU1 from 5xODU4 + 4x16 ODU1 from
      4xODU3)

      - 528 sub-lambda ODU0 (5x80 ODU0 from 5xODU4 + 4x32 ODU0 from
      4xODU3)

   The ability to distinguish between link rate capacity and link
   multiplexing capacity is already a requirement as per [OTN-FWK].  As
   discussed in Section 3.2, [RFC4203] could achieve this distinction by
   advertising different bandwidths for full lambda and sub-lambda
   signal granularities.  However, this approach implies the usage of
   multiple ISCDs and therefore it is not efficient.  For example a link
   with link rate capacity OTU3 and multiplexing capacity ODU1, ODU2 and
   ODU3, [RFC4203] could require the utilization of up to three
   different ISCDs, one for each capability.

   So TE-link declaring would need:

      1 ISCD for ODU1 with MAX LSP BW = MIN LSP BW = ODU1

      1 ISCD for ODU2 with MAX LSP BW = MIN LSP BW = ODU2

      1 ISCD for ODU3 with MAX LSP BW = MIN LSP BW = ODU3 (full lambda)

   Maximum Reservable Bandwidth (of the TE-link) set to ODU3

      Unreserved Bandwidth (of the TE-link)) set to ODU3

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

3.7.  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].



Belotti, et al.          Expires January 9, 2011               [Page 10]


Internet-Draft       Information model for G.709 OTN           July 2010


   Modifications to ISCD/IACD , if needed, are FFS.


4.  Security Considerations

   TBD


5.  IANA Considerations

   TBD


6.  Acknowledgements

   The authors would like to thank Eve Varma for her precious
   collaboration and review.


7.  References

7.1.  Normative References

   [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", consented by ITU-T on Oct 2009.

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




Belotti, et al.          Expires January 9, 2011               [Page 11]


Internet-Draft       Information model for G.709 OTN           July 2010


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

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


Authors' Addresses

   Sergio Belotti
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email: sergio.belotti@alcatel-lucent.com








Belotti, et al.          Expires January 9, 2011               [Page 12]


Internet-Draft       Information model for G.709 OTN           July 2010


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

   Email: pietro_vittorio.grandi@alcatel-lucent.com


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


   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 January 9, 2011               [Page 13]