CCAMP Working Group                            Eric Mannie (Consult)
   Internet Draft                       Dimitri Papadimitriou (Alcatel)
   Expiration Date: August 2003
                                                          February 2003



                  Traffic Engineering Extensions to OSPF
            for Generalized MPLS control of Sonet/SDH Networks

            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt (*)



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

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

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

   (*) Previously draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-01.txt

Abstract

   This document introduces the Sonet/SDH traffic engineering
   extensions required for existing IGP protocols in support of
   Generalized MPLS (GMPLS) signalling as defined in [RFC-3471] and
   [GMPLS-SONET-SDH]. Using [GMPLS-RTG] as guideline, this memo
   specifies the GMPLS routing traffic engineering extensions to OSPF
   for Sonet/SDH networks.

   Based on the Traffic Engineering (TE) extensions defined in [OSPF-
   TE], the proposed approach is aligned with link bundling as defined
   in [MPLS-BDL] and extends the set of Link sub-TLVs proposed in
   [GMPLS-OSPF] to Sonet/SDH networks. The proposed extensions do not
   preclude any further integration with the Interface Switching
   Capability Descriptor specified in [GMPLS-OSPF].




                          Expires July 2003                  [Page 1]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


1. Introduction

   The approach proposed in this document is based on Traffic
   Engineering (TE) extensions as defined in [OSPF-TE] which have been
   extended for GMPLS in [GMPLS-OSPF]. The current proposal also uses
   the notion Link Bundling and TE link as defined in [MPLS-BDL]. A set
   of links between two adjacent GMPLS nodes (or simply nodes) is
   defined as a TE link. GMPLS currently integrates the TE link notion
   by detailing among others that several links having the same Traffic
   Engineering (TE) capabilities (i.e. same TE metric, same set of
   Resource Class and same Switching capability set) can be advertised
   as a single TE link. Such TE links are referred to as link bundles
   whose individual data bearing link (or simply links) are referred to
   as component links when de/multiplexing capable. There is no longer
   a one-to-one association between a regular routing adjacency and a
   TE link.

   However, the definition of (TE) Link sub-TLV as proposed in [OSPF-
   TE] and [GMPLS-OSPF] is mainly based on packet or cell switching
   paradigm that uses statistical multiplexing at each GMPLS nodes. The
   traffic in packet switched technologies is described by various
   attributes such as peak rate, mean rate and burst size and usually
   defined in bits or bytes per second. On the contrary, Sonet/SDH does
   not provide statistical multiplexing; the circuits must be
   multiplexed in a defined manner as specified in [G.707] and
   [T1.105].

   Also, Sonet/SDH circuits can be interpreted like Constant Bit Rate
   (or Peak Bit Rate) traffic with predefined classes such as VC-4-Nc
   in SDH or STS-(3*N)c in Sonet. Hence the Maximum Reservable
   Bandwidth (see [OSPF-TE]) can be mapped to the maximum VC-4-Nc (STS-
   (3*N)c) that can be provided at the TE Link. But the definition of
   Minimum/Maximum LSP Bandwidth included in the Interface Switching
   Capability Descriptor (see [GMPLS-OSPF]) has to be extended in order
   to reflect available multiplexing timeslots. For instance, the sum
   of 4 times VC-4 does not necessarily mean that a VC-4-4c can be
   used, as the VC-4s can be located in different AUG-4s.

   In order to enable distributed Sonet/SDH network control, the link
   state routing protocol has to enable the exchange of two different
   sets (or types) of information. First, a set that describes the link
   capabilities of a GMPLS Sonet/SDH node (or simply a node in this
   context) and this, independently of their usage. Second, a set that
   describes the Sonet/SDH resources (more precisely the timeslots)
   that are in use at each TE link.

   The first set can be defined as being driven by less frequent
   updates (since TE Link capabilities changes are not expected to be
   frequent) while the second would follow update interval values as
   than the one used for any other non-technology dependent TE Link
   attribute. We consider here that when this frequency is very low the
   corresponding TE-link capability is static; by opposition, other are


                          Expires August 2003                 [Page 2]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   referred to as dynamic. Details concerning update frequency usage
   and related concepts are out of the scope of the current document.

   In brief, the present memo proposes to review the current TE Link
   sub-TLVs (and in particular the Interface Switching Capability sub-
   TLV) to extend them for SDH/SONET technology. It memo defines two
   additional sub-sets of information. Their flooding enables the
   Traffic Engineering of the Sonet/SDH LSPs (i.e. the VT SPE/LOVC and
   STS SPE/HOVC LSPs). The first set describes the Sonet/SDH TE Link
   capabilities and this, independently of their usage. The second set
   describes the resources utilization (referred to as timeslot
   components allocation) used at each TE Link and expressed in terms
   of number of unallocated components per TE Link. Last a detailed
   comparison between the bandwidth encoding techniques introduced in
   this document and the ones specified in [GMPLS-RTG] and [GMPLS-OSPF]
   is proposed. Note also that [GMPLS-ISIS] specifics are addressed in
   a companion document.

   Conventions used in this document:

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

   The reader is assumed to be familiar with the terminology in ANSI
   [T1.105], ITU-T [G.707] as well as [RFC-3471], [GMPLS-RTG] and
   [GMPLS-OSPF] and referenced. The following abbreviations are used in
   this document:

     DCC:      Data Communications Channel.
     LOVC:     Lower Order Virtual Container
     HOVC:     Higher Order Virtual Container
     MS:       Multiplex Section.
     MSOH:     Multiplex Section overhead.
     POH:      Path overhead.
     RS:       Regenerator Section.
     RSOH:     Regenerator section overhead.
     SDH:      Synchronous digital hierarchy.
     SOH:      Section overhead.
     SONET:    Synchronous Optical Network.
     SPE:      Synchronous Payload Envelope.
     STM(-N):  Synchronous Transport Module (-N) (SDH).
     STS(-N):  Synchronous Transport Signal-Level N (SONET).
     VC-n:     Virtual Container-n (SDH).
     VTn:      Virtual Tributary-n (SONET).

