idnits 2.17.1 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt: -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([GMPLS-ISIS], [GMPLS-OSPF], [MPLS-BDL], [ISIS-TE], [GMPLS-SONET-SDH], [G.707], [GMPLS-RTG], [RFC-3471]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 332 has weird spacing: '...T-Group in S...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 Extended IS Reachability TLV (see [ISIS-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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7741 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 16 == Missing Reference: 'GMPLS-OSPF' is mentioned on line 122, but not defined == Missing Reference: 'RFC-1195' is mentioned on line 134, but not defined == Missing Reference: 'LMP' is mentioned on line 212, but not defined == Unused Reference: 'GMPLS-ARCH' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'MPLS-HIER' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 837, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-16 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-05 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-07 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group E. Mannie (Consult) 3 Internet Draft D. Papadimitriou (Alcatel) 4 Expiration Date: August 2003 5 February 2003 7 Traffic Engineering Extensions to IS-IS 8 for Generalized MPLS control of Sonet/SDH Networks 10 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt (*) 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 (*) Previously draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-01.txt 34 Abstract 36 This document introduces the Sonet/SDH traffic engineering 37 extensions required for existing IGP protocols in support of 38 Generalized MPLS (GMPLS) signalling as defined in [RFC-3471] and 39 [GMPLS-SONET-SDH]. Using [GMPLS-RTG] as guideline, this memo 40 specifies the GMPLS routing traffic engineering extensions to ISIS 41 for Sonet/SDH networks. 43 Based on the Traffic Engineering (TE) extensions defined in [ISIS- 44 TE], the proposed approach is aligned with link bundling as defined 45 in [MPLS-BDL] and extends the set of Extended IS Reachability sub- 46 TLVs proposed in [GMPLS-ISIS] to Sonet/SDH networks. The proposed 47 extensions do not preclude any further integration with the 48 Interface Switching Capability Descriptor specified in [GMPLS-ISIS]. 50 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 52 1. 53 Introduction 55 The approach proposed in this document is based on Traffic 56 Engineering (TE) extensions as defined in [ISIS-TE] which have been 57 extended for GMPLS in [GMPLS-ISIS]. The current proposal also uses 58 the notion Link Bundling and TE link as defined in [MPLS-BDL]. A set 59 of links between two adjacent GMPLS nodes (or simply nodes) is 60 defined as a TE link. GMPLS currently integrates the TE link notion 61 by detailing among others that several links having the same Traffic 62 Engineering (TE) capabilities (i.e. same TE metric, same set of 63 Resource Class and same Switching capability set) can be advertised 64 as a single TE link. Such TE links are referred to as link bundles 65 whose individual data bearing link (or simply links) are referred to 66 as component links when de/multiplexing capable. There is no longer 67 a one-to-one association between a regular routing adjacency and a 68 TE link. 70 However, the definition of the Extended IS Reachability sub-TLVs as 71 proposed in [ISIS-TE] and [GMPLS-ISIS] is mainly based on packet or 72 cell switching paradigm that uses statistical multiplexing at each 73 GMPLS nodes. The traffic in packet switched technologies is 74 described by various attributes such as peak rate, mean rate and 75 burst size and usually defined in bits or bytes per second. On the 76 contrary, Sonet/SDH does not provide statistical multiplexing; the 77 circuits must be multiplexed in a defined manner as specified in 78 [G.707] and [T1.105]. 80 Also, Sonet/SDH circuits can be interpreted like Constant Bit Rate 81 (or Peak Bit Rate) traffic with predefined classes such as VC-4-Nc 82 in SDH or STS-(3*N)c in Sonet. Hence the Maximum Reservable 83 Bandwidth (see [ISIS-TE]) can be mapped to the maximum VC-4-Nc (STS- 84 (3*N)c) that can be provided at the TE Link. But the definition of 85 Minimum/Maximum LSP Bandwidth included in the Interface Switching 86 Capability Descriptor (see [GMPLS-ISIS]) has to be extended in order 87 to reflect available multiplexing timeslots. For instance, the sum 88 of 4 times VC-4 does not necessarily mean that a VC-4-4c can be 89 used, as the VC-4s can be located in different AUG-4s. 91 In order to enable distributed Sonet/SDH network control, the link 92 state routing protocol has to enable the exchange of two different 93 sets (or types) of information. First, a set that describes the link 94 capabilities of a GMPLS Sonet/SDH node (or simply a node in this 95 context) and this, independently of their usage. Second, a set that 96 describes the Sonet/SDH resources (more precisely the timeslots) 97 that are in use at each TE link. 99 The first set can be defined as being driven by less frequent 100 updates (since TE Link capabilities changes are not expected to be 101 frequent) while the second would follow update interval values as 102 than the one used for any other non-technology dependent TE Link 103 attribute. We consider here that when this frequency is very low the 104 corresponding TE-link capability is static; by opposition, other are 105 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 107 referred to as dynamic. Details concerning update frequency usage 108 and related concepts are out of the scope of the current document. 110 In brief, the present memo proposes to review the current TE Link 111 sub-TLVs (and in particular the Interface Switching Capability sub- 112 TLV) to extend them for SDH/SONET technology. It memo defines two 113 additional sub-sets of information. Their flooding enables the 114 Traffic Engineering of the Sonet/SDH LSPs (i.e. the VT SPE/LOVC and 115 STS SPE/HOVC LSPs). The first set describes the Sonet/SDH TE Link 116 capabilities and this, independently of their usage. The second set 117 describes the resources utilization (referred to as timeslot 118 components allocation) used at each TE Link and expressed in terms 119 of number of unallocated components per TE Link. Last a detailed 120 comparison between the bandwidth encoding techniques introduced in 121 this document and the ones specified in [GMPLS-RTG] and [GMPLS-ISIS] 122 is proposed. Note also that [GMPLS-OSPF] specifics are addressed in 123 a companion document. 125 Conventions used in this document: 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 128 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 129 this document are to be interpreted as described in RFC 2119. 131 The reader is assumed to be familiar with the terminology in ANSI 132 [T1.105], ITU-T [G.707] as well as [RFC-3471], [GMPLS-RTG] and 133 [GMPLS-ISIS], [ISIS-TE] and referenced. ISIS specific terminology 134 can be found in [RFC-1195]. The following abbreviations are used in 135 this document: 137 DCC: Data Communications Channel. 138 LOVC: Lower Order Virtual Container 139 HOVC: Higher Order Virtual Container 140 MS: Multiplex Section. 141 MSOH: Multiplex Section overhead. 142 POH: Path overhead. 143 RS: Regenerator section. 144 RSOH: Regenerator section overhead. 145 SDH: Synchronous digital hierarchy. 146 SOH: Section overhead. 147 SONET: Synchronous Optical Network. 148 SPE: Synchronous Payload Envelope. 149 STM(-N): Synchronous Transport Module (-N) (SDH). 150 STS(-N): Synchronous Transport Signal-Level N (SONET). 151 VC-n: Virtual Container-n (SDH). 152 VTn: Virtual Tributary-n (SONET). 154 2. ISIS Routing Extensions 156 When using IS-IS, GMPLS TE links are advertised using LS PDUs. TE 157 Attributes TLVs are defined as sub-TLV for the Extended IS 158 Reachability TLV (Type 22) (see [ISIS-TE] and [GMPLS-ISIS]). 160 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 162 Here, we propose to extend the current sub-TLV set of Extended IS 163 Reachability TLV, respectively. The sub-TLVs describing the 164 capabilities of SONET/SDH TE Links are separately defined for 165 LOVC/VT and HOVC/STS SPE; these are: 167 1. Sonet/SDH TE Link capabilities: 169 - Multiplexing Capability sub-TLV 170 - Concatenation Capability sub-TLV 171 - Transparency Capability sub-TLV 173 2. Sonet/SDH TE Link component allocation: 175 - Component Allocation sub-TLV 177 Note: the proposed optional sub-TLVs are defined in a way that can 178 complement the Interface Switching Capability Descriptor sub-TLV of 179 the Extended IS Reachability TLV (see [GMPLS-ISIS]) when the 180 Switching Capability field value refers to TDM. Also, due to the 181 Extended IS Reachability TLV size limit to 244 octets a dedicated 182 TLV might be considered for the sake of technology specific 183 descriptors. 185 Also, it results from the TE Link definition (see [MPLS-BDL]) that 186 each of its component links SHOULD support the same multiplexing and 187 (virtual) concatenation capabilities. Note also that the 188 corresponding sub-TLVs are specified once, and apply to each 189 component link. No per component information or identification is 190 required for these sub-TLVs. 192 3. Additional Considerations 194 Between two adjacent nodes, several links having the same TE 195 capabilities (i.e. the same TE metric and the same set of Resource 196 Class) can be advertised as a single TE Link, such TE links are 197 referred to as link bundles. The individual links (or data bearing 198 links) belonging to a given bundle are referred to as component 199 links when they support multiplexing at each end. Also there is no 200 longer a one-to-one association between a regular routing adjacency 201 and a TE link. 203 In this context, each component of a TE Link may have the same 204 Sonet/SDH multiplexing and concatenation capabilities as defined 205 later in this document. The corresponding sub-TLVs are specified 206 once, but apply to each component of the TE Link. The TE Link 207 Sonet/SDH Component Allocation sub-TLV defined in Section 5 gives 208 the total number of unallocated components (i.e. timeslots) included 209 in a given TE Link. Hence, no per component information or 210 identification is required in that context. 212 Combined with the Link Property Correlation (see [LMP]) of data 213 links into TE Links (also referred to as link bundling) this 214 capability helps in removing the potential problem of flooding huge 215 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 217 amount of routing information. For instance, with a group of 10 218 fibers and 40 wavelengths per fiber, each of them supporting an STM- 219 64, there are potentially 76800 VC-3 timeslots that can be allocated 220 into the corresponding TE Link and that have therefore to be 221 advertised to all nodes within the same routing domain. The most 222 efficient way to proceed on a per-TE Link basis is to advertise the 223 number of unallocated components (i.e. timeslots) such that after 224 the initial advertisement, each node within a given routing area is 225 aware of total capacity per TE Link (see Section 5.1). 227 However, despite being bundled, the usage of each component link in 228 a TE Link may differ completely. For example, in a TE Link 229 comprising two components the first component could be structured in 230 VC-4-4c while the second component could be structured in VC-3s. 231 Likewise, each STM-i of an STM-N (N > 1) could also be structured 232 differently from the others. 234 Therefore, for given TE Link it is not sufficient to simply 235 represent the total number of timeslots (i.e. the bandwidth) that 236 are (un)allocated. It is also essential to know the corresponding 237 signal types. This because an allocated component does not only 238 consume a timeslot at a given position in the multiplex, it also 239 imposes some restrictions on the future allocations that can be made 240 from the free portion of the Sonet/SDH multiplex. This imposes 241 specific concatenation capability rules as described in Section 4.2. 243 The knowledge of the signal types that can be carried in the STS- 244 (3*N)/STM-N (N = 1, 4, 16, 64, 256) supported by the TE links are 245 needed for path computation purposes. When computing an explicit 246 route, a node considers the Interface Switching Capability 247 descriptor sub�TLV (see [GMPLS-ISIS]), the Multiplexing Capability 248 sub-TLV and Component Allocation sub-TLV to ensure that the path has 249 (a) the capability to carry the requested signal and (b) the 250 sufficient available bandwidth (i.e. enough timeslot in the 251 Sonet/SDH multiplex on this interface) to carry the requested 252 signal. 254 4. TE Link Capabilities 256 There are three Sonet/SDH TE Link capabilities that can be 257 advertised in the routing protocols: the multiplexing capabilities, 258 the concatenation and the transparency capability. 260 4.1 Sonet/SDH TE Link Multiplexing Capability 262 The purpose of the TE Link multiplexing capability is to succinctly 263 describe the types of Sonet/SDH signals that can be multiplexed by a 264 Sonet/SDH TE Link for explicit route computation purposes. For 265 example, depending on how it is structured, an OC-48/STM-16 link may 266 be able to multiplex a variety of signal types. 268 4.1.1 Structure of Sonet/SDH Multiplexing Capabilities 269 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 271 GMPLS-based control of Sonet/SDH networks enables the control of 272 multiplex structures at a finer level of granularity than both STS- 273 (3*N)/STM-N with N = 1, 4, 16, 64, 256 and STM-0/STS-1. These 274 multiplexing structures are defined in [T1.105] and [G.707]. 276 4.1.2 Sonet/SDH TE Link Multiplexing Capability sub-TLV 278 The Multiplexing Capability optional sub-TLV describes the 279 multiplexing capabilities of the STS-(3*N)/STM-N (with N = 1, 4, 16, 280 64, 256) components of Sonet/SDH TE Links. It indicates precisely 281 the types of elementary signal that can be multiplexed by this link. 283 This TLV is a sub-TLV of the Extended IS Reachability TLV (TLV 22) 284 with Type TBD. The Low Order Multiplexing Capability Flag (LO MC 285 Flag) field is defined as a vector of flags and coded over one 286 octet. The High Order Multiplexing Capability Flag (HO MC Flag) 287 field is defined as a vector of flags and coded over one octet: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | HO MC Flag | LO MC Flag | Reserved | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Fig 1. Sonet/SDH TE Link Multiplex Capability sub-TLV 297 These fields defined separately for both High Order (HO) and Low 298 Order (LO) Sonet/SDH signals are vectors of bit flags. Each MC Flag 299 bit indicates the capability of the TE link components to multiplex 300 a given signal into the higher order signal in the Sonet/SDH 301 multiplex. A bit value of 1 indicates that the multiplexing 302 capability is supported while a bit value of 0 indicates that the 303 multiplexing capability is not supported. Bit 1 is the lowest order 304 bit of the flag field. 306 The Sonet/SDH High Order MC Flag field is defined as: 308 - Bit 1 : /VC-3 in TUG-3 309 - Bit 2 : /TUG-3 in AUG-1 (via VC-4) 310 - Bit 3 : STS-1 in STSG-3 /AU-3 in AUG-1 311 - Bit 4 : STSG-3 in STSG-12 /AUG-1 in AUG-4 312 - Bit 5 : STSG-12 in STSG-48 /AUG-4 in AUG-16 313 - Bit 6 : STSG-48 in STSG-192/AUG-16 in AUG-64 314 - Bit 7 : STSG-192 in STSG-768/AUG-64 in AUG-256 315 - Bit 8 : Reserved 317 In SDH, the High Order MC Flag can for instance take the following 318 values: 319 - 0b01111111 (0x7f): indicates a full SDH HO multiplexing capability 320 - 0b00001111 (0x0f): indicates a full AUG-4 (within an STM-4) 321 multiplexing capability 322 - 0b01111000 (0x78): indicates that the lowest multiplexing 323 capability is AUG-1 (with C4->VC4->AU4->AUG1) 324 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 326 Similarly, the Sonet/SDH Low Order MC Flag is defined as: 328 - Bit 1 : VT-1.5 SPE in VT Group /VC-11 in TUG-2 329 - Bit 2 : VT-2 SPE in VT Group /VC-12 in TUG-2 330 - Bit 3 : VT-3 SPE in VT Group / 331 - Bit 4 : VT-6 SPE in VT Group /VC-2 in TUG-2 332 - Bit 5 : VT-Group in STS-1 SPE/TUG-2 in AU-3 333 - Bit 6 : /TUG-2 in TUG-3 334 - Bit 7 : reserved 335 - Bit 8 : reserved 337 For SDH, the Low Order MC-Flag can for instance take the following 338 values: 339 - 0b00100010 (0x22): indicates that VC-12 can only be multiplexed in 340 VC-3 (through TUG-2) 341 - 0b00101000 (0x28): indicates that VC-2 can only be multiplexed in 342 VC-3 (through TUG-2) 344 Note: A binary value of 0b0...0 when advertised indicates no 345 Sonet/SDH multiplexing capability at all. Therefore referring to 346 single VC-4-Nc in AUG-N/STM-N or STS-(3*N)c in STSG-(3*N)/STS-(3*N) 347 capable interfaces. 349 4.2 Sonet/SDH TE Link Concatenation Capability sub-TLV 351 Contiguous and Virtual concatenation of Low Order (LO) and High 352 Order (HO) SONET and SDH signals are respectively defined in 353 [T1.105] and [G.707]. 355 4.2.1 SDH TE Link Concatenation Capability sub-TLV 357 For SDH, the TE Link Concatenation Capability sub-TLV describes the 358 SDH concatenation capabilities of a TE link. This TLV is defined as 359 an optional sub-TLV of Extended IS Reachability TLV (see [ISIS-TE]) 360 with Type TBD. The corresponding encoding and values are defined for 361 Low Order and High Order VCs. If no concatenation is supported on a 362 TE Link, this sub-TLV SHOULD not be advertised. 364 1. Low Order VC (LOVC) Concatenation 366 LOVC Concatenation includes: 367 - Contiguous concatenation of X VC-2s (VC-2-Xc, X = 1,...,7) 368 - Virtual concatenation of X VC-2/12/11s (VC-m-Xv, m = 11,12,2) 369 as defined in the following table: 371 Signal Carried in X interval 372 -------------------------------------------------- 373 VC-11-Xv VC-3 1 to 28 374 VC-12-Xv VC-3 1 to 21 375 VC-2-Xv VC-3 1 to 7 376 VC-11-Xv VC-4 1 to 64 377 VC-12-Xv VC-4 1 to 63 378 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 380 VC-2-Xv VC-4 1 to 21 382 The TE Link Concatenation Capability optional sub-TLV has the 383 following format: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Signal Type | CT | Res. | LT | List Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | NCC | . . . | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | NCC | . . . | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 // . . . // 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Signal Type | CT | Res. | LT | List Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | NCC | . . . | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | NCC | . . . | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Fig 2. TE Link Concatenation Capability sub-TLV 407 Signal Type (8 bits): 409 The Signal Type field values are defined in [GMPLS-SONET-SDH]. 411 CT � Concatenation Type (4 bits): 413 The CT field is defined as a 4-bit vector of flags (with bit 1 414 defined as the low order bit). A flag set to 1 indicates the 415 support of the corresponding concatenation type: 417 Flag 1 (Bit 1): Contiguous Concatenation 418 Flag 2 (Bit 2): Virtual Concatenation 419 Flag 3 (Bit 3): Reserved 420 Flag 4 (Bit 4): Reserved 422 Reserved flags MUST be set to zero when sent and ignored when 423 received. 425 Reserved (4 bits): 427 The Reserved field bits must be set to zero when sent and 428 should be ignored when received. 430 LT � List Type (4 bits): 432 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 434 The LT field indicates the type of the list; the following 435 values are defined (the values to which multiple lists refer 436 must be mutually disjoint): 438 0x0000 Reserved 439 0x0001 Inclusive list 440 0x0010 Exclusive list 441 0x0011 Inclusive range (one or more Minimum/Maximum pairs) 442 0x0100 Exclusive range (one or more Minimum/Maximum pairs) 444 Values ranging from 0x0101 to 0x1111 are reserved, they must be 445 set to zero when sent and should be ignored when received. At 446 most one LT value is allowed per sub-TLV (this limits its 447 length). Therefore, this sub-TLV includes at most four sub- 448 lists. 450 List Length (12 bits): 452 The List Length field indicates the number N of NCC fields (of 453 16 bits) comprised in a given list including the zero padding 454 field. Zero is an invalid value (or equivalently, N MUST be 455 greater than 0 and the minimum sub-TLV length is 8 octets). 457 NCC - Number of Concatenated Components (16 bits): 459 The NCC field indicates the supported number of low order VC�s 460 with respect to the Signal Type and the CT values. A NCC value 461 equal to zero refers to a zero padding field. For SDH LOVCs, 462 the number of VC-m�s values MUST refer to one or more of the 463 following values (as defined in the Signal Type field): VC-11, 464 VC-12 and/or VC-2. 466 When the LT field value equals 2 or 3, at least one pair of 467 LOVC�s numbers (i.e. two NCC fields) must be included in the 468 list. The first value indicates the minimum number of LOVC�s 469 and the second one the maximum number of LOVC�s supported (or 470 not supported, respectively) with the selected concatenation 471 type (CT). 473 Note: for a given Signal Type when this sub-TLV includes 474 several lists (defined with the same Type or not), the NCC 475 values that each list contain MUST be mutually consistent. 477 2. High Order VC (HOVC) Concatenation: 479 HOVC Concatenation includes: 480 - Contiguous concatenation of X VC-4s (VC-4-Xc, X = 4,16,64,256) 481 - Virtual concatenation of X VC-3/4s (VC-3/4-Xv, X = 1,...,256) 483 The SDH HOVC TE Link Concatenation Capability TLV has exactly the 484 same format and encoding as the one defined here above: 486 Signal Type (8 bits): see above. 488 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 490 CT � Concatenation Type (4 bits): see above. 492 Reserved (4 bits): see above. 494 LT � List Type (4 bits): see above. 496 List Length (12 bits): see above. 498 NCC - Number of Concatenated Components (16 bits): 500 The NCC field indicates the supported number of high order VC�s 501 with respect to the Signal Type (i.e. VC-3 and/or VC-4) and the 502 CT values. A NCC value equal to zero refers to a zero padding 503 field. 505 When the LT field value equals 2 or 3, at least one pair of 506 HOVC�s numbers (i.e. two NCC fields) must be included in the 507 list. The first value indicates the minimum number of HOVC�s 508 and the second one the maximum number of HOVC�s supported (or 509 not supported, respectively) with the selected concatenation 510 type (CT). 512 Note: for a given Signal Type, when this sub-TLV includes 513 several lists (defined with the same Type or not), the NCC 514 values that each list contain MUST be mutually consistent. 516 4.2.2 Sonet TE Link Concatenation Capability sub-TLV 518 Using the STS-1 SPE and STS-3c SPE equivalence to a VC-3 and a VC-4, 519 respectively, the above definition of high order Concatenation 520 Capability sub-TLV applies. Notice that in SONET, contiguous 521 concatenation is applicable to STS-3c SPE signals, resulting in STS- 522 (3*X)c SPE signals with X = 4,16,64,256. For low order signal, only 523 virtual concatenation of X VTn SPEs (VTn-Xv SPE, n = 1.5,2,3,6) must 524 be considered since low order contiguous concatenation is not 525 defined in ANSI [T1.105]. 527 This optional sub-TLV is defined (see also Section 4.2.1) of 528 Extended IS Reachability TLV (see [ISIS-TE]) with Type TBD. The 529 corresponding encoding and values are defined for Low Order and High 530 Order VCs. 532 1. Low order VT SPEs concatenation: 534 - Virtual concatenation of X VTn�s SPE (VTn-Xv SPE, n = 1.5,2,3, 535 6) as defined in the following table: 537 Signal Carried in X interval 538 -------------------------------------------------- 539 VT1.5-Xv SPE STS-1 1 to 28 540 VT2-Xv SPE STS-1 1 to 21 541 VT3-Xv SPE STS-1 1 to 14 542 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 544 VT6-Xv SPE STS-1 1 to 7 545 VT1.5-Xv SPE STS-3c 1 to 64 546 VT2-Xv SPE STS-3c 1 to 63 547 VT3-Xv SPE STS-3c 1 to 42 548 VT6-Xv SPE STS-3c 1 to 21 550 The format and encoding for the Low Order SONET TE Link 551 Concatenation Capability TLV is identical to the one defined for 552 SDH LOVC TE Links (see Section 4.2.1). 554 2. High order STS SPEs concatenation: 556 - Contiguous concatenation of X STS-3c SPEs (STS-(3*X)c with X = 557 4,16,64,256) 558 - Virtual concatenation of X STS-1/STS-3c SPEs (STS-1-Xv/STS-3c- 559 Xv with X = 1,...,256) 561 The format and encoding for the High Order SONET TE Link 562 Concatenation Capability TLV is identical to the one defined for 563 SDH HOVC TE Links (see Section 4.2.1). 565 4.3 Sonet/SDH TE Link Transparency Capability sub-TLV 567 This optional sub-TLV is defined as a vector of flags that indicates 568 the type of transparency supported by each of the component of a 569 given TE Link. Therefore it SHOULD be used only when these 570 components supports transparent signal types (see [GMPLS-SONET- 571 SDH]). 573 Several flags can be combined to provide different types of 574 transparency while any combination is not necessarily valid. By 575 default, the supported transparency on a TE Link is defined as the 576 Path Overhead (POH) transparency; therefore this sub-TLV should not 577 be sent for a TE Link only supporting POH transparency. 579 Note that when this sub-TLV is advertised, the Signal Type(s) 580 field(s) in the sub-TLV defined in Section 5 MUST take at least one 581 of the following values (see [GMPLS-SONET-SDH]): STS-1/STM-0, STS- 582 3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64 and STS- 583 768/STM-256. Equivalently, at least one transparency type MUST be 584 specified when advertising such Signal Type(s) in this sub-TLV. 586 This TLV is defined as a sub-TLV of the Extended IS Reachability TLV 587 (see [ISIS-TE]) with Type TBD and a length of four octets. It 588 includes the Transparency field defined as a 32-bit vector of flags. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Transparency (T) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Fig 3. Sonet/SDH TE Link Transparency Capability sub-TLV 597 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 599 The different transparency flags are the following: 601 Flag 1 (bit 1): Section/Regenerator Section layer 602 Flag 2 (bit 2): Line/Multiplex Section layer 604 Where bit 1 is the low order bit. Others flags are reserved, they 605 should be set to zero when sent, and must be ignored when received. 606 A flag is set to one to indicate that the corresponding transparency 607 is supported on the corresponding TE link. Additional flagging rules 608 MUST follow the rules defined in [GMPLS-SONET-SDH]. 610 5. TE Link Component Allocation 612 TE Link component allocation refers to the actual resource 613 utilization status of a TE link (representing either a single 614 component link or a bundled link). In the Sonet/SDH context, this 615 information can be represented by the number of unallocated (free) 616 timeslots per signal type and per TE link. 618 5.1 Sonet/SDH TE Link Component Allocation sub-TLV 620 The Sonet/SDH TE Link Component Allocation sub-TLV specifies the 621 number of identical unallocated timeslots per TE Link. As such, the 622 initial value(s) of this TLV indicates the total capacity in terms 623 of number of timeslot (per Signal Type) per TE link. 625 This TLV is defined as a sub-TLV of Extended IS Reachability TLV 626 (see [ISIS-TE]) with Type TBD and a length of n*4 octets. Each of 627 the n fields gives the number of unallocated timeslot per Signal 628 Type (per TE Link) and comprises a Signal Type field (8 bits) and a 629 Number of Unallocated Timeslot field (24 bits). The Signal Type 630 field values are defined in [GMPLS-SONET-SDH]. 632 Typically, this sub-TLV will be advertised by including Signal 633 Type(s) of the same order since one expects (as it is mostly the 634 case in legacy networks) separated routing instances between Low 635 Order and High Order VC transport layers. 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Signal Type | Number of Unallocated Timeslots | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Signal Type | Number of Unallocated Timeslots | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 // . . . // 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Signal Type | Number of Unallocated Timeslots | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 652 Fig 4. Sonet/SDH TE Link Component Allocation sub-TLV 654 For instance, if a TE Link is constituted by 40 STM-64, each of them 655 decomposed in VC-4, initially the value of the Number of Unallocated 656 Timeslots field of this TLV is 40 x 64. Thus, 2560 VC-4 signals are 657 supported, and, if required, 2560 instances of exactly the same 658 signal can be allocated. 660 Note: for transparent Signal Types such as STS-(3*N)/STM-N (see 661 [GMPLS-SONET-SDH]), this number simply refers to the number of 662 interfaces supported at each end of the TE Link. 664 5.2 Sonet/SDH TE Link Contiguous Component Allocation 666 Contiguous concatenation of Low Order (LO) and High Order (HO) SONET 667 and SDH signals are respectively defined in [T1.105] and [G.707]. 668 Here, instead of advertising the concatenation capabilities (as 669 defined in Section 4.2), and provide a countdown on a per-timeslot 670 basis as defined in Section 5.1, an alternative way for the 671 representation of the component allocation in case of contiguous 672 concatenation capable TE links consists in defining additional 673 signal type values. In particular: 675 Value Type (Elementary Signal) 676 ----- ------------------------ 677 TBA STS-12c SPE / VC-4-4c 678 TBA STS-48c SPE / VC-4-16c 679 TBA STS-192c SPE / VC-4-64c 680 TBA STS-768c SPE / VC-4-256c 682 These Signal Type field values extends the set of values defined in 683 [GMPLS-SONET-SDH] and allows for an efficient accounting of the 684 timeslot allocation on interfaces supporting (simultaneously) 685 multiple contiguous concatenation types. Also, in this case, the 686 Concatenation Capability sub-TLV (See Section 4.2) SHOULD not be 687 used. 689 Example: A given Sonet/SDH STM-256 interface supporting all the 690 above contiguous concatenation is initially advertised with the 691 following capacity (timeslots being numbered from 0 to 255): 693 Signal Type Number of Unallocated Timeslot 694 Init VC-4#0 VC-4#4 VC-4-4c#64 VC4-16c#128 695 ----------- ------------------------------------------------------ 696 VC-4 256 255 254 250 234 697 VC-4-4c 64 63 62 61 57 698 VC-4-16c 16 15 15 14 13 699 VC-4-64c 4 3 3 2 1 700 VC-4-256c 1 0 0 0 0 702 Here, (0,0,0,0,0) indicates the first AUG-256 (first letter), first 703 AUG-64 (second letter), first AUG-16 (third letter), first AUG-4 704 (forth letter), first AUG-1 (fifth letter). 706 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 708 For instance, after a first VC-4 timeslot gets allocated at position 709 0 (0,0,0,0,0), (disables the availability of the VC-4-256c, first 710 VC-4-64c, the first VC-4-16c and first VC-4-4c) the values indicated 711 in column 2 are advertised. A second VC-4 timeslot gets allocated at 712 position 4 (0,0,0,1,0), (disabling the second VC-4-4c) implying the 713 information indicated in column 3 is advertised. Then, on the same 714 link, a VC-4-4c timeslot gets allocated at position 64 (0,1,0,0,0), 715 (disables the second VC-4-64c, the first VC-4-16c, and its 716 underlying VC-4-4c and VC-4s (4 times)) the number of unallocated 717 timeslots indicated in column 4 is advertised. Last, a VC-4-16c 718 timeslot gets allocated at position 128 (disables the third VC-4-64c 719 and its underlying VC-4-4cs (4 times) and VC-4s (16 times)), the 720 values of column 5 are advertised. 722 It should be noted that the description above is given for 723 understanding reasons. Usually the label allocation process should 724 allocate labels in a more sophisticated way by limiting 725 fragmentation of the multiplex structure. As an example the VC-4#4 726 should be allocated at position 1, the VC-4-4c#64 should be 727 allocated at position 4 and the VC4-16c should be allocated at 728 position 16. The table below shows the difference that there is 729 still a possibility to allocate 3 VC-4-64c at this interface. 731 Signal Type Number of Unallocated Timeslot 732 Init VC-4#0 VC-4#1 VC-4-4c#4 VC-4-16c#16 733 ----------- ------------------------------------------------------ 734 VC-4 256 255 254 250 234 735 VC-4-4c 64 63 63 62 58 736 VC-4-16c 16 15 15 15 14 737 VC-4-64c 4 3 3 3 3 738 VC-4-256c 1 0 0 0 0 740 Note also that the following accounting is forbidden taking for 741 instance an STM-16 interface where, 4 VC-4s are allocated at 742 position 0, 4, 8 and 12, respectively as each VC-4 is located in 743 different a AUG-4 group. 745 Signal Type Number of Unallocated Timeslot 746 ----------- ------------------------------ 747 VC-4 12 748 VC-4-4c 3 749 VC-4-16c 0 751 The corresponding values MUST be assigned as follows: 753 Signal Type Number of Unallocated Timeslot 754 ----------- ------------------------------ 755 VC-4 12 756 VC-4-4c 0 757 VC-4-16c 0 759 5.3 Minimum/Maximum LSP Bandwidth 760 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 762 The third representation makes usage of the Minimum/Maximum LSP 763 Bandwidth as defined in [GMPLS-RTG]. It has to be noticed that in 764 this case (taking into account the above example), that the Minimum 765 LSP Bandwidth would correspond to a VC-4 and the Maximum LSP 766 Bandwidth to a VC-4-256c (and thus the Unreserved Bandwidth on that 767 link). 769 Also the Maximum LSP Bandwidth can vary over time as timeslots gets 770 allocated. In the above example, it would range from a VC-4-256c 771 initially to a VC-4-64c afterwards. On the contrary the Minimum LSP 772 Bandwidth does not change unless all the 256 VC-4 timeslots have 773 been allocated on that link. 775 5.4 Comparison and Tradeoffs 777 The method proposed in Section 5.3 is the most straightforward 778 without requiring any bandwidth accounting change from an LSR 779 perspective. The lost of information only affects the number of 780 signals that can be used but not the range they cover. On the other 781 hand, when additional technology specific information are advertised 782 (see Section 4, 5.1 and 5.2) a finer grained resource countdown and 783 accounting can be performed allowing for network wide resource 784 allocation in Sonet/SDH environments. 786 It has to be emphasized that the behavior of the Concatenation 787 Capability sub-TLV (as defined in Section 4.2) is equivalent to the 788 one specified when advertising Minimum/Maximum LSP Bandwidth. Note 789 that the update frequency of the TLV is not affected by the 790 technology specific methods because the former implies variation of 791 the Unreserved Bandwidth sub-TLV when timeslots are allocated. Hence 792 from this perspective, both classes of solutions are equivalent. 794 7. Security Considerations 796 Routing protocol related security considerations are identical to 797 the on referenced in [GMPLS-ISIS] and [ISIS-TE]. 799 8. References 801 8.1 Normative References 803 [G.707] ITU-T Recommendation G.707, "Network Node Interface for 804 the Synchronous Digital Hierarchy", October 2000. 806 [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized MPLS (GMPLS) 807 Architecture," Internet Draft, Work in Progress, draft- 808 ietf-ccamp-gmpls-architecture-03.txt, August 2002. 810 [GMPLS-ISIS] K.Kompella et al, "IS-IS Extensions in Support of 811 Generalized MPLS," Internet Draft, Work in Progress, 812 draft-ietf-isis-gmpls-extensions-16.txt, January 2003. 814 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 816 [GMPLS-RTG] K.Kompella et al., "Routing Extensions in Support of 817 Generalized MPLS," Internet Draft, Work in Progress, 818 draft-ietf-ccamp-gmpls-routing-05.txt, August 2002. 820 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors), 821 "GMPLS extensions for SONET and SDH control", Internet 822 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- 823 sdh-07.txt, October 2002. 825 [ISIS-TE] H.Smith and T.Li, "ISIS Extensions for Traffic 826 Engineering", draft-ietf-isis-traffic-04.txt, Internet 827 Draft, Work in Progress, June 2001. 829 [MPLS-BDL] K.Kompella et al., "Link Bundling in MPLS Traffic 830 Engineering," Internet Draft, Work in Progress, draft- 831 ietf-mpls-bundle-04.txt, August 2002. 833 [MPLS-HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with 834 Generalized MPLS TE", Internet Draft, Work in Progress, 835 draft-ietf-mpls-lsp-hierarchy-08.txt, August 2002. 837 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, March 1997. 840 [RFC-3471] L.Berger (Editor) et al., "Generalized MPLS � 841 Signaling Functional Description", RFC 3471, IETF 842 Proposed Standard, January 2003. 844 [T1.105] American National Standards Institute, "Synchronous 845 Optical Network - Payload Mappings", T1.105, January 846 2001. 848 9. Author's Addresses 850 Dimitri Papadimitriou (Alcatel) 851 Francis Wellesplein 1, 852 B-2018 Antwerpen, Belgium 853 Phone: +32 3 240-8491 854 Email: dimitri.papadimitriou@alcatel.be 856 Eric Mannie (Consult) 857 Email: eric_mannie@hotmail.com 858 draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt Feb'03 860 Full Copyright Statement 862 "Copyright (C) The Internet Society (date). All Rights Reserved. 864 This document and translations of it may be copied and furnished to 865 others, and derivative works that comment on or otherwise explain it 866 or assist in its implementation may be prepared, copied, published 867 and distributed, in whole or in part, without restriction of any 868 kind, provided that the above copyright notice and this paragraph 869 are included on all such copies and derivative works. However, this 870 document itself may not be modified in any way, such as by removing 871 the copyright notice or references to the Internet Society or other 872 Internet organizations, except as needed for the purpose of 873 developing Internet standards in which case the procedures for 874 copyrights defined in the Internet Standards process must be 875 followed, or as required to translate it into languages other than 876 English. 878 The limited permissions granted above are perpetual and will not be 879 revoked by the Internet Society or its successors or assigns. 881 This document and the information contained herein is provided on an 882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 884 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 885 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 886 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."