CCAMP Working Group Eric Mannie (Consult) Internet Draft Dimitri Papadimitriou (Alcatel) Expiration Date: May 2003 November 2002 Traffic Engineering Extensions to OSPF for Generalized MPLS control of Sonet/SDH Networks draft-mannie-ccamp-gmpls-sonet-sdh-ospf-00.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 traffic engineering extensions required in existing IGP protocols to support sub-sequent signalling for Label Switched Path (LSP) when using Generalized MPLS (GMPLS) signalling as defined in [GMPLS-SIG] and [GMPLS-SONET-SDH] for Sonet/SDH Networks. In particular, using [GMPLS-RTG] as guideline, it 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 TE Link sub-TLVs proposed in [GMPLS- OSPF] by proposing several new sub-TLVs for Sonet/SDH networks. The proposed extensions do not preclude any further integration with these documents. Expires May 2003 [Page 1] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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. 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 referred to as dynamic. Details concerning update frequency usage and related concepts are out of the scope of the current document. In brief, this 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) used at each TE Link and expressed in terms of number of unallocated components per TE Link. 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 [GMPLS-SIG], [GMPLS-RTG] and [GMPLS-OSPF] and referenced. The following abbreviations are used in this document: Expires December 2002 [Page 2] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 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 sub-TLVs can also complement the Interface Switching Capability Descriptor sub-TLV of the TE Link TLV and (see [GMPLS-OSPF]) when the Switching Capability field value refers to TDM. Expires December 2002 [Page 3] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 Using the above classification, one can reduce the amount of more static information flooded since changes are much less frequent when considering TE Link capabilities (see [OSPF-DNA] for instance). This, while keeping the more dynamic information (changes are more frequent when considering TE Link component allocation for instance) confined to the region to which this information is relevant. In addition, it results from the TE Link definition (see [MPLS-BDL]) that each of its component link 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 Traffic Engineering (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 two corresponding sub-TLVs are specified once, but apply to each component of the TE Link. Thus, no per component information or identification is required for these TLVs. The TE Link Sonet/SDH Component Allocation sub-TLV defined in Section 5 gives the total number of unallocated components (i.e. timeslots) included in a given TE Link. 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). 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. Expires December 2002 [Page 4] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 two Sonet/SDH TE Link capabilities to be advertised in the routing protocols: the multiplexing capabilities, the concatenation and the transparency capability. 4.1 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 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 STM- N/STS-(3xN) 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 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. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length of this TLV is 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 Expires December 2002 [Page 5] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 : STS-1 in STSG-3 /AU-3 in AUG-1 - Bit 2 : STSG-3 in STSG-12 /AUG-1 in AUG-4 - Bit 3 : STSG-12 in STSG-48 /AUG-4 in AUG-16 - Bit 4 : STSG-48 in STSG-192/AUG-16 in AUG-64 - Bit 5 : STSG-192 in STSG-768/AUG-64 in AUG-256 - Bit 6 : /TUG-3 in AUG-1 (via VC-4) - Bit 7 : Reserved - Bit 8 : Reserved In SDH, the High Order MC Flag can for instance take the following values: - 0b00111111 (0x3f): indicates a full SDH HO multiplexing capability - 0b00011110 (0x1e): indicates that the lowest multiplexing capability is AUG-1 (with C4->VC4->AU4->AUG1) - 0b00000111 (0x05): indicates a full AUG-4 (within an STM-4) multiplexing capability 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 Expires December 2002 [Page 6] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 STS3-Mc in STS-N (with N = 3xM) 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]. Some equipmentÆs have limitations on the number of signal that can be concatenated. In that case, it may not possible to use a complete range of signals for contiguous (or even virtual) concatenation. It might also be that some of the supported contiguous and virtual concatenation capabilities are precluded or discarded for reasons outside of the scope of this specification. Therefore, we propose an alternate way of representing the concatenation capabilities of a TE link by efficiently listing the levels of contiguous and virtual concatenation they support. 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 a sub-TLV of the Link TLV, 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) - 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 Expires December 2002 [Page 7] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 The TE Link Concatenation Capability 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): Concatenation Conversion (see ITU-T G.783) 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): Expires December 2002 [Page 8] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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. 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. Expires December 2002 [Page 9] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 High Order Concatenation Capability 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 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: - 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 Expires December 2002 [Page 10] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 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. 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]): STM-0/STS-1, STM- 1/STS-3, STM-4/STS-12, STM-16/STS-48, STM-64/STS-192, and STM- 256/STS-768. Equivalently, at least one transparency type MUST be specified when advertising such Signal Type(s) in this sub-TLV. This TLV is defined a sub-TLV of the Link TLV, with type TBD. The length of this TLV is 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 Expires December 2002 [Page 11] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 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 TE link. This TLV is defined as a sub-TLV of the Link TLV, with type TBD. The length is n*4 octets. The value is the number of unallocated (free) timeslot in the TE Link, and is coded in 4 octets. The Signal Type field values are defined in [GMPLS-SONET-SDH]. Typically, a given 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 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. Expires December 2002 [Page 12] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 For transparent Signal Types, this number simply refers to the number of interfaces supported at each end of the TE Link. When two Number of Unallocated Timeslots fields with the same Signal Type value are advertised, the second one indicates the number of contiguous block of unallocated timeslots. Thus, when advertised initially the corresponding value equal 1. This enables efficient resource control to avoid the fragmentation that may appear on certain Sonet/SDH TE links. 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 routing domain. In particular, this applies to the Unallocated Timeslot 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. Expires December 2002 [Page 13] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 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 [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-14.txt, August 2002. [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) et al., "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-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-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. Expires December 2002 [Page 14] draft-mannie-ccamp-gmpls-sonet-sdh-ospf-02.txt Nov. 02 [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 December 2002 [Page 15]