2. OSPF Routing Extensions

   In OSPF, GMPLS TE links can be advertised using Opaque LSAs (Link
   State Advertisements) of Type 10 (see [RFC-2370]). This Traffic
   Engineering (TE) LSA with area flooding scope is defined in [OSPF-
   TE] and has one top-level Type/Length/Value (TLV) triplet and one or
   more nested sub-TLVs for extensibility. Also, nodes shall originate

                          Expires August 2003                 [Page 3]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   TE LSAs whenever their content change, and whenever required by OSPF
   (for example, originate an LSA refresh when the LSA age field
   reaches the LSRefreshTime). However, this does not mean that every
   LSA contents change must be flooded immediately. As specified in
   [RFC-2328], the origination of TE LSAs SHOULD be rate-limited to at
   most one every MinLSInterval. Upon receipt of a changed TE LSA or
   Network LSA (since these are used in TE calculations), the node
   should update its TE Link state database without necessarily
   performing any (Constraint-)SPF or other path computation.

   Per [OSPF-TE], two top-level TLVs are defined (1) the Router Address
   TLV (referred to as the Node TLV) and (2) the TE Link TLV. This memo
   extends the current sub-TLV set of the TE Link TLV by defining:

   1. Sonet/SDH TE Link capabilities:

      - Multiplexing Capability sub-TLV
      - Concatenation Capability sub-TLV
      - Transparency Capability sub-TLV

   2. Sonet/SDH TE Link component allocation:

      - Component Allocation sub-TLV

   Note: the proposed optional sub-TLVs are defined in a way that can
   complement the Interface Switching Capability Descriptor sub-TLV of
   the TE Link TLV (see [GMPLS-OSPF]) when the Switching Capability
   field value refers to TDM.

   It results from the TE Link definition (see [MPLS-BDL]) that each of
   its component links SHOULD support the same multiplexing and
   (virtual) concatenation capabilities. Note also that the
   corresponding sub-TLVs are specified once, and apply to each
   component link. No per component information or identification is
   required for these sub-TLVs.

3. Additional Considerations

   Between two adjacent nodes, several links having the same TE
   capabilities (i.e. the same TE metric and the same set of Resource
   Class) can be advertised as a single TE Link, such TE links are
   referred to as link bundles. The individual links (or data bearing
   links) belonging to a given bundle are referred to as component
   links when they support multiplexing at each end. Also there is no
   longer a one-to-one association between a regular routing adjacency
   and a TE link.

   In this context, each component of a TE Link may have the same
   Sonet/SDH multiplexing and concatenation capabilities as defined
   later in this document. The corresponding sub-TLVs are specified
   once, but apply to each component of the TE Link. The TE Link
   Sonet/SDH Component Allocation sub-TLV defined in Section 5 gives
   the total number of unallocated components (i.e. timeslots) included

                          Expires August 2003                 [Page 4]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   in a given TE Link. Hence, no per component information or
   identification is required in that context.

   Combined with the Link Property Correlation (see [LMP]) of data
   links into TE Links (also referred to as link bundling) this
   capability helps in removing the potential problem of flooding huge
   amount of routing information. For instance, with a group of 10
   fibers and 40 wavelengths per fiber, each of them supporting an STM-
   64, there are potentially 76800 VC-3 timeslots that can be allocated
   into the corresponding TE Link and that have therefore to be
   advertised to all nodes within the same routing domain. The most
   efficient way to proceed on a per-TE Link basis is to advertise the
   number of unallocated components (i.e. timeslots) such that after
   the initial advertisement, each node within a given routing area is
   aware of total capacity per TE Link (see Section 5.1).

   However, despite being bundled, the usage of each component link in
   a TE Link may differ completely. For example, in a TE Link
   comprising two components the first component could be structured in
   VC-4-4c while the second component could be structured in VC-3s.
   Likewise, each STM-i of an STM-N (N > 1) could also be structured
   differently from the others.

   Therefore, for given TE Link it is not sufficient to simply
   represent the total number of timeslots (i.e. the bandwidth) that
   are (un)allocated. It is also essential to know the corresponding
   signal types. This because an allocated component does not only
   consume a timeslot at a given position in the multiplex, it also
   imposes some restrictions on the future allocations that can be made
   from the free portion of the Sonet/SDH multiplex. This imposes
   specific concatenation capability rules as described in Section 4.2.

   The knowledge of the signal types that can be carried in the STS-
   (3*N)/STM-N (N = 1, 4, 16, 64, 256) supported by the TE links are
   needed for path computation purposes. When computing an explicit
   route, a node considers the Interface Switching Capability
   descriptor subùTLV (see [GMPLS-OSPF]), the Multiplexing Capability
   sub-TLV and Component Allocation sub-TLV to ensure that the path has
   (a) the capability to carry the requested signal and (b) the
   sufficient available bandwidth (i.e. enough timeslot in the
   Sonet/SDH multiplex on this interface) to carry the requested
   signal.

