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]