idnits 2.17.1 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt: -(510): 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 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-OSPF], [MPLS-BDL], [GMPLS-SONET-SDH], [GMPLS-RTG], [RFC-3471], [OSPF-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 342 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 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. == 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 860, but not defined == Missing Reference: 'LMP' is mentioned on line 219, but not defined == Unused Reference: 'GMPLS-ARCH' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'MPLS-HIER' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'OSPF-DNA' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 909, 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 (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-07) exists of draft-pillay-esnault-ospf-flooding-04 ** Downref: Normative reference to an Informational draft: draft-pillay-esnault-ospf-flooding (ref. 'OSPF-DNA') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-09 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) Summary: 8 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 Eric Mannie (Consult) 3 Internet Draft Dimitri Papadimitriou (Alcatel) 4 Expiration Date: August 2003 5 February 2003 7 Traffic Engineering Extensions to OSPF 8 for Generalized MPLS control of Sonet/SDH Networks 10 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.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 OSPF 41 for Sonet/SDH networks. 43 Based on the Traffic Engineering (TE) extensions defined in [OSPF- 44 TE], the proposed approach is aligned with link bundling as defined 45 in [MPLS-BDL] and extends the set of Link sub-TLVs proposed in 46 [GMPLS-OSPF] to Sonet/SDH networks. The proposed extensions do not 47 preclude any further integration with the Interface Switching 48 Capability Descriptor specified in [GMPLS-OSPF]. 50 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 52 1. Introduction 54 The approach proposed in this document is based on Traffic 55 Engineering (TE) extensions as defined in [OSPF-TE] which have been 56 extended for GMPLS in [GMPLS-OSPF]. The current proposal also uses 57 the notion Link Bundling and TE link as defined in [MPLS-BDL]. A set 58 of links between two adjacent GMPLS nodes (or simply nodes) is 59 defined as a TE link. GMPLS currently integrates the TE link notion 60 by detailing among others that several links having the same Traffic 61 Engineering (TE) capabilities (i.e. same TE metric, same set of 62 Resource Class and same Switching capability set) can be advertised 63 as a single TE link. Such TE links are referred to as link bundles 64 whose individual data bearing link (or simply links) are referred to 65 as component links when de/multiplexing capable. There is no longer 66 a one-to-one association between a regular routing adjacency and a 67 TE link. 69 However, the definition of (TE) Link sub-TLV as proposed in [OSPF- 70 TE] and [GMPLS-OSPF] is mainly based on packet or cell switching 71 paradigm that uses statistical multiplexing at each GMPLS nodes. The 72 traffic in packet switched technologies is described by various 73 attributes such as peak rate, mean rate and burst size and usually 74 defined in bits or bytes per second. On the contrary, Sonet/SDH does 75 not provide statistical multiplexing; the circuits must be 76 multiplexed in a defined manner as specified in [G.707] and 77 [T1.105]. 79 Also, Sonet/SDH circuits can be interpreted like Constant Bit Rate 80 (or Peak Bit Rate) traffic with predefined classes such as VC-4-Nc 81 in SDH or STS-(3*N)c in Sonet. Hence the Maximum Reservable 82 Bandwidth (see [OSPF-TE]) can be mapped to the maximum VC-4-Nc (STS- 83 (3*N)c) that can be provided at the TE Link. But the definition of 84 Minimum/Maximum LSP Bandwidth included in the Interface Switching 85 Capability Descriptor (see [GMPLS-OSPF]) has to be extended in order 86 to reflect available multiplexing timeslots. For instance, the sum 87 of 4 times VC-4 does not necessarily mean that a VC-4-4c can be 88 used, as the VC-4s can be located in different AUG-4s. 90 In order to enable distributed Sonet/SDH network control, the link 91 state routing protocol has to enable the exchange of two different 92 sets (or types) of information. First, a set that describes the link 93 capabilities of a GMPLS Sonet/SDH node (or simply a node in this 94 context) and this, independently of their usage. Second, a set that 95 describes the Sonet/SDH resources (more precisely the timeslots) 96 that are in use at each TE link. 98 The first set can be defined as being driven by less frequent 99 updates (since TE Link capabilities changes are not expected to be 100 frequent) while the second would follow update interval values as 101 than the one used for any other non-technology dependent TE Link 102 attribute. We consider here that when this frequency is very low the 103 corresponding TE-link capability is static; by opposition, other are 104 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 106 referred to as dynamic. Details concerning update frequency usage 107 and related concepts are out of the scope of the current document. 109 In brief, the present memo proposes to review the current TE Link 110 sub-TLVs (and in particular the Interface Switching Capability sub- 111 TLV) to extend them for SDH/SONET technology. It memo defines two 112 additional sub-sets of information. Their flooding enables the 113 Traffic Engineering of the Sonet/SDH LSPs (i.e. the VT SPE/LOVC and 114 STS SPE/HOVC LSPs). The first set describes the Sonet/SDH TE Link 115 capabilities and this, independently of their usage. The second set 116 describes the resources utilization (referred to as timeslot 117 components allocation) used at each TE Link and expressed in terms 118 of number of unallocated components per TE Link. Last a detailed 119 comparison between the bandwidth encoding techniques introduced in 120 this document and the ones specified in [GMPLS-RTG] and [GMPLS-OSPF] 121 is proposed. Note also that [GMPLS-ISIS] specifics are addressed in 122 a companion document. 124 Conventions used in this document: 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 127 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 128 this document are to be interpreted as described in RFC 2119. 130 The reader is assumed to be familiar with the terminology in ANSI 131 [T1.105], ITU-T [G.707] as well as [RFC-3471], [GMPLS-RTG] and 132 [GMPLS-OSPF] and referenced. The following abbreviations are used in 133 this document: 135 DCC: Data Communications Channel. 136 LOVC: Lower Order Virtual Container 137 HOVC: Higher Order Virtual Container 138 MS: Multiplex Section. 139 MSOH: Multiplex Section overhead. 140 POH: Path overhead. 141 RS: Regenerator Section. 142 RSOH: Regenerator section overhead. 143 SDH: Synchronous digital hierarchy. 144 SOH: Section overhead. 145 SONET: Synchronous Optical Network. 146 SPE: Synchronous Payload Envelope. 147 STM(-N): Synchronous Transport Module (-N) (SDH). 148 STS(-N): Synchronous Transport Signal-Level N (SONET). 149 VC-n: Virtual Container-n (SDH). 150 VTn: Virtual Tributary-n (SONET). 152 2. OSPF Routing Extensions 154 In OSPF, GMPLS TE links can be advertised using Opaque LSAs (Link 155 State Advertisements) of Type 10 (see [RFC-2370]). This Traffic 156 Engineering (TE) LSA with area flooding scope is defined in [OSPF- 157 TE] and has one top-level Type/Length/Value (TLV) triplet and one or 158 more nested sub-TLVs for extensibility. Also, nodes shall originate 159 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 161 TE LSAs whenever their content change, and whenever required by OSPF 162 (for example, originate an LSA refresh when the LSA age field 163 reaches the LSRefreshTime). However, this does not mean that every 164 LSA contents change must be flooded immediately. As specified in 165 [RFC-2328], the origination of TE LSAs SHOULD be rate-limited to at 166 most one every MinLSInterval. Upon receipt of a changed TE LSA or 167 Network LSA (since these are used in TE calculations), the node 168 should update its TE Link state database without necessarily 169 performing any (Constraint-)SPF or other path computation. 171 Per [OSPF-TE], two top-level TLVs are defined (1) the Router Address 172 TLV (referred to as the Node TLV) and (2) the TE Link TLV. This memo 173 extends the current sub-TLV set of the TE Link TLV by defining: 175 1. Sonet/SDH TE Link capabilities: 177 - Multiplexing Capability sub-TLV 178 - Concatenation Capability sub-TLV 179 - Transparency Capability sub-TLV 181 2. Sonet/SDH TE Link component allocation: 183 - Component Allocation sub-TLV 185 Note: the proposed optional sub-TLVs are defined in a way that can 186 complement the Interface Switching Capability Descriptor sub-TLV of 187 the TE Link TLV (see [GMPLS-OSPF]) when the Switching Capability 188 field value refers to TDM. 190 It results from the TE Link definition (see [MPLS-BDL]) that each of 191 its component links SHOULD support the same multiplexing and 192 (virtual) concatenation capabilities. Note also that the 193 corresponding sub-TLVs are specified once, and apply to each 194 component link. No per component information or identification is 195 required for these sub-TLVs. 197 3. Additional Considerations 199 Between two adjacent nodes, several links having the same TE 200 capabilities (i.e. the same TE metric and the same set of Resource 201 Class) can be advertised as a single TE Link, such TE links are 202 referred to as link bundles. The individual links (or data bearing 203 links) belonging to a given bundle are referred to as component 204 links when they support multiplexing at each end. Also there is no 205 longer a one-to-one association between a regular routing adjacency 206 and a TE link. 208 In this context, each component of a TE Link may have the same 209 Sonet/SDH multiplexing and concatenation capabilities as defined 210 later in this document. The corresponding sub-TLVs are specified 211 once, but apply to each component of the TE Link. The TE Link 212 Sonet/SDH Component Allocation sub-TLV defined in Section 5 gives 213 the total number of unallocated components (i.e. timeslots) included 214 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 216 in a given TE Link. Hence, no per component information or 217 identification is required in that context. 219 Combined with the Link Property Correlation (see [LMP]) of data 220 links into TE Links (also referred to as link bundling) this 221 capability helps in removing the potential problem of flooding huge 222 amount of routing information. For instance, with a group of 10 223 fibers and 40 wavelengths per fiber, each of them supporting an STM- 224 64, there are potentially 76800 VC-3 timeslots that can be allocated 225 into the corresponding TE Link and that have therefore to be 226 advertised to all nodes within the same routing domain. The most 227 efficient way to proceed on a per-TE Link basis is to advertise the 228 number of unallocated components (i.e. timeslots) such that after 229 the initial advertisement, each node within a given routing area is 230 aware of total capacity per TE Link (see Section 5.1). 232 However, despite being bundled, the usage of each component link in 233 a TE Link may differ completely. For example, in a TE Link 234 comprising two components the first component could be structured in 235 VC-4-4c while the second component could be structured in VC-3s. 236 Likewise, each STM-i of an STM-N (N > 1) could also be structured 237 differently from the others. 239 Therefore, for given TE Link it is not sufficient to simply 240 represent the total number of timeslots (i.e. the bandwidth) that 241 are (un)allocated. It is also essential to know the corresponding 242 signal types. This because an allocated component does not only 243 consume a timeslot at a given position in the multiplex, it also 244 imposes some restrictions on the future allocations that can be made 245 from the free portion of the Sonet/SDH multiplex. This imposes 246 specific concatenation capability rules as described in Section 4.2. 248 The knowledge of the signal types that can be carried in the STS- 249 (3*N)/STM-N (N = 1, 4, 16, 64, 256) supported by the TE links are 250 needed for path computation purposes. When computing an explicit 251 route, a node considers the Interface Switching Capability 252 descriptor sub�TLV (see [GMPLS-OSPF]), the Multiplexing Capability 253 sub-TLV and Component Allocation sub-TLV to ensure that the path has 254 (a) the capability to carry the requested signal and (b) the 255 sufficient available bandwidth (i.e. enough timeslot in the 256 Sonet/SDH multiplex on this interface) to carry the requested 257 signal. 259 4. TE Link Capabilities 261 There are three Sonet/SDH TE Link capabilities that can be 262 advertised in the routing protocols: the multiplexing capabilities, 263 the concatenation and the transparency capability. 265 4.1 Sonet/SDH TE Link Multiplexing Capability 267 The purpose of the TE Link multiplexing capability is to succinctly 268 describe the types of Sonet/SDH signals that can be multiplexed by a 269 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 271 Sonet/SDH TE Link for explicit route computation purposes. For 272 example, depending on how it is structured, an OC-48/STM-16 link may 273 be able to multiplex a variety of signal types. 275 4.1.1 Structure of Sonet/SDH Multiplexing Capabilities 277 GMPLS-based control of Sonet/SDH networks enables the control of 278 multiplex structures at a finer level of granularity than both STS- 279 (3*N)/STM-N with N = 1, 4, 16, 64, 256 and STM-0/STS-1. These 280 multiplexing structures are defined in [T1.105] and [G.707]. 282 4.1.2 Sonet/SDH TE Link Multiplexing Capability sub-TLV 284 The Multiplexing Capability optional sub-TLV describes the 285 multiplexing capabilities of the STS-(3*N)/STM-N (with N = 1, 4, 16, 286 64, 256) components of Sonet/SDH TE Links. It indicates precisely 287 the types of elementary signal that can be multiplexed by this link. 289 This optional sub-TLV of the Link TLV (see [OSPF-TE]), with Type 290 TBD, has a length of four octets. The Low Order Multiplexing 291 Capability Flag (LO MC Flag) field is defined as a vector of flags 292 and coded over one octet. The High Order Multiplexing Capability 293 Flag (HO MC Flag) field is defined as a vector of flags and coded 294 over one octet: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length = 4 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | HO MC Flag | LO MC Flag | Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Fig 1. Sonet/SDH TE Link Multiplex Capability sub-TLV 306 These fields defined separately for both High Order (HO) and Low 307 Order (LO) Sonet/SDH signals are vectors of bit flags. Each MC Flag 308 bit indicates the capability of the TE link components to multiplex 309 a given signal into the higher order signal in the Sonet/SDH 310 multiplex. A bit value of 1 indicates that the multiplexing 311 capability is supported while a bit value of 0 indicates that the 312 multiplexing capability is not supported. Bit 1 is the lowest order 313 bit of the flag field. 315 The Sonet/SDH High Order MC Flag field is defined as: 317 - Bit 1 : /VC-3 in TUG-3 318 - Bit 2 : /TUG-3 in AUG-1 (via VC-4) 319 - Bit 3 : STS-1 in STSG-3 /AU-3 in AUG-1 320 - Bit 4 : STSG-3 in STSG-12 /AUG-1 in AUG-4 321 - Bit 5 : STSG-12 in STSG-48 /AUG-4 in AUG-16 322 - Bit 6 : STSG-48 in STSG-192/AUG-16 in AUG-64 323 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 325 - Bit 7 : STSG-192 in STSG-768/AUG-64 in AUG-256 326 - Bit 8 : Reserved 328 In SDH, the High Order MC Flag can for instance take the following 329 values: 330 - 0b01111111 (0x7f): indicates a full SDH HO multiplexing capability 331 - 0b00001111 (0x0f): indicates a full AUG-4 (within an STM-4) 332 multiplexing capability 333 - 0b01111000 (0x78): indicates that the lowest multiplexing 334 capability is AUG-1 (with C4->VC4->AU4->AUG1) 336 Similarly, the Sonet/SDH Low Order MC Flag is defined as: 338 - Bit 1 : VT-1.5 SPE in VT Group /VC-11 in TUG-2 339 - Bit 2 : VT-2 SPE in VT Group /VC-12 in TUG-2 340 - Bit 3 : VT-3 SPE in VT Group / 341 - Bit 4 : VT-6 SPE in VT Group /VC-2 in TUG-2 342 - Bit 5 : VT-Group in STS-1 SPE/TUG-2 in AU-3 343 - Bit 6 : /TUG-2 in TUG-3 344 - Bit 7 : reserved 345 - Bit 8 : reserved 347 For SDH, the Low Order MC-Flag can for instance take the following 348 values: 349 - 0b00100010 (0x22): indicates that VC-12 can only be multiplexed in 350 VC-3 (through TUG-2) 351 - 0b00101000 (0x28): indicates that VC-2 can only be multiplexed in 352 VC-3 (through TUG-2) 354 Note: A binary value of 0b0...0 when advertised indicates no 355 Sonet/SDH multiplexing capability at all. Therefore referring to 356 single VC-4-Nc in AUG-N/STM-N or STS-(3*N)c in STSG-(3*N)/STS-(3*N) 357 capable interfaces. 359 4.2 Sonet/SDH TE Link Concatenation Capability sub-TLV 361 Contiguous and Virtual concatenation of Low Order (LO) and High 362 Order (HO) SONET and SDH signals are respectively defined in 363 [T1.105] and [G.707]. 365 4.2.1 SDH TE Link Concatenation Capability sub-TLV 367 For SDH, the TE Link Concatenation Capability sub-TLV describes the 368 SDH concatenation capabilities of a TE link. This TLV is defined as 369 an optional sub-TLV of the Link TLV (see [OSPF-TE]) with Type TBD. 370 The corresponding encoding and values are defined for Low Order and 371 High Order VCs. If no concatenation is supported on a TE Link, this 372 sub-TLV SHOULD not be advertised. 374 1. Low Order VC (LOVC) Concatenation 376 LOVC Concatenation includes: 377 - Contiguous concatenation of X VC-2s (VC-2-Xc, X = 1,...,7) 378 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 380 - Virtual concatenation of X VC-2/12/11s (VC-m-Xv, m = 11,12,2) 381 as defined in the following table: 383 Signal Carried in X interval 384 -------------------------------------------------- 385 VC-11-Xv VC-3 1 to 28 386 VC-12-Xv VC-3 1 to 21 387 VC-2-Xv VC-3 1 to 7 388 VC-11-Xv VC-4 1 to 64 389 VC-12-Xv VC-4 1 to 63 390 VC-2-Xv VC-4 1 to 21 392 The TE Link Concatenation Capability optional sub-TLV has the 393 following format: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Signal Type | CT | Res. | LT | List Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | NCC | . . . | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | NCC | . . . | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 // . . . // 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Signal Type | CT | Res. | LT | List Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | NCC | . . . | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | NCC | . . . | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Fig 2. TE Link Concatenation Capability sub-TLV 419 Signal Type (8 bits): 421 The Signal Type field values are defined in [GMPLS-SONET-SDH]. 423 CT � Concatenation Type (4 bits): 425 The CT field is defined as a 4-bit vector of flags (with bit 1 426 defined as the low order bit). A flag set to 1 indicates the 427 support of the corresponding concatenation type: 429 Flag 1 (Bit 1): Contiguous Concatenation 430 Flag 2 (Bit 2): Virtual Concatenation 431 Flag 3 (Bit 3): Reserved 432 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 434 Flag 4 (Bit 4): Reserved 436 Reserved flags MUST be set to zero when sent and ignored when 437 received. 439 Reserved (4 bits): 441 The Reserved field bits must be set to zero when sent and 442 should be ignored when received. 444 LT � List Type (4 bits): 446 The LT field indicates the type of the list; the following 447 values are defined (the values to which multiple lists refer 448 must be mutually disjoint): 450 0x0000 Reserved 451 0x0001 Inclusive list 452 0x0010 Exclusive list 453 0x0011 Inclusive range (one or more Minimum/Maximum pairs) 454 0x0100 Exclusive range (one or more Minimum/Maximum pairs) 456 Values ranging from 0x0101 to 0x1111 are reserved. At most one 457 LT value is allowed per sub-TLV (this limits its length). 458 Therefore this sub-TLV includes at most four sub-lists. 460 List Length (12 bits): 462 The List Length field indicates the number N of NCC fields (of 463 16 bits) comprised in a given list including the zero padding 464 field. Zero is an invalid value (or equivalently, N MUST be 465 greater than 0 and the minimum sub-TLV length is 8 octets). 467 NCC - Number of Concatenated Components (16 bits): 469 The NCC field indicates the supported number of low order VC�s 470 with respect to the Signal Type and the CT values. A NCC value 471 equal to zero refers to a zero padding field. For SDH LOVCs, 472 the number of VC-m�s values MUST refer to one or more of the 473 following values (as defined in the Signal Type field): VC-11, 474 VC-12 and/or VC-2. 476 When the LT field value equals 2 or 3, at least one pair of 477 LOVC�s numbers (i.e. two NCC fields) must be included in the 478 list. The first value indicates the minimum number of LOVC�s 479 and the second one the maximum number of LOVC�s supported (or 480 not supported, respectively) with the selected concatenation 481 type (CT). 483 Note: for a given Signal Type when this sub-TLV includes 484 several lists (defined with the same Type or not), the NCC 485 values that each list contain MUST be mutually consistent. 487 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 489 2. High Order VC (HOVC) Concatenation: 491 HOVC Concatenation includes: 492 - Contiguous concatenation of X VC-4s (VC-4-Xc, X = 4,16,64,256) 493 - Virtual concatenation of X VC-3/4s (VC-3/4-Xv, X = 1,...,256) 495 The SDH HOVC TE Link Concatenation Capability TLV has exactly the 496 same format and encoding as the one defined here above: 498 Signal Type (8 bits): see above. 500 CT � Concatenation Type (4 bits): see above. 502 Reserved (4 bits): see above. 504 LT � List Type (4 bits): see above. 506 List Length (12 bits): see above. 508 NCC - Number of Concatenated Components (16 bits): 510 The NCC field indicates the supported number of high order VC�s 511 with respect to the Signal Type (i.e. VC-3 and/or VC-4) and the 512 CT values. A NCC value equal to zero refers to a zero padding 513 field. 515 When the LT field value equals 2 or 3, at least one pair of 516 HOVC�s numbers (i.e. two NCC fields) must be included in the 517 list. The first value indicates the minimum number of HOVC�s 518 and the second one the maximum number of HOVC�s supported (or 519 not supported, respectively) with the selected concatenation 520 type (CT). 522 Note: for a given Signal Type, when this sub-TLV includes 523 several lists (defined with the same Type or not), the NCC 524 values that each list contain MUST be mutually consistent. 526 4.2.2 Sonet TE Link Concatenation Capability sub-TLV 528 Using the STS-1 SPE and STS-3c SPE equivalence to a VC-3 and a VC-4, 529 respectively, the above definition of high order Concatenation 530 Capability sub-TLV applies. Notice that in SONET, contiguous 531 concatenation is applicable to STS-3c SPE signals, resulting in STS- 532 (3*X)c SPE signals with X = 4,16,64,256. For low order signal, only 533 virtual concatenation of X VTn SPEs (VTn-Xv SPE, n = 1.5,2,3,6) must 534 be considered since low order contiguous concatenation is not 535 defined in ANSI [T1.105]. 537 This optional sub-TLV is defined (see also Section 4.2.1) as a sub- 538 TLV of the Link TLV, with Type TBD. The corresponding encoding and 539 values are defined for Low Order and High Order VCs. 541 1. Low order VT SPEs concatenation: 543 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 545 - Virtual concatenation of X VTn�s SPE (VTn-Xv SPE, n = 1.5,2,3, 546 6) as defined in the following table: 548 Signal Carried in X interval 549 -------------------------------------------------- 550 VT1.5-Xv SPE STS-1 1 to 28 551 VT2-Xv SPE STS-1 1 to 21 552 VT3-Xv SPE STS-1 1 to 14 553 VT6-Xv SPE STS-1 1 to 7 554 VT1.5-Xv SPE STS-3c 1 to 64 555 VT2-Xv SPE STS-3c 1 to 63 556 VT3-Xv SPE STS-3c 1 to 42 557 VT6-Xv SPE STS-3c 1 to 21 559 The format and encoding for the Low Order SONET TE Link 560 Concatenation Capability TLV is identical to the one defined for 561 SDH LOVC TE Links (see Section 4.2.1). 563 2. High order STS SPEs concatenation: 565 - Contiguous concatenation of X STS-3c SPEs (STS-(3*X)c with X = 566 4,16,64,256) 567 - Virtual concatenation of X STS-1/STS-3c SPEs (STS-1-Xv/STS-3c- 568 Xv with X = 1,...,256) 570 The format and encoding for the High Order SONET TE Link 571 Concatenation Capability TLV is identical to the one defined for 572 SDH HOVC TE Links (see Section 4.2.1). 574 4.3 Sonet/SDH TE Link Transparency Capability sub-TLV 576 This optional sub-TLV is defined as a vector of flags that indicates 577 the type of transparency supported by each of the component of a 578 given TE Link. Therefore it SHOULD be used only when these 579 components supports transparent signal types (see [GMPLS-SONET- 580 SDH]). 582 Several flags can be combined to provide different types of 583 transparency while any combination is not necessarily valid. By 584 default, the supported transparency on a TE Link is defined as the 585 Path Overhead (POH) transparency; therefore this sub-TLV should not 586 be sent for a TE Link only supporting POH transparency. 588 Note that when this sub-TLV is advertised, the Signal Type(s) 589 field(s) in the sub-TLV defined in Section 5 MUST take at least one 590 of the following values (see [GMPLS-SONET-SDH]): STS-1/STM-0, STS- 591 3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64 and STS- 592 768/STM-256. Equivalently, at least one transparency type MUST be 593 specified when advertising such Signal Type(s) in this sub-TLV. 595 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 597 This TLV is defined a sub-TLV of the Link TLV (see [OSPF-TE]), with 598 Type TBD and a length of four octets. It includes the Transparency 599 field defined as a 32-bit vector of flags. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length = 4 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Transparency (T) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Fig 4. Sonet/SDH TE Link Transparency Capability sub-TLV 611 The different transparency flags are the following: 613 Flag 1 (bit 1): Section/Regenerator Section layer 614 Flag 2 (bit 2): Line/Multiplex Section layer 616 Where bit 1 is the low order bit. Others flags are reserved, they 617 should be set to zero when sent, and must be ignored when received. 618 A flag is set to one to indicate that the corresponding transparency 619 is supported on the corresponding TE link. Additional flagging rules 620 MUST follow the rules defined in [GMPLS-SONET-SDH]. 622 5. TE Link Component Allocation 624 TE Link component allocation refers to the actual resource 625 utilization status of a TE link (representing either a single 626 component link or a bundled link). In the Sonet/SDH context, this 627 information can be represented by the number of unallocated (free) 628 timeslots per signal type and per TE link. 630 5.1 Sonet/SDH TE Link Component Allocation sub-TLV 632 The Sonet/SDH TE Link Component Allocation sub-TLV specifies the 633 number of identical unallocated timeslots per TE Link. As such, the 634 initial value(s) of this TLV indicates the total capacity in terms 635 of number of timeslot (per Signal Type) per TE link. 637 This TLV is defined as a sub-TLV of the Link TLV (see [OSPF-TE]), 638 with Type TBD and a length of n*4 octets. Each of the n fields gives 639 the number of unallocated timeslot per Signal Type (per TE Link) and 640 comprises a Signal Type field (8 bits) and a Number of Unallocated 641 Timeslot field (24 bits). The Signal Type field values are defined 642 in [GMPLS-SONET-SDH]. 644 Typically, this sub-TLV will be advertised by including Signal 645 Type(s) of the same order since one expects (as it is mostly the 646 case in legacy networks) separated routing instances between Low 647 Order and High Order VC transport layers. 649 0 1 2 3 650 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length = n*4 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Signal Type | Number of Unallocated Timeslots | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Signal Type | Number of Unallocated Timeslots | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | | 661 // . . . // 662 | | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Fig 5. Sonet/SDH TE Link Component Allocation sub-TLV 667 For instance, if a TE Link is constituted by 40 STM-64, each of them 668 decomposed in VC-4, initially the value of the Number of Unallocated 669 Timeslots field of this TLV is 40 x 64. Thus, 2560 VC-4 signals are 670 supported, and, if required, 2560 instances of exactly the same 671 signal can be allocated. 673 Note: for transparent Signal Types such as STS-(3*N)/STM-N (see 674 [GMPLS-SONET-SDH]), this number simply refers to the number of 675 interfaces supported at each end of the TE Link. 677 5.2 Sonet/SDH TE Link Contiguous Component Allocation 679 Contiguous concatenation of Low Order (LO) and High Order (HO) SONET 680 and SDH signals are respectively defined in [T1.105] and [G.707]. 681 Here, instead of advertising the concatenation capabilities (as 682 defined in Section 4.2), and provide a countdown on a per-timeslot 683 basis as defined in Section 5.1, an alternative way for the 684 representation of the component allocation in case of contiguous 685 concatenation capable TE links consists in defining additional 686 signal type values. In particular: 688 Value Type (Elementary Signal) 689 ----- ------------------------ 690 TBA STS-12c SPE / VC-4-4c 691 TBA STS-48c SPE / VC-4-16c 692 TBA STS-192c SPE / VC-4-64c 693 TBA STS-768c SPE / VC-4-256c 695 These Signal Type field values extends the set of values defined in 696 [GMPLS-SONET-SDH] and allows for an efficient accounting of the 697 timeslot allocation on interfaces supporting (simultaneously) 698 multiple contiguous concatenation types. Also, in this case, the 699 Concatenation Capability sub-TLV (See Section 4.2) SHOULD not be 700 used. 702 Example: A given Sonet/SDH STM-256 interface supporting all the 703 above contiguous concatenation is initially advertised with the 704 following capacity (timeslots being numbered from 0 to 255): 706 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 708 Signal Type Number of Unallocated Timeslot 709 Init VC-4#0 VC-4#4 VC-4-4c#64 VC4-16c#128 710 ----------- ------------------------------------------------------ 711 VC-4 256 255 254 250 234 712 VC-4-4c 64 63 62 61 57 713 VC-4-16c 16 15 15 14 13 714 VC-4-64c 4 3 3 2 1 715 VC-4-256c 1 0 0 0 0 717 Here, (0,0,0,0,0) indicates the first AUG-256 (first letter), first 718 AUG-64 (second letter), first AUG-16 (third letter), first AUG-4 719 (forth letter), first AUG-1 (fifth letter). 721 For instance, after a first VC-4 timeslot gets allocated at position 722 0 (0,0,0,0,0), (disables the availability of the VC-4-256c, first 723 VC-4-64c, the first VC-4-16c and first VC-4-4c) the values indicated 724 in column 2 are advertised. A second VC-4 timeslot gets allocated at 725 position 4 (0,0,0,1,0), (disabling the second VC-4-4c) implying the 726 information indicated in column 3 is advertised. Then, on the same 727 link, a VC-4-4c timeslot gets allocated at position 64 (0,1,0,0,0), 728 (disables the second VC-4-64c, the first VC-4-16c, and its 729 underlying VC-4-4c and VC-4s (4 times)) the number of unallocated 730 timeslots indicated in column 4 is advertised. Last, a VC-4-16c 731 timeslot gets allocated at position 128 (disables the third VC-4-64c 732 and its underlying VC-4-4cs (4 times) and VC-4s (16 times)), the 733 values of column 5 are advertised. 735 It should be noted that the description above is given for 736 understanding reasons. Usually the label allocation process should 737 allocate labels in a more sophisticated way by limiting 738 fragmentation of the multiplex structure. As an example the VC-4#4 739 should be allocated at position 1, the VC-4-4c#64 should be 740 allocated at position 4 and the VC4-16c should be allocated at 741 position 16. The table below shows the difference that there is 742 still a possibility to allocate 3 VC-4-64c at this interface. 744 Signal Type Number of Unallocated Timeslot 745 Init VC-4#0 VC-4#1 VC-4-4c#4 VC-4-16c#16 746 ----------- ------------------------------------------------------ 747 VC-4 256 255 254 250 234 748 VC-4-4c 64 63 63 62 58 749 VC-4-16c 16 15 15 15 14 750 VC-4-64c 4 3 3 3 3 751 VC-4-256c 1 0 0 0 0 753 Note also that the following accounting is forbidden taking for 754 instance an STM-16 interface where, 4 VC-4s are allocated at 755 position 0, 4, 8 and 12, respectively as each VC-4 is located in 756 different a AUG-4 group. 758 Signal Type Number of Unallocated Timeslot 759 ----------- ------------------------------ 760 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 762 VC-4 12 763 VC-4-4c 3 764 VC-4-16c 0 766 The corresponding values MUST be assigned as follows: 768 Signal Type Number of Unallocated Timeslot 769 ----------- ------------------------------ 770 VC-4 12 771 VC-4-4c 0 772 VC-4-16c 0 774 5.3 Minimum/Maximum LSP Bandwidth 776 The third representation makes usage of the Minimum/Maximum LSP 777 Bandwidth as defined in [GMPLS-RTG]. It has to be noticed that in 778 this case (taking into account the above example), that the Minimum 779 LSP Bandwidth would correspond to a VC-4 and the Maximum LSP 780 Bandwidth to a VC-4-256c (and thus the Unreserved Bandwidth on that 781 link). 783 Also the Maximum LSP Bandwidth can vary over time as timeslots gets 784 allocated. In the above example, it would range from a VC-4-256c 785 initially to a VC-4-64c afterwards. On the contrary the Minimum LSP 786 Bandwidth does not change unless all the 256 VC-4 timeslots have 787 been allocated on that link. 789 5.4 Comparison and Tradeoffs 791 The method proposed in Section 5.3 is the most straightforward 792 without requiring any bandwidth accounting change from an LSR 793 perspective. The lost of information only affects the number of 794 signals that can be used but not the range they cover. On the other 795 hand, when additional technology specific information are advertised 796 (see Section 4, 5.1 and 5.2) a finer grained resource countdown and 797 accounting can be performed allowing for network wide resource 798 allocation in Sonet/SDH environments. 800 It has to be emphasized that the behavior of the Concatenation 801 Capability sub-TLV (as defined in Section 4.2) is equivalent to the 802 one specified when advertising Minimum/Maximum LSP Bandwidth. Note 803 that the update frequency of the Opaque TE LSA (Type 1, see [OSPF- 804 TE]) does not affect technology specific methods because the former 805 implies variation of the Unreserved Bandwidth sub-TLV when timeslots 806 are allocated. Hence from this perspective, both classes of 807 solutions are equivalent. 809 6. Scalability Considerations 811 A Sonet/SDH-capable node SHOULD try to minimize the amount of 812 traffic engineering routing information it floods. Each time a 813 signal (e.g. a timeslot) is allocated or released that information 814 shall be flooded (not necessarily immediately) to all nodes in the 815 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 817 routing domain. In particular, this applies to the Component 818 Allocation sub-TLVs. This can result in updating an existing LSA or 819 even flushing an existing LSA. Removing an LSA can be performed in 820 OSPF by prematurely aging the LSA. The LSA is re-flooded with an LSA 821 age equal to MaxAge. Each node receiving an existing LSA with MaxAge 822 removes it from its link state database. 824 Also, the usage of OSPF implies each LSA must be refreshed 825 periodically (when the LSA age field reaches the LSRefreshTime, see 826 [RFC-2328]) to avoid age timeout and removal from the link state 827 database. This periodical LSA flooding and processing applies 828 particularly to the Capability sub-TLVs defined in this document 829 since their variation period is expected to be much larger than the 830 LSRefreshTime. 832 An Opaque LSA has a length field of 16 bits indicating the length of 833 the LSA, including the header. Thus, the length of OSPF packets can 834 be up to 65535 octets (including the IP header). Moreover, an OSPF 835 packet can contain several LSAs. OSPF relies if necessary on the IP 836 fragmentation to transmit large packets. This is possible without 837 any loss of functionality. However this is not recommended and it is 838 suggested to split packets that are too large into several smaller 839 packets. 841 It has to be emphasized that none of the sub-TLVs defined in this 842 document exceed the maximum OSPF packet size. Limiting the size of 843 the Concatenation Capability sub-TLV is ensured by construction. 844 Therefore, there is no particular issue that may be generated by the 845 size of Sonet/SDH sub-TLVs to be flooded in TE LSAs. 847 7. Compatibility Considerations 849 There should be no interoperability issues with Sonet/SDH GMPLS- 850 capable nodes that do not implement the proposed extensions, as the 851 Opaque LSAs (and the sub-TLVs proposed in this document) will be 852 silently ignored. 854 The result of having such nodes that do not implement these 855 extensions is that the Sonet/SDH specific traffic engineering 856 topology will be missing leading to an increasing rejection of sub- 857 sequent LSP signaling. 859 However, TE constraint paths can still be calculated using the 860 [OSPF-TE] and [GMPLS-OSPF] technology independent TE Link sub-TLVs. 862 8. Security Considerations 864 Routing protocol related security considerations are identical to 865 the on referenced in [RFC-2328] and [OSPF-TE]. 867 9. References 869 9.1 Normative References 870 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 872 [G.707] ITU-T Recommendation G.707, "Network Node Interface for 873 the Synchronous Digital Hierarchy", October 2000. 875 [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized MPLS (GMPLS) 876 Architecture," Internet Draft, Work in Progress, draft- 877 ietf-ccamp-gmpls-architecture-03.txt, August 2002. 879 [GMPLS-ISIS] K.Kompella et al, "IS-IS Extensions in Support of 880 Generalized MPLS," Internet Draft, Work in Progress, 881 draft-ietf-isis-gmpls-extensions-16.txt, January 2003. 883 [GMPLS-RTG] K.Kompella et al., "Routing Extensions in Support of 884 Generalized MPLS," Internet Draft, Work in Progress, 885 draft-ietf-ccamp-gmpls-routing-05.txt, August 2002. 887 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors), 888 "GMPLS extensions for SONET and SDH control", Internet 889 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- 890 sdh-07.txt, October 2002. 892 [MPLS-BDL] K.Kompella et al., "Link Bundling in MPLS Traffic 893 Engineering," Internet Draft, Work in Progress, draft- 894 ietf-mpls-bundle-04.txt, August 2002. 896 [MPLS-HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with 897 Generalized MPLS TE", Internet Draft, Work in Progress, 898 draft-ietf-mpls-lsp-hierarchy-08.txt, August 2002. 900 [OSPF-DNA] P.Pillay-Esnault, "OSPF Refresh and Flooding Reduction 901 in Stable Topologies", Internet Draft, Work in 902 progress, draft-pillay-esnault-ospf-flooding-04.txt, 903 January 2003. 905 [OSPF-TE] D.Katz, D.Yeung and K.Kompella, "Traffic Engineering 906 Extensions to OSPF", draft-katz-yeung-ospf-traffic- 907 09.txt, Internet Draft, Work in Progress, October 2002. 909 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, March 1997. 912 [RFC-2328] J.Moy, RFC 2328, "OSPF Version 2", STD 54, IETF 913 Standard Track, April 1998. 915 [RFC-2370] R.Coltun, RFC 2370, Standard Track, "The OSPF Opaque 916 LSA Option", July 1998. 918 [RFC-3471] Berger, L. (Editor), et al., "Generalized MPLS � 919 Signaling Functional Description", RFC 3471, January 920 2003. 922 draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt Feb. 03 924 [T1.105] American National Standards Institute, "Synchronous 925 Optical Network - Payload Mappings", T1.105, January 926 2001. 928 10. Author's Addresses 930 Dimitri Papadimitriou (Alcatel) 931 Francis Wellesplein 1, 932 B-2018 Antwerpen, Belgium 933 Phone: +32 3 240-8491 934 Email: dimitri.papadimitriou@alcatel.be 936 Eric Mannie (Consult) 937 Email: eric_mannie@hotmail.com