4. TE Link Capabilities

   There are three Sonet/SDH TE Link capabilities that can be
   advertised in the routing protocols: the multiplexing capabilities,
   the concatenation and the transparency capability.

4.1  Sonet/SDH TE Link Multiplexing Capability

   The purpose of the TE Link multiplexing capability is to succinctly
   describe the types of Sonet/SDH signals that can be multiplexed by a

                          Expires August 2003                 [Page 5]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   Sonet/SDH TE Link for explicit route computation purposes. For
   example, depending on how it is structured, an OC-48/STM-16 link may
   be able to multiplex a variety of signal types.

4.1.1   Structure of Sonet/SDH Multiplexing Capabilities

   GMPLS-based control of Sonet/SDH networks enables the control of
   multiplex structures at a finer level of granularity than both STS-
   (3*N)/STM-N with N = 1, 4, 16, 64, 256 and STM-0/STS-1. These
   multiplexing structures are defined in [T1.105] and [G.707].

4.1.2   Sonet/SDH TE Link Multiplexing Capability sub-TLV

   The Multiplexing Capability optional sub-TLV describes the
   multiplexing capabilities of the STS-(3*N)/STM-N (with N = 1, 4, 16,
   64, 256) components of Sonet/SDH TE Links. It indicates precisely
   the types of elementary signal that can be multiplexed by this link.

   This optional sub-TLV of the Link TLV (see [OSPF-TE]), with Type
   TBD, has a length of four octets. The Low Order Multiplexing
   Capability Flag (LO MC Flag) field is defined as a vector of flags
   and coded over one octet. The High Order Multiplexing Capability
   Flag (HO MC Flag) field is defined as a vector of flags and coded
   over one octet:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |           Length = 4          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  HO MC Flag   |  LO MC Flag   |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Fig 1. Sonet/SDH TE Link Multiplex Capability sub-TLV


   These fields defined separately for both High Order (HO) and Low
   Order (LO) Sonet/SDH signals are vectors of bit flags. Each MC Flag
   bit indicates the capability of the TE link components to multiplex
   a given signal into the higher order signal in the Sonet/SDH
   multiplex. A bit value of 1 indicates that the multiplexing
   capability is supported while a bit value of 0 indicates that the
   multiplexing capability is not supported. Bit 1 is the lowest order
   bit of the flag field.

   The Sonet/SDH High Order MC Flag field is defined as:

        - Bit 1 :                     /VC-3   in TUG-3
        - Bit 2 :                     /TUG-3  in AUG-1 (via VC-4)
        - Bit 3 : STS-1    in STSG-3  /AU-3   in AUG-1
        - Bit 4 : STSG-3   in STSG-12 /AUG-1  in AUG-4
        - Bit 5 : STSG-12  in STSG-48 /AUG-4  in AUG-16
        - Bit 6 : STSG-48  in STSG-192/AUG-16 in AUG-64

                          Expires August 2003                 [Page 6]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


        - Bit 7 : STSG-192 in STSG-768/AUG-64 in AUG-256
        - Bit 8 : Reserved

   In SDH, the High Order MC Flag can for instance take the following
   values:
   - 0b01111111 (0x7f): indicates a full SDH HO multiplexing capability
   - 0b00001111 (0x0f): indicates a full AUG-4 (within an STM-4)
     multiplexing capability
   - 0b01111000 (0x78): indicates that the lowest multiplexing
     capability is AUG-1 (with C4->VC4->AU4->AUG1)

   Similarly, the Sonet/SDH Low Order MC Flag is defined as:

        - Bit 1 : VT-1.5 SPE in VT Group /VC-11 in TUG-2
        - Bit 2 : VT-2   SPE in VT Group /VC-12 in TUG-2
        - Bit 3 : VT-3   SPE in VT Group /
        - Bit 4 : VT-6   SPE in VT Group /VC-2  in TUG-2
        - Bit 5 : VT-Group   in STS-1 SPE/TUG-2 in AU-3
        - Bit 6 :                        /TUG-2 in TUG-3
        - Bit 7 : reserved
        - Bit 8 : reserved

   For SDH, the Low Order MC-Flag can for instance take the following
   values:
   - 0b00100010 (0x22): indicates that VC-12 can only be multiplexed in
     VC-3 (through TUG-2)
   - 0b00101000 (0x28): indicates that VC-2 can only be multiplexed in
     VC-3 (through TUG-2)

   Note: A binary value of 0b0...0 when advertised indicates no
   Sonet/SDH multiplexing capability at all. Therefore referring to
   single VC-4-Nc in AUG-N/STM-N or STS-(3*N)c in STSG-(3*N)/STS-(3*N)
   capable interfaces.

