idnits 2.17.1 draft-gasparini-ccamp-gmpls-g709-ospf-00.txt: -(338): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(542): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(560): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(566): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(570): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(596): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(703): 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == There are 49 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 15) being 60 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([GMPLS-OSPF], [MPLS-BDL], [GMPLS-G709], [GMPLS-RTG], [OSPF-TE], [GMPLS-SIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (November 2002) is 7832 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 18 -- Looks like a reference, but probably isn't: '2' on line 39 == Missing Reference: 'ISIS-TE' is mentioned on line 526, but not defined == Unused Reference: 'GMPLS-ARCH' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'GMPLS-LDP' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SONET-SDH' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'ITUT-G707' is defined on line 570, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-03 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-08 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-08 == 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G707' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' == 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-03 ** 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 (~~), 18 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Germano Gasparini 3 Category: Internet Draft Gert Grammel 4 Expiration Date: May 2003 Dimitri Papadimitriou 5 Alcatel 7 November 2002 9 Traffic Engineering Extensions to OSPF 10 for Generalized MPLS (GMPLS) Control of G.709 Networks 12 draft-gasparini-ccamp-gmpls-g709-ospf-00.txt (*) 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Conventions used in this document: 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 38 this document are to be interpreted as described in RFC-2119 [2]. 40 (*) Previously draft-gasparini-ccamp-gmpls-g709-ospf�isis-03.txt 42 Abstract 44 This document introduces the traffic engineering extensions required 45 in existing IGP protocols to support sub-sequent signalling for 46 Label Switched Path (LSP) when using Generalized MPLS (GMPLS) 47 signalling as defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 48 Optical Transport Networks. In particular, using [GMPLS-RTG] as 49 guideline, it specifies the GMPLS routing extensions to OSPF and IS- 50 IS protocols for G.709 Optical Transport Networks (OTN). 52 D.Papadimitriou et al. - Expires May 2003 1 53 Based on the Traffic Engineering (TE) extensions defined in [OSPF- 54 TE], the proposed approach is aligned with link bundling as defined 55 in [MPLS-BDL] and extends the TE link sub-TLVs proposed in [GMPLS- 56 OSPF] by proposing several new sub-TLVs for G.709 networks. The 57 proposed extensions do not preclude any further integration with the 58 one it intends to complement. 60 1. Introduction 62 The approach proposed in this document is based on Traffic 63 Engineering (TE) extensions as defined in [OSPF-TE] which have been 64 extended for GMPLS purposes in [GMPLS-OSPF]. The current proposal 65 also uses the notion Link Bundling and TE link as defined in [MPLS- 66 BDL]. In this context, a set of links between two adjacent GMPLS 67 nodes (or simply nodes) is defined as a TE link. GMPLS currently 68 integrates the TE link notion by specifying that several links 69 having the same Traffic Engineering (TE) capabilities (i.e. same TE 70 metric, same set of Resource Class and same Switching capability) 71 can be advertised as a single TE link. Such TE links are referred to 72 as link bundles whose individual data bearing link (or simply links) 73 are referred to as component links (or ports). Moreover, there is no 74 longer a one-to-one association between a regular routing adjacency 75 and a TE link. 77 In order to enable distributed G.709 transport network control, the 78 link state routing protocol has to enable the exchange of two 79 different sets (or types) of information. First, a set that 80 describes the link capabilities belonging to a GMPLS G.709 LSR (or 81 simply a G.709 node in the present context) and this, independently 82 of their usage. Second, a set that describes the resources (more 83 precisely the timeslots or the optical channels) that are in use at 84 each of its TE links. 86 The first set can be defined as being driven by less frequent 87 updates (since TE link capabilities changes are not expected to be 88 frequent) while the second one would follow update interval values 89 as than the one used for any other non-technology dependent TE link 90 attribute (see [GMPLS-OSPF]). Therefore, one considers that when 91 this frequency is very low the corresponding TE link capability is 92 (quasi-)static; by opposition, others are referred to as dynamic. 93 Details concerning update frequency usage and related concepts are 94 out of the scope of this memo. 96 Moreover, the G.709 Optical Transport Hierarchy (OTH) is composed by 97 a digital and an optical part (see [ITUT-G709]). The former one 98 includes the Digital Path Layer (a.k.a. ODUk) while the latter one 99 includes the Optical Channel Layer (a.k.a. OCh). Consequently we can 100 define for of each of them a dedicated set of specific TLV. 102 In brief, this memo defines two additional sub-sets of information. 103 Their flooding enables the Traffic Engineering of the G.709 LSPs 104 (i.e. the ODUk and OCh LSPs). The first set describes the TE link 106 D.Papadimitriou et al. � Expires April 2003 2 107 capabilities (i.e. the OTM-n.m/OTM-nr.m/OTM-0.m interface 108 capabilities) and this, independently of their usage. The second set 109 describes the resources utilization (referred to as ODUk or OCh 110 components) used at each TE link and expressed in terms of number of 111 unallocated components per TE link. 113 2. OSPF Routing Extensions 115 In OSPF, GMPLS TE links can be advertised using Opaque LSAs (Link 116 State Advertisements) of Type 10 (see [RFC-2370]). This Traffic 117 Engineering (TE) LSA with area flooding scope is defined in [OSPF- 118 TE] and has one top-level Type/Length/Value (TLV) triplet and one or 119 more nested sub-TLVs for extensibility. Also, nodes shall originate 120 TE LSAs whenever their content change, and whenever required by OSPF 121 (for example, originate an LSA refresh when the LSA age field 122 reaches the LSRefreshTime). However, this does not mean that every 123 LSA contents change must be flooded immediately. As specified in 124 [RFC-2328], the origination of TE LSAs SHOULD be rate-limited to at 125 most one every MinLSInterval. Upon receipt of a changed TE LSA or 126 Network LSA (since these are used in TE calculations), the node 127 should update its TE link state database without necessarily 128 performing any (Constraint-)SPF or other path computation. 130 Per [OSPF-TE], two top-level TLVs are defined (1) the Router Address 131 TLV (referred to as the Node TLV) and (2) the TE link TLV. This memo 132 extends the current sub-TLV set of the TE link TLV by defining: 134 1. G.709 TE link capabilities: 136 - ODUk Multiplexing Capability sub-TLV 137 - ODUk virtual Concatenation Capability sub-TLV 139 2. G.709 TE link component allocation: 141 - ODUk Component Allocation sub-TLV 142 - OCh Component Allocation sub-TLV 144 Also, the proposed sub-TLVs can complement the Interface Switching 145 Capability Descriptor sub-TLV of the TE link TLV (see [GMPLS-OSPF]) 146 when the Switching Capability field value refers to (G.709 ODU) TDM. 148 Using the above classification, one can reduce the amount of more 149 static information flooded since changes are much less frequent when 150 considering TE link capabilities (see [OSPF-DNA] for instance). 151 This, while keeping the more dynamic information (changes are more 152 frequent when considering TE link component allocation for instance) 153 confined to the region to which this information is relevant. 155 In addition, it results from the TE link definition (see [MPLS-BDL]) 156 that each of its component link should support the same multiplexing 157 and (virtual) concatenation capabilities. The corresponding sub-TLVs 158 are specified once, and apply to each component link. No per 159 component information or identification is required for these TLVs. 161 D.Papadimitriou et al. � Expires April 2003 3 162 3. TE Link Capabilities 164 Additional TE link capabilities are (only) defined at the digital 165 path layer (i.e. the ODUk layers) and include the ODUk Multiplexing 166 Capability sub-TLV and ODUk virtual Concatenation Capability sub- 167 TLV. 169 3.1 TE Link ODUk Multiplexing Capability sub-TLV 171 The TE link ODUk Multiplexing Capability sub-TLV describes the ODUk 172 multiplexing structure available on a given link. This TLV indicates 173 the signals that can be potentially allocated in an ODUk multiplex. 175 As described in [ITUT-G709], in addition to the support of ODUk 176 mapping into OTUk (k = 1, 2, 3), the current version of the G.709 177 recommendation supports ODUk multiplexing. It refers to the 178 multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in 179 particular: 180 - ODU1 into ODU2 multiplexing 181 - ODU1 into ODU3 multiplexing 182 - ODU2 into ODU3 multiplexing 183 - ODU1 and ODU2 into ODU3 multiplexing 185 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 186 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 187 ODTUG constituted by ODU tributary slots) which is mapped into an 188 OPUk. The resulting OPUk is then mapped into an ODUk and the ODUk is 189 finally mapped into an OTUk. Subsequently, the OTUk is mapped into 190 an OCh/OChr, which is then modulated onto an OCC/OCCr. 192 The ODUk Multiplexing Capability sub-TLV is a sub-TLV of the Link 193 TLV whose type is TBD. The length of this TLV is four octets. It 194 includes a 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length = 4 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | MC-Flag | Reserved | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 MC-Flag (8 bits): 206 The Multiplexing Capability Flag (MC-Flag) field is coded in 207 one octet and defined as a vector of bit flags. 209 The following values are currently defined for the MC-Flag: 210 - Flag 1 (Bit 1): ODU1 multiplexing into ODU2 211 - Flag 2 (Bit 2): ODU1 multiplexing into ODU3 212 - Flag 3 (Bit 3): reserved 213 - Flag 4 (Bit 4): ODU2 multiplexing into ODU3 215 D.Papadimitriou et al. � Expires April 2003 4 216 - Flag 5 (Bit 5) to 8 (Bit 8): reserved 218 A bit value of 1 indicates that the multiplexing capability is 219 supported while a bit value of 0 indicates that the 220 multiplexing capability is not supported. For instance, the 221 support of ODU1 and ODU2 into ODU3 multiplexing is defined by 222 setting the Flag 1 and the Flag 4 to one. 224 Reserved Flags MUST be set to zero. When Flags 1 to 8 are set 225 to zero (in addition to the reserved field), ODUk multiplexing 226 is not supported on the TE link: the corresponding ODUk 227 signal(s) is not further structured. 229 Reserved (24 bits) 231 This field SHOULD be set to zero when sent and MUST be ignored 232 when received. 234 3.2 TE Link ODUk virtual Concatenation Capability sub-TLV 236 ODUk virtual concatenation refers to the concatenation of two or 237 more identical ODUk signals as defined in [ITUT-G709]. The resulting 238 signal is defined as an ODUk-Xv. The ODUk-Xv signal can then 239 transport a non-OTN client signal. For instance, an ODU2-4v may 240 transport an STM-256 client signal. 242 The characteristic information of a virtual concatenated ODUk (ODUk- 243 Xv) layer network is transported via a set of X ODUk LSP, each LSP 244 having its own transfer delay. The egress G.709 node terminating the 245 ODUk-Xv LSP has to compensate this differential delay in order to 246 provide a contiguous payload at the output. 248 The TE link ODUk (virtual) Concatenation Capability sub-TLV whose 249 Type is TBD has the following encoding: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length = M*(2*N + 4) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Signal Type | CT | Res. | LT | List Length (N) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | NCC | . . . | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | NCC | . . . | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 // . . . // 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Signal Type | CT | Res. | LT | List Length (N) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | NCC | . . . | 270 D.Papadimitriou et al. � Expires April 2003 5 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | NCC | . . . | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Signal Type (8 bits): 277 The Signal Type field values are defined in [GMPLS-G709]. 279 CT � Concatenation Type (4 bits): 281 The CT field is defined as a 4-bit vector of flags (with bit 1 282 defined as the low order bit). A flag set to 1 indicates the 283 support of the corresponding concatenation type: 285 Flag 1 (Bit 1): Reserved 286 Flag 2 (Bit 2): Virtual Concatenation 287 Flag 3 (Bit 3): Reserved 288 Flag 4 (Bit 4): Reserved 290 Reserved flags MUST be set to zero when sent and ignored when 291 received. 293 Reserved (4 bits): 295 The Reserved field bits must be set to zero when sent and 296 should be ignored when received. 298 LT � List Type (4 bits): 300 The LT field indicates the type of the list; the following 301 values are defined (the values to which multiple lists refer 302 must be mutually disjoint): 304 0x0000 Reserved 305 0x0001 Inclusive list 306 0x0010 Exclusive list 307 0x0011 Inclusive range (one or more Minimum/Maximum pairs) 308 0x0100 Exclusive range (one or more Minimum/Maximum pairs) 310 Values ranging from 0x0101 to 0x1111 are reserved. 312 List Length (12 bits): 314 The List Length field indicates the number N of NCC fields (of 315 16 bits) comprised in a given list including the zero padding 316 field. Zero is an invalid value (or equivalently, the number N 317 MUST be greater than 0 and the minimum sub-TLV length is of 8 318 octets). 320 NCC - Number of Concatenated Components (16 bits): 322 The NCC field indicates the supported number X of ODU 323 components with respect to the Signal Type and the CT values 325 D.Papadimitriou et al. � Expires April 2003 6 326 (here, in fact limited to virtual concatenation) that can 327 compose an ODUk-Xv signal on the corresponding TE link. 329 When the LT field value equals 1 or 2, at least one number X1 330 (i.e. one NCC field) must be included in the list. When list of 331 numbers X1,..,Xn is included, with Xi < Xj (i < j), each Xi 332 indicates the number of ODU�s supported (or not supported, 333 respectively) in a virtually concatenated signal. 335 When the LT field value equals 3 or 4, at least one pair of 336 numbers X1 and X2 (i.e. two NCC fields) must be included in the 337 list, with X1 < X2. The first one indicates the minimum number 338 X1 of ODU�s and the second one the maximum number X2 of ODU�s 339 supported (or not supported, respectively) in a virtually 340 concatenated signal. 342 When this sub-TLV includes several lists (defined with the same 343 Type), the NCC values that each list contain, MUST be mutually 344 consistent. A NCC value equal to zero refers to a zero padding 345 field. 347 Note that the maximum value of X is currently 16 (ODU1-16v) 348 therefore limiting the size of this sub-TLV to at most 16 x (4 + 4) 349 octets (i.e. worst case with one NCC field per list including zero 350 padding). 352 4. TE Link Component Allocation 354 To detail the actual resource utilization status of a TE link 355 (representing either a single component link or a bundled link), the 356 following TE link Component Allocation sub-TLVs are defined: 358 4.1 ODUk TE Link Component Allocation sub-TLV 360 The ODUk TE link Component Allocation sub-TLV represents the number 361 of unallocated (free) ODU timeslots also referred to as components, 362 per ODUk Signal Type value (k = 1, 2, 3) on a given TE link. 363 Therefore, when advertised for the first time, this sub-TLV 364 represents the total capacity in terms of number of ODU timeslot per 365 TE link i.e. the Maximum Number of ODUk components supported on this 366 TE link. 368 The ODUk Component Allocation sub-TLV whose Type is TBD has a length 369 of max(k)*4, where max(k) is the maximum value of the k index 370 supported on the corresponding TE link. Its encoding is defined as: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length = max(k)*4 | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Signal Type | Number of Unallocated ODU Timeslots | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 D.Papadimitriou et al. � Expires April 2003 7 381 | | 382 | . . . | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Signal Type | Number of Unallocated ODU Timeslots | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Signal Type (8 bits): 390 The valid Signal Type field values are defined in [GMPLS-G709]. 392 Number of Unallocated ODU Timeslots (24 bits): 394 This field indicates, per TE link, the number of unallocated 395 ODUk timeslots, k being implicitly specified by the Signal Type 396 field value. 398 Note: since currently the maximum value of the k index is 3 the 399 maximum length of this sub-TLV is 12 octets. 401 4.2 Optical Channel (OCh) Component Allocation sub-TLV 403 The TE link OCh Component Allocation sub-TLV represents the number 404 of optical channel actually allocated on a given TE link. This TE 405 link can, by definition, include one (single link) or more than one 406 (bundled link) OTM-nr.m or OTM-n.m interface. This allocation is 407 expressed in terms of the Number of Unallocated Optical Channel per 408 bit-rate m i.e. at 2.5 Gbps (m = 1), 10 Gbps (m = 2) and 40 Gbps (m 409 = 3). Therefore, when advertised for the first time, the Number of 410 Unallocated OCh represents for each supported bit rate the Maximum 411 Number of optical channels supported on a given TE link. 413 The OCh Component Allocation TLV sub-TLV is a sub-TLV of the Link 414 TLV with Type is TBD. The length of this sub-TLV is max(m)*4 octets, 415 where max(m) is the maximum value of the m index (m = 1, 2, 3) 416 supported on the corresponding TE link. Its encoding is defined as: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type | Length = max(m)*4 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Signal Type |R| Number of Unallocated OCh | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 | . . . | 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Signal Type |R| Number of Unallocated OCh | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 The valid Signal Type field values are defined in [GMPLS-G709]. 434 D.Papadimitriou et al. � Expires April 2003 8 435 The R bit indicates the functionality of the corresponding OTM- 436 n.m/OTM-nr.m interface(s). When R = 0, the interface signal refers 437 to an OTM-n.m (reduced functionality OChr) while R = 1, to an OTM- 438 nr.m (full functionality OCh). The value of this bit is irrelevant 439 in any other situation. 441 Therefore this encoding allows for TE links including both OTM-nr.m 442 and OTM-n.m interfaces. Each component link belonging to the same TE 443 link can have independently from each other a reduced OR a full 444 functionality stack support. Thus, reduced AND full optical channels 445 at 2.5, 10 or 40 Gbps can compose TE links. 447 Since the maximum value of the m index, as currently defined, is 3, 448 the maximum length of this sub-TLV is 2 x (3 x 4) octets. 450 Note: OCh Multiplexing Capability 452 As described in [ITUT-G709], with reduced stack functionality: up to 453 n (n >= 1) OCCr are multiplexed into an OCG-nr.m using wavelength 454 division multiplexing. The OCCr tributary slots of the OCG-nr.m can 455 be of different size (depending on the m value with m = 1, 2, 3). 456 The number of OCCr that can be multiplexed into an OCG-nr.m is 457 bounded by the following formula: 1 =< i + j + k =< n where i 458 (respectively, k and j) represents the number of OChr carrying an 459 OTU1 (respectively, OTU2 and OTU3). The OCG-nr.m is transported via 460 the OTM-nr.m. 462 With full stack functionality: up to n (n >= 1) OCC are multiplexed 463 into an OCG-n.m using wavelength division multiplexing. The OCC 464 tributary slots of the OCG-n.m can be of different size (depending 465 on the m value with m = 1, 2, 3). The number of OCC that can be 466 multiplexed into an OCG-n.m is bounded by the following formula: 1 467 =< i + j + k =< n where i (respectively, k and j) represents the 468 number of OCh carrying an OTU1 (respectively, OTU2 and OTU3). The 469 OCG-n.m is transported via the OTM-n.m. 471 5. Scalability Considerations 473 A G.709-capable node should try to minimize the amount of routing 474 information it floods. Each time a signal is allocated or released 475 that information shall be flooded (not necessarily immediately) to 476 all nodes in the routing domain. This applies particularly to the 477 Component Allocation sub-TLVs. Removing an LSA is done in OSPF by 478 prematurely aging the LSA. The LSA is re-flooded with an LSA age 479 equal to MaxAge. Each node receiving an existing LSA with MaxAge 480 removes it from its link state database. 482 Also, the usage of OSPF implies each LSA must be refreshed 483 periodically (when the LSA age field reaches the LSRefreshTime, see 484 [RFC-2328]) to avoid age timeout and removal from the link state 485 database. This periodical LSA flooding and processing applies 486 particularly to the Capability sub-TLVs defined in this document 488 D.Papadimitriou et al. � Expires April 2003 9 489 since their variation period is expected to be much larger than the 490 LSRefreshTime. 492 As specified in [RFC-2370], an Opaque LSA has a length field of 16 493 bits indicating the length of the LSA, including the header. Thus, 494 the length of OSPF packets can be up to 65535 octets (including the 495 IP header). Moreover, an OSPF packet can contain several LSAs. OSPF 496 relies if necessary on the IP fragmentation to transmit large 497 packets. However this is not recommended and it is suggested to 498 split packets that are too large into several smaller packets. This 499 is possible without any loss of functionality. 501 It has also to be emphasized that none of the sub-TLVs defined in 502 this document exceed 128 octets. Therefore, there is no particular 503 issue due to the size of G.709 sub-TLV to be flooded in TE LSAs. 505 In brief, there are no more (or less) scalability issues with the 506 proposed sub-TLVs (and the proposed encoding together with their 507 processing) than the ones already introduced in [OSPF-TE] and 508 [GMPLS-OSPF]. 510 7. Compatibility Considerations 512 There should be no interoperability issues with G.709 GMPLS-capable 513 nodes that do not implement the proposed extensions, as the Opaque 514 LSAs (and the sub-TLVs proposed in this document) will be silently 515 ignored. 517 The result of having such nodes that do not implement these 518 extensions is that the G.709 specific traffic engineering topology 519 will be missing. However, TE constraint paths can still be 520 calculated using the [OSPF-TE] and [GMPLS-OSPF] technology 521 independent TE link sub-TLVs. 523 8. Security Considerations 525 Routing protocol related security considerations are identical to 526 the on referenced in [OSPF-TE] and [ISIS-TE]. 528 9. References 530 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 531 Label Switching (GMPLS) Architecture�, Internet Draft, 532 Work in progress, draft-ietf-ccamp-gmpls-architecture- 533 03.txt, August 2002. 535 [GMPLS-G709] D.Papadimitriou (Editor) et al., �Generalized MPLS 536 Signalling Extensions for G.709 Optical Transport 537 Networks�, Internet Draft, Work in progress, draft- 538 ietf-ccamp-gmpls-g709-03.txt, November 2002. 540 D.Papadimitriou et al. � Expires April 2003 10 542 [GMPLS-LDP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 543 CR-LDP Extensions�, Internet Draft, Work in progress, 544 draft-ietf-mpls-generalized-cr-ldp-07.txt, August 2002. 546 [GMPLS-OSPF] K.Kompella et al., �OSPF Extensions in Support of 547 Generalized MPLS,� Internet Draft, Work in progress, 548 draft-ietf-ccamp-ospf-gmpls-extensions-08.txt, August 549 2002. 551 [GMPLS-RSVP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 552 RSVP-TE Extensions�, Internet Draft, Work in progress, 553 draft-ietf-mpls-generalized-rsvp-te-08.txt, August 554 2002. 556 [GMPLS-RTG] K.Kompella et al., �Routing Extensions in Support of 557 Generalized MPLS,� Internet Draft, Work in Progress, 558 draft-ietf-ccamp-gmpls-routing-05.txt, August 2002. 560 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS - Signaling 561 Functional Description�, Internet Draft, Work in 562 progress, draft-ietf-mpls-generalized-signaling-09.txt, 563 August 2002. 565 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., 566 �GMPLS extensions for SONET and SDH control�, Internet 567 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- 568 sdh-07.txt, October 2002. 570 [ITUT-G707] ITU-T G.707 Recommendation, �Network node interface for 571 the synchronous digital hierarchy (SDH)�, ITU-T, 572 October 2000. 574 [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment 575 1), �Interface for the Optical Transport Network 576 (OTN)�, ITU-T, October 2001. 578 [MPLS-BDL] K.Kompella et al., �Link Bundling in MPLS Traffic 579 Engineering,� Internet Draft, Work in progress, draft- 580 ietf-mpls-bundle-04.txt, August 2002. 582 [OSPF-DNA] P.Pillay-Esnault et al., �OSPF Refresh and flooding 583 reduction in stable topologies,� Internet Draft, Work 584 in progress, draft-pillay-esnault-ospf-flooding-03.txt, 585 December 2000. 587 [OSPF-TE] D.Katz, D.Yeung and K.Kompella, �Traffic Engineering 588 Extensions to OSPF�, draft-katz-yeung-ospf-traffic- 589 09.txt, Internet Draft, Work in progress, October 2002. 591 [RFC-2328] J.Moy, RFC 2328, �OSPF Version 2�, STD 54, IETF 592 Standard Track, April 1998. 594 D.Papadimitriou et al. � Expires April 2003 11 596 [RFC-2370] R.Coltun, RFC 2370, �The OSPF Opaque LSA Option�, IETF 597 Standard Track, July 1998. 599 10. Acknowledgments 601 The authors would like to thank Alberto Bellato, Michele Fontana, 602 and Jim Jones for their constructive comments and inputs leading to 603 the current version of this document. 605 11. Author's Addresses 607 Germano Gasparini (Alcatel) 608 Via Trento 30, 609 I-20059 Vimercate, Italy 610 Phone: +39 039 686-7670 611 Email: germano.gasparini@netit.alcatel.it 613 Gert Grammel (Alcatel) 614 Via Trento 30, 615 I-20059 Vimercate, Italy 616 Phone: +39 039 686-7060 617 Email: gert.grammel@netit.alcatel.it 619 Dimitri Papadimitriou (Alcatel) 620 Francis Wellesplein 1, 621 B-2018 Antwerpen, Belgium 622 Phone: +32 3 240-8491 623 Email: dimitri.papadimitriou@alcatel.be 625 D.Papadimitriou et al. � Expires April 2003 12 626 Appendix 1 � Abbreviations 628 1R Re-amplification 629 2R Re-amplification and Re-shaping 630 3R Re-amplification, Re-shaping and Re-timing 631 AI Adapted information 632 AIS Alarm Indication Signal 633 APS Automatic Protection Switching 634 BDI Backward Defect Indication 635 BEI Backward Error Indication 636 BI Backward Indication 637 BIP Bit Interleaved Parity 638 CBR Constant Bit Rate 639 CI Characteristic information 640 CM Connection Monitoring 641 EDC Error Detection Code 642 EXP Experimental 643 ExTI Expected Trace Identifier 644 FAS Frame Alignment Signal 645 FDI Forward Defect Indication 646 FEC Forward Error Correction 647 GCC General Communication Channel 648 IaDI Intra-Domain Interface 649 IAE Incoming Alignment Error 650 IrDI Inter-Domain Interface 651 MFAS MultiFrame Alignment Signal 652 MS Maintenance Signal 653 naOH non-associated Overhead 654 NNI Network-to-Network interface 655 OCC Optical Channel Carrier 656 OCG Optical Carrier Group 657 OCI Open Connection Indication 658 OCh Optical Channel (with full functionality) 659 OChr Optical Channel (with reduced functionality) 660 ODU Optical Channel Data Unit 661 OH Overhead 662 OMS Optical Multiplex Section 663 OMU Optical Multiplex Unit 664 OOS OTM Overhead Signal 665 OPS Optical Physical Section 666 OPU Optical Channel Payload Unit 667 OSC Optical Supervisory Channel 668 OTH Optical transport hierarchy 669 OTM Optical transport module 670 OTN Optical transport network 671 OTS Optical transmission section 672 OTU Optical Channel Transport Unit 673 PCC Protection Communication Channel 674 PLD Payload 675 PM Path Monitoring 676 PMI Payload Missing Indication 677 PRBS Pseudo Random Binary Sequence 678 PSI Payload Structure Identifier 680 D.Papadimitriou et al. � Expires April 2003 13 681 PT Payload Type 682 RES Reserved 683 RS Reed-Solomon 684 SM Section Monitoring 685 TC Tandem Connection 686 TCM Tandem Connection Monitoring 687 UNI User-to-Network Interface 689 Appendix 2 � G.709 Indexes 691 - Index k: The index "k" is used to represent a supported bit rate 692 and the different versions of OPUk, ODUk and OTUk. k=1 represents 693 an approximate bit rate of 2.5 Gbit/s, k=2 represents an 694 approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate 695 of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s 696 (under definition). The exact bit-rate values are in kbits/s: 697 OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 698 ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 699 OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 701 - Index m: The index "m" is used to represent the bit rate or set of 702 bit rates supported on the interface. This is a one or more digit 703 �k�, where each �k� represents a particular bit rate. The valid 704 values for m are (1, 2, 3, 12, 23, 123). 706 - Index n: The index "n" is used to represent the order of the OTM, 707 OTS, OMS, OPS, OCG and OMU. This index represents the maximum 708 number of wavelengths that can be supported at the lowest bit rate 709 supported on the wavelength. It is possible that a reduced number 710 of higher bit rate wavelengths are supported. The case n=0 711 represents a single channel without a specific wavelength assigned 712 to the channel. 714 - Index r: The index "r", if present, is used to indicate a reduced 715 functionality OTM, OCG, OCC and OCh (non-associated overhead is 716 not supported). Note that for n=0 the index r is not required as 717 it implies always reduced functionality. 719 D.Papadimitriou et al. � Expires April 2003 14 720 Full Copyright Statement 722 "Copyright (C) The Internet Society (date). All Rights Reserved. 723 This document and translations of it may be copied and furnished to 724 others, and derivative works that comment on or otherwise explain it 725 or assist in its implementation may be prepared, copied, published 726 and distributed, in whole or in part, without restriction of any 727 kind, provided that the above copyright notice and this paragraph 728 are included on all such copies and derivative works. However, this 729 document itself may not be modified in any way, such as by removing 730 the copyright notice or references to the Internet Society or other 731 Internet organizations, except as needed for the purpose of 732 developing Internet standards in which case the procedures for 733 copyrights defined in the Internet Standards process must be 734 followed, or as required to translate it into languages other than 735 English. 737 The limited permissions granted above are perpetual and will not be 738 revoked by the Internet Society or its successors or assigns. 740 This document and the information contained herein is provided on an 741 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 742 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 743 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 744 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 745 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 747 D.Papadimitriou et al. � Expires April 2003 15