4.2  Sonet/SDH TE Link Concatenation Capability sub-TLV

   Contiguous and Virtual concatenation of Low Order (LO) and High
   Order (HO) SONET and SDH signals are respectively defined in
   [T1.105] and [G.707].

4.2.1 SDH TE Link Concatenation Capability sub-TLV

   For SDH, the TE Link Concatenation Capability sub-TLV describes the
   SDH concatenation capabilities of a TE link. This TLV is defined as
   an optional sub-TLV of the Link TLV (see [OSPF-TE]) with Type TBD.
   The corresponding encoding and values are defined for Low Order and
   High Order VCs. If no concatenation is supported on a TE Link, this
   sub-TLV SHOULD not be advertised.

   1. Low Order VC (LOVC) Concatenation

      LOVC Concatenation includes:
      - Contiguous concatenation of X VC-2s (VC-2-Xc, X = 1,...,7)

                          Expires August 2003                 [Page 7]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


      - Virtual concatenation of X VC-2/12/11s (VC-m-Xv, m = 11,12,2)
        as defined in the following table:

        Signal                  Carried in      X interval
        --------------------------------------------------
        VC-11-Xv                VC-3            1 to 28
        VC-12-Xv                VC-3            1 to 21
        VC-2-Xv                 VC-3            1 to 7
        VC-11-Xv                VC-4            1 to 64
        VC-12-Xv                VC-4            1 to 63
        VC-2-Xv                 VC-4            1 to 21

      The TE Link Concatenation Capability optional sub-TLV has the
      following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |   CT  |  Res. |   LT  |     List Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NCC              |             . . .             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NCC              |             . . .             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                            . . .                             //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |   CT  |  Res. |   LT  |     List Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NCC              |             . . .             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NCC              |             . . .             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Fig 2. TE Link Concatenation Capability sub-TLV


   Signal Type (8 bits):

        The Signal Type field values are defined in [GMPLS-SONET-SDH].

   CT û Concatenation Type (4 bits):

        The CT field is defined as a 4-bit vector of flags (with bit 1
        defined as the low order bit). A flag set to 1 indicates the
        support of the corresponding concatenation type:

           Flag 1 (Bit 1): Contiguous Concatenation
           Flag 2 (Bit 2): Virtual Concatenation
           Flag 3 (Bit 3): Reserved

                          Expires August 2003                 [Page 8]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


           Flag 4 (Bit 4): Reserved

        Reserved flags MUST be set to zero when sent and ignored when
        received.

   Reserved (4 bits):

        The Reserved field bits must be set to zero when sent and
        should be ignored when received.

   LT û List Type (4 bits):

        The LT field indicates the type of the list; the following
        values are defined (the values to which multiple lists refer
        must be mutually disjoint):

           0x0000   Reserved
           0x0001   Inclusive list
           0x0010   Exclusive list
           0x0011   Inclusive range (one or more Minimum/Maximum pairs)
           0x0100   Exclusive range (one or more Minimum/Maximum pairs)

        Values ranging from 0x0101 to 0x1111 are reserved. At most one
        LT value is allowed per sub-TLV (this limits its length).
        Therefore this sub-TLV includes at most four sub-lists.

   List Length (12 bits):

        The List Length field indicates the number N of NCC fields (of
        16 bits) comprised in a given list including the zero padding
        field. Zero is an invalid value (or equivalently, N MUST be
        greater than 0 and the minimum sub-TLV length is 8 octets).

   NCC - Number of Concatenated Components (16 bits):

        The NCC field indicates the supported number of low order VCÆs
        with respect to the Signal Type and the CT values. A NCC value
        equal to zero refers to a zero padding field. For SDH LOVCs,
        the number of VC-mÆs values MUST refer to one or more of the
        following values (as defined in the Signal Type field): VC-11,
        VC-12 and/or VC-2.

        When the LT field value equals 2 or 3, at least one pair of
        LOVCÆs numbers (i.e. two NCC fields) must be included in the
        list. The first value indicates the minimum number of LOVCÆs
        and the second one the maximum number of LOVCÆs supported (or
        not supported, respectively) with the selected concatenation
        type (CT).

        Note: for a given Signal Type when this sub-TLV includes
        several lists (defined with the same Type or not), the NCC
        values that each list contain MUST be mutually consistent.


                          Expires August 2003                 [Page 9]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   2. High Order VC (HOVC) Concatenation:

      HOVC Concatenation includes:
      - Contiguous concatenation of X VC-4s (VC-4-Xc, X = 4,16,64,256)
      - Virtual concatenation of X VC-3/4s  (VC-3/4-Xv, X = 1,...,256)

      The SDH HOVC TE Link Concatenation Capability TLV has exactly the
      same format and encoding as the one defined here above:

      Signal Type (8 bits): see above.

      CT û Concatenation Type (4 bits): see above.

      Reserved (4 bits): see above.

      LT û List Type (4 bits): see above.

      List Length (12 bits): see above.

      NCC - Number of Concatenated Components (16 bits):

        The NCC field indicates the supported number of high order VCÆs
        with respect to the Signal Type (i.e. VC-3 and/or VC-4) and the
        CT values. A NCC value equal to zero refers to a zero padding
        field.

        When the LT field value equals 2 or 3, at least one pair of
        HOVCÆs numbers (i.e. two NCC fields) must be included in the
        list. The first value indicates the minimum number of HOVCÆs
        and the second one the maximum number of HOVCÆs supported (or
        not supported, respectively) with the selected concatenation
        type (CT).

        Note: for a given Signal Type, when this sub-TLV includes
        several lists (defined with the same Type or not), the NCC
        values that each list contain MUST be mutually consistent.

4.2.2 Sonet TE Link Concatenation Capability sub-TLV

   Using the STS-1 SPE and STS-3c SPE equivalence to a VC-3 and a VC-4,
   respectively, the above definition of high order Concatenation
   Capability sub-TLV applies. Notice that in SONET, contiguous
   concatenation is applicable to STS-3c SPE signals, resulting in STS-
   (3*X)c SPE signals with X = 4,16,64,256. For low order signal, only
   virtual concatenation of X VTn SPEs (VTn-Xv SPE, n = 1.5,2,3,6) must
   be considered since low order contiguous concatenation is not
   defined in ANSI [T1.105].

   This optional sub-TLV is defined (see also Section 4.2.1) as a sub-
   TLV of the Link TLV, with Type TBD. The corresponding encoding and
   values are defined for Low Order and High Order VCs.

   1. Low order VT SPEs concatenation:

                          Expires August 2003                [Page 10]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03



      - Virtual concatenation of X VTnÆs SPE (VTn-Xv SPE, n = 1.5,2,3,
        6) as defined in the following table:

        Signal                  Carried in      X interval
        --------------------------------------------------
        VT1.5-Xv SPE            STS-1           1 to 28
        VT2-Xv   SPE            STS-1           1 to 21
        VT3-Xv   SPE            STS-1           1 to 14
        VT6-Xv   SPE            STS-1           1 to 7
        VT1.5-Xv SPE            STS-3c          1 to 64
        VT2-Xv   SPE            STS-3c          1 to 63
        VT3-Xv   SPE            STS-3c          1 to 42
        VT6-Xv   SPE            STS-3c          1 to 21

      The format and encoding for the Low Order SONET TE Link
      Concatenation Capability TLV is identical to the one defined for
      SDH LOVC TE Links (see Section 4.2.1).

   2. High order STS SPEs concatenation:

      - Contiguous concatenation of X STS-3c SPEs (STS-(3*X)c with X =
        4,16,64,256)
      - Virtual concatenation of X STS-1/STS-3c SPEs (STS-1-Xv/STS-3c-
        Xv with X = 1,...,256)

      The format and encoding for the High Order SONET TE Link
      Concatenation Capability TLV is identical to the one defined for
      SDH HOVC TE Links (see Section 4.2.1).

4.3  Sonet/SDH TE Link Transparency Capability sub-TLV

   This optional sub-TLV is defined as a vector of flags that indicates
   the type of transparency supported by each of the component of a
   given TE Link. Therefore it SHOULD be used only when these
   components supports transparent signal types (see [GMPLS-SONET-
   SDH]).

   Several flags can be combined to provide different types of
   transparency while any combination is not necessarily valid. By
   default, the supported transparency on a TE Link is defined as the
   Path Overhead (POH) transparency; therefore this sub-TLV should not
   be sent for a TE Link only supporting POH transparency.

   Note that when this sub-TLV is advertised, the Signal Type(s)
   field(s) in the sub-TLV defined in Section 5 MUST take at least one
   of the following values (see [GMPLS-SONET-SDH]): STS-1/STM-0, STS-
   3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64 and STS-
   768/STM-256. Equivalently, at least one transparency type MUST be
   specified when advertising such Signal Type(s) in this sub-TLV.




                          Expires August 2003                [Page 11]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   This TLV is defined a sub-TLV of the Link TLV (see [OSPF-TE]), with
   Type TBD and a length of four octets. It includes the Transparency
   field defined as a 32-bit vector of flags.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |         Length = 4            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Transparency (T)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Fig 4. Sonet/SDH TE Link Transparency Capability sub-TLV

   The different transparency flags are the following:

        Flag 1 (bit 1): Section/Regenerator Section layer
        Flag 2 (bit 2): Line/Multiplex Section layer

   Where bit 1 is the low order bit. Others flags are reserved, they
   should be set to zero when sent, and must be ignored when received.
   A flag is set to one to indicate that the corresponding transparency
   is supported on the corresponding TE link. Additional flagging rules
   MUST follow the rules defined in [GMPLS-SONET-SDH].

5. TE Link Component Allocation

   TE Link component allocation refers to the actual resource
   utilization status of a TE link (representing either a single
   component link or a bundled link). In the Sonet/SDH context, this
   information can be represented by the number of unallocated (free)
   timeslots per signal type and per TE link.

5.1 Sonet/SDH TE Link Component Allocation sub-TLV

   The Sonet/SDH TE Link Component Allocation sub-TLV specifies the
   number of identical unallocated timeslots per TE Link. As such, the
   initial value(s) of this TLV indicates the total capacity in terms
   of number of timeslot (per Signal Type) per TE link.

   This TLV is defined as a sub-TLV of the Link TLV (see [OSPF-TE]),
   with Type TBD and a length of n*4 octets. Each of the n fields gives
   the number of unallocated timeslot per Signal Type (per TE Link) and
   comprises a Signal Type field (8 bits) and a Number of Unallocated
   Timeslot field (24 bits). The Signal Type field values are defined
   in [GMPLS-SONET-SDH].

   Typically, this sub-TLV will be advertised by including Signal
   Type(s) of the same order since one expects (as it is mostly the
   case in legacy networks) separated routing instances between Low
   Order and High Order VC transport layers.

      0                   1                   2                   3

                          Expires August 2003                [Page 12]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |          Length = n*4         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |        Number of Unallocated Timeslots        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |        Number of Unallocated Timeslots        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                            . . .                             //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Fig 5. Sonet/SDH TE Link Component Allocation sub-TLV

   For instance, if a TE Link is constituted by 40 STM-64, each of them
   decomposed in VC-4, initially the value of the Number of Unallocated
   Timeslots field of this TLV is 40 x 64. Thus, 2560 VC-4 signals are
   supported, and, if required, 2560 instances of exactly the same
   signal can be allocated.

   Note: for transparent Signal Types such as STS-(3*N)/STM-N (see
   [GMPLS-SONET-SDH]), this number simply refers to the number of
   interfaces supported at each end of the TE Link.

5.2 Sonet/SDH TE Link Contiguous Component Allocation

   Contiguous concatenation of Low Order (LO) and High Order (HO) SONET
   and SDH signals are respectively defined in [T1.105] and [G.707].
   Here, instead of advertising the concatenation capabilities (as
   defined in Section 4.2), and provide a countdown on a per-timeslot
   basis as defined in Section 5.1, an alternative way for the
   representation of the component allocation in case of contiguous
   concatenation capable TE links consists in defining additional
   signal type values. In particular:

   Value        Type (Elementary Signal)
   -----        ------------------------
    TBA         STS-12c SPE  / VC-4-4c
    TBA         STS-48c SPE  / VC-4-16c
    TBA         STS-192c SPE / VC-4-64c
    TBA         STS-768c SPE / VC-4-256c

   These Signal Type field values extends the set of values defined in
   [GMPLS-SONET-SDH] and allows for an efficient accounting of the
   timeslot allocation on interfaces supporting (simultaneously)
   multiple contiguous concatenation types. Also, in this case, the
   Concatenation Capability sub-TLV (See Section 4.2) SHOULD not be
   used.

   Example: A given Sonet/SDH STM-256 interface supporting all the
   above contiguous concatenation is initially advertised with the
   following capacity (timeslots being numbered from 0 to 255):

                          Expires August 2003                [Page 13]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03



   Signal Type  Number of Unallocated Timeslot
                Init     VC-4#0    VC-4#4    VC-4-4c#64    VC4-16c#128
   -----------  ------------------------------------------------------
   VC-4         256      255       254       250           234
   VC-4-4c      64       63        62        61            57
   VC-4-16c     16       15        15        14            13
   VC-4-64c     4        3         3         2             1
   VC-4-256c    1        0         0         0             0

   Here, (0,0,0,0,0) indicates the first AUG-256 (first letter), first
   AUG-64 (second letter), first AUG-16 (third letter), first AUG-4
   (forth letter), first AUG-1 (fifth letter).

   For instance, after a first VC-4 timeslot gets allocated at position
   0 (0,0,0,0,0), (disables the availability of the VC-4-256c, first
   VC-4-64c, the first VC-4-16c and first VC-4-4c) the values indicated
   in column 2 are advertised. A second VC-4 timeslot gets allocated at
   position 4 (0,0,0,1,0), (disabling the second VC-4-4c) implying the
   information indicated in column 3 is advertised. Then, on the same
   link, a VC-4-4c timeslot gets allocated at position 64 (0,1,0,0,0),
   (disables the second VC-4-64c, the first VC-4-16c, and its
   underlying VC-4-4c and VC-4s (4 times)) the number of unallocated
   timeslots indicated in column 4 is advertised. Last, a VC-4-16c
   timeslot gets allocated at position 128 (disables the third VC-4-64c
   and its underlying VC-4-4cs (4 times) and VC-4s (16 times)), the
   values of column 5 are advertised.

   It should be noted that the description above is given for
   understanding reasons. Usually the label allocation process should
   allocate labels in a more sophisticated way by limiting
   fragmentation of the multiplex structure. As an example the VC-4#4
   should be allocated at position 1, the VC-4-4c#64 should be
   allocated at position 4 and the VC4-16c should be allocated at
   position 16. The table below shows the difference that there is
   still a possibility to allocate 3 VC-4-64c at this interface.

   Signal Type  Number of Unallocated Timeslot
                Init     VC-4#0     VC-4#1    VC-4-4c#4    VC-4-16c#16
   -----------  ------------------------------------------------------
   VC-4         256      255        254       250          234
   VC-4-4c      64       63         63        62           58
   VC-4-16c     16       15         15        15           14
   VC-4-64c     4        3          3         3            3
   VC-4-256c    1        0          0         0            0

   Note also that the following accounting is forbidden taking for
   instance an STM-16 interface where, 4 VC-4s are allocated at
   position 0, 4, 8 and 12, respectively as each VC-4 is located in
   different a AUG-4 group.

   Signal Type   Number of Unallocated Timeslot
   -----------   ------------------------------

                          Expires August 2003                [Page 14]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   VC-4          12
   VC-4-4c       3
   VC-4-16c      0

   The corresponding values MUST be assigned as follows:

   Signal Type   Number of Unallocated Timeslot
   -----------   ------------------------------
   VC-4          12
   VC-4-4c       0
   VC-4-16c      0

5.3 Minimum/Maximum LSP Bandwidth

   The third representation makes usage of the Minimum/Maximum LSP
   Bandwidth as defined in [GMPLS-RTG]. It has to be noticed that in
   this case (taking into account the above example), that the Minimum
   LSP Bandwidth would correspond to a VC-4 and the Maximum LSP
   Bandwidth to a VC-4-256c (and thus the Unreserved Bandwidth on that
   link).

   Also the Maximum LSP Bandwidth can vary over time as timeslots gets
   allocated. In the above example, it would range from a VC-4-256c
   initially to a VC-4-64c afterwards. On the contrary the Minimum LSP
   Bandwidth does not change unless all the 256 VC-4 timeslots have
   been allocated on that link.

5.4 Comparison and Tradeoffs

   The method proposed in Section 5.3 is the most straightforward
   without requiring any bandwidth accounting change from an LSR
   perspective. The lost of information only affects the number of
   signals that can be used but not the range they cover. On the other
   hand, when additional technology specific information are advertised
   (see Section 4, 5.1 and 5.2) a finer grained resource countdown and
   accounting can be performed allowing for network wide resource
   allocation in Sonet/SDH environments.

   It has to be emphasized that the behavior of the Concatenation
   Capability sub-TLV (as defined in Section 4.2) is equivalent to the
   one specified when advertising Minimum/Maximum LSP Bandwidth. Note
   that the update frequency of the Opaque TE LSA (Type 1, see [OSPF-
   TE]) does not affect technology specific methods because the former
   implies variation of the Unreserved Bandwidth sub-TLV when timeslots
   are allocated. Hence from this perspective, both classes of
   solutions are equivalent.

6. Scalability Considerations

   A Sonet/SDH-capable node SHOULD try to minimize the amount of
   traffic engineering routing information it floods. Each time a
   signal (e.g. a timeslot) is allocated or released that information
   shall be flooded (not necessarily immediately) to all nodes in the

                          Expires August 2003                [Page 15]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   routing domain. In particular, this applies to the Component
   Allocation sub-TLVs. This can result in updating an existing LSA or
   even flushing an existing LSA. Removing an LSA can be performed in
   OSPF by prematurely aging the LSA. The LSA is re-flooded with an LSA
   age equal to MaxAge. Each node receiving an existing LSA with MaxAge
   removes it from its link state database.

   Also, the usage of OSPF implies each LSA must be refreshed
   periodically (when the LSA age field reaches the LSRefreshTime, see
   [RFC-2328]) to avoid age timeout and removal from the link state
   database. This periodical LSA flooding and processing applies
   particularly to the Capability sub-TLVs defined in this document
   since their variation period is expected to be much larger than the
   LSRefreshTime.

   An Opaque LSA has a length field of 16 bits indicating the length of
   the LSA, including the header. Thus, the length of OSPF packets can
   be up to 65535 octets (including the IP header). Moreover, an OSPF
   packet can contain several LSAs. OSPF relies if necessary on the IP
   fragmentation to transmit large packets. This is possible without
   any loss of functionality. However this is not recommended and it is
   suggested to split packets that are too large into several smaller
   packets.

   It has to be emphasized that none of the sub-TLVs defined in this
   document exceed the maximum OSPF packet size. Limiting the size of
   the Concatenation Capability sub-TLV is ensured by construction.
   Therefore, there is no particular issue that may be generated by the
   size of Sonet/SDH sub-TLVs to be flooded in TE LSAs.

7. Compatibility Considerations

   There should be no interoperability issues with Sonet/SDH GMPLS-
   capable nodes that do not implement the proposed extensions, as the
   Opaque LSAs (and the sub-TLVs proposed in this document) will be
   silently ignored.

   The result of having such nodes that do not implement these
   extensions is that the Sonet/SDH specific traffic engineering
   topology will be missing leading to an increasing rejection of sub-
   sequent LSP signaling.

   However, TE constraint paths can still be calculated using the
   [OSPF-TE] and [GMPLS-OSPF] technology independent TE Link sub-TLVs.

8. Security Considerations

   Routing protocol related security considerations are identical to
   the on referenced in [RFC-2328] and [OSPF-TE].

9. References

9.1 Normative References

                          Expires August 2003                [Page 16]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03



   [G.707]      ITU-T Recommendation G.707, "Network Node Interface for
                the Synchronous Digital Hierarchy", October 2000.

   [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized MPLS (GMPLS)
                Architecture," Internet Draft, Work in Progress, draft-
                ietf-ccamp-gmpls-architecture-03.txt, August 2002.

   [GMPLS-ISIS] K.Kompella et al, "IS-IS Extensions in Support of
                Generalized MPLS," Internet Draft, Work in Progress,
                draft-ietf-isis-gmpls-extensions-16.txt, January 2003.

   [GMPLS-RTG]  K.Kompella et al., "Routing Extensions in Support of
                Generalized MPLS," Internet Draft, Work in Progress,
                draft-ietf-ccamp-gmpls-routing-05.txt, August 2002.

   [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors),
                "GMPLS extensions for SONET and SDH control", Internet
                Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-
                sdh-07.txt, October 2002.

   [MPLS-BDL]   K.Kompella et al., "Link Bundling in MPLS Traffic
                Engineering," Internet Draft, Work in Progress, draft-
                ietf-mpls-bundle-04.txt, August 2002.

   [MPLS-HIER]  K.Kompella and Y.Rekhter, "LSP Hierarchy with
                Generalized MPLS TE", Internet Draft, Work in Progress,
                draft-ietf-mpls-lsp-hierarchy-08.txt, August 2002.

   [OSPF-DNA]   P.Pillay-Esnault, "OSPF Refresh and Flooding Reduction
                in Stable Topologies", Internet Draft, Work in
                progress, draft-pillay-esnault-ospf-flooding-04.txt,
                January 2003.

   [OSPF-TE]    D.Katz, D.Yeung and K.Kompella, "Traffic Engineering
                Extensions to OSPF", draft-katz-yeung-ospf-traffic-
                09.txt, Internet Draft, Work in Progress, October 2002.

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

   [RFC-2328]   J.Moy, RFC 2328, "OSPF Version 2", STD 54, IETF
                Standard Track, April 1998.

   [RFC-2370]   R.Coltun, RFC 2370, Standard Track, "The OSPF Opaque
                LSA Option", July 1998.

   [RFC-3471]   Berger, L. (Editor), et al., "Generalized MPLS û
                Signaling Functional Description", RFC 3471, January
                2003.




                          Expires August 2003                [Page 17]


            draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt     Feb. 03


   [T1.105]     American National Standards Institute, "Synchronous
                Optical Network - Payload Mappings", T1.105, January
                2001.

10. Author's Addresses

   Dimitri Papadimitriou (Alcatel)
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   Email: dimitri.papadimitriou@alcatel.be

   Eric Mannie (Consult)
   Email: eric_mannie@hotmail.com








































                          Expires August 2003                [Page 18]