idnits 2.17.1 draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt: -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(549): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(558): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(562): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(572): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(576): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(700): 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 42 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-ISIS], [GMPLS-OSPF], [MPLS-BDL], [ISIS-TE], [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: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (June 2002) is 7987 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: 'GMPLS-RTG' is mentioned on line 46, but not defined == Unused Reference: 'GMPLS-ARCH' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'GMPLS-LDP' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SONET-SDH' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'ITUT-G707' is defined on line 576, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-G709' == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-12 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-05 == 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') -- 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-03 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) Summary: 9 errors (**), 0 flaws (~~), 20 warnings (==), 7 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: December 2002 Dimitri Papadimitriou 5 - Alcatel 7 June 2002 9 Traffic Engineering Extensions to OSPF and ISIS 10 for GMPLS Control of G.709 Optical Transport Networks 12 draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.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 Abstract 42 This document introduces the traffic engineering extensions required 43 in existing IGP protocols to support sub-sequent signalling for 44 Label Switched Path (LSP) when using Generalized MPLS signalling as 45 defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical Transport 46 Networks (see [GMPLS-G709]). In particular, using [GMPLS-RTG] as 47 guideline, it specifies the GMPLS routing extensions to OSPF and IS- 48 IS protocols for G.709 Optical Transport Networks (OTN). 50 Based on the Traffic Engineering (TE) extensions defined in [OSPF- 51 TE] and [ISIS-TE], the proposed approach supports link bundling as 53 D.Papadimitriou et al. - Expires December 2002 1 54 defined in [MPLS-BDL] and defines several new sub-TLVs for Optical 55 Transport Network (OTN) control by extending those proposed in 56 [GMPLS-OSPF] and [GMPLS-ISIS]. The proposed encoding does not 57 preclude any further integration in these documents that the current 58 one 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] and [ISIS-TE] 64 which have been extended for GMPLS in [GMPLS-OSPF] and [GMPLS-ISIS]. 66 The current proposal also uses the notion Link Bundling and TE Link 67 as defined in [MPLS-BDL]. A set of links between two adjacent GMPLS 68 nodes (or simply nodes) is defined as a TE-link, identified by a TE 69 link ID. GMPLS currently integrates the TE-link notion by detailing 70 among others that several links having the same Traffic Engineering 71 (TE) capabilities (i.e. same TE metric, same set of Resource Class 72 and same Switching capability) can be advertised as a single TE- 73 link. Such TE-links are referred to as link bundles whose individual 74 data bearing link (or simply links) are referred to as component 75 links; There is no longer a one-to-one association between a regular 76 routing adjacency and a TE-link. 78 In order to enable distributed G.709 OTN control, the IGP routing 79 protocol has to enable the exchange of two different sets (or types) 80 of information. First, a set that describes the link capabilities of 81 a GMPLS G.709 OTN node (or simply a node in this context), 82 independently of their usage. Second, a set that describes the OTN 83 resources (more precisely the digital timeslots or the optical 84 channels) that are in use at each TE link. 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 would follow update interval values as 89 than the one used for any other non-technology dependent TE Link 90 attribute. We consider here that when this frequency is very low the 91 corresponding TE-link capability is static; by opposition, other are 92 referred to as dynamic. Details concerning update frequency usage 93 and related concepts are out of the scope of the current document. 95 Moreover, the G.709 Optical Transport Hierarchy (OTH) is composed by 96 a digital and an optical part (see [ITUT-G709]). The first one 97 includes the Digital Path Layer (i.e. the ODUk layers) while the 98 second one includes the Optical Channel Layer (i.e. the OCh layer). 99 Consequently we can define for of each of these hierarchies a 100 separated set of specific TLV. We refer to the first set as LD (Link 101 Digital) and to the second as LO (Link Optical). 103 Consequently, two specific sub-sets of information must be flooded 104 by an extended link state routing protocol to enable Traffic- 105 Engineering of the G.709 LSPs (ODUk and OCh LSPs) in OTN. First, a 106 set of information describing the TE Link capabilities (i.e. the 108 D.Papadimitriou et al. � Expires December 2002 2 109 OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities) independently of 110 their usage must be defined. Then a set of information describing 111 the resources utilization (also referred to as ODUk or OCh component 112 allocation) used at each TE Link and expressed in terms of number 113 unallocated components. 115 In this way, one can reduce the amount of more static information 116 (since changes are less frequent when considering TE Link 117 capabilities) flooded through the routing protocol. This, while 118 keeping the more dynamic information (changes are more frequent when 119 considering TE Link component allocation for instance) confined to 120 the layer to which this information is relevant. 122 Routing information is exchanged in OSPF by Link State 123 Advertisements (LSAs) grouped in OSPF PDUs, and in IS-IS by Link 124 State PDUs (LSPs). When using OSPF, GMPLS TE links can be advertised 125 using Opaque LSAs (Link State Advertisements) of Type 10 (see [RFC- 126 2370]). This Traffic Engineering (TE) LSA with area flooding scope 127 is defined in [OSPF-TE] and has one top-level Type/Length/Value 128 (TLV) triplet and one or more nested sub-TLVs for extensibility. 129 Per [OSPF-TE], the following top-level TLVs are defined (1) Router 130 Address TLV (referred to as the Node TLV) and (2) TE Link TLV. When 131 using IS-IS, GMPLS TE links are advertised using LS PDUs. TE 132 Attributes TLVs are defined as sub-TLV for the Extended IS 133 Reachability TLV (TLV 22) (see [ISIS-TE] and [GMPLS-ISIS]). 135 Therefore, in this memo, we propose to extend the current sub-TLV 136 set of both the TE Link TLV (in OSPF) and the Extended IS 137 Reachability TLV (in ISIS). For each of these sets, the following 138 sub-TLVs are defined: 140 1. G.709 TE Link capabilities: 142 - LD-MC TLV : TE Link ODUk Multiplexing Capability TLV 143 - LD-CC TLV : TE Link ODUk virtual Concatenation Capability TLV 145 2. G.709 TE Link component allocation: 147 - LD-CA TLV : TE Link ODUk Component Allocation TLV 148 - LO-CA TLV : TE Link OCh Component Allocation TLV 150 Note: the proposed sub-TLVs can also complement the Interface 151 Switching Capability Descriptor sub-TLV of the TE Link TLV and 152 Extended IS Reachability TLV (see [GMPLS-OSPF] and [GMPLS-ISIS], 153 respectively) when the Switching Capability field value refers to 154 (G.709 ODU) TDM. 156 In addition, it results from the TE Link definition (see [MPLS-BDL]) 157 that each of its component link should support the same multiplexing 158 and (virtual) concatenation capabilities. The corresponding TLVs 159 (LD-MC and LD-CC) are specified once, and apply to each component 160 link. No per component information or identification is required for 161 these TLVs. 163 D.Papadimitriou et al. � Expires December 2002 3 164 2. TE-Link Capabilities 166 TE-Link capabilities are (only) defined at the digital path layer 167 (i.e. the ODUk layers); the corresponding TE Link capability TLVs 168 includes: 170 - LD-MC TLV : TE Link ODUk Multiplexing Capability TLV 171 - LD-CC TLV : TE Link ODUk virtual Concatenation Capability TLV 173 2.1 TE Link ODUk Multiplexing Capability TLV (LD-MC TLV) 175 The TE Link ODUk Multiplexing Capability TLV (LD-MC TLV) describes 176 the ODUk multiplexing structure available on a given link. This TLV 177 indicates the signals that can be potentially allocated in an ODUk 178 multiplex. 180 As described in [ITUT-G709], in addition to the support of ODUk 181 mapping into OTUk (k = 1, 2, 3), the current version of the G.709 182 recommendation supports ODUk multiplexing. It refers to the 183 multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in 184 particular: 185 - ODU1 into ODU2 multiplexing 186 - ODU1 into ODU3 multiplexing 187 - ODU2 into ODU3 multiplexing 188 - ODU1 and ODU2 into ODU3 multiplexing 190 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 191 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 192 ODTUG constituted by ODU tributary slots) which is mapped into an 193 OPUk. The resulting OPUk is then mapped into an ODUk and the ODUk is 194 finally mapped into an OTUk. Subsequently, the OTUk is mapped into 195 an OCh/OChr, which is then modulated onto an OCC/OCCr. 197 In IS-IS, the LD-MC TLV is defined as a sub-TLV of the Extended IS 198 Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of 199 the Link TLV whose type is TBD. The length of this TLV is four 200 octets. It includes a Multiplexing Capability Flag (MC-Flag) coded 201 in one octet and defined as a vector of bit flags. 203 OSPF TE Link ODUk Multiplexing Capability TLV (LD-MC TLV) coding: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length = 4 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | MC-Flag | Reserved | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ISIS TE Link ODUk Multiplexing Capability TLV coding (Sub-TLV Type 214 TBD and Length = 4): 216 D.Papadimitriou et al. � Expires December 2002 4 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | MC-Flag | Reserved | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 The following values are currently defined for the MC-Flag: 224 - Flag 1 (Bit 1): ODU1 multiplexing into ODU2 225 - Flag 2 (Bit 2): ODU1 multiplexing into ODU3 226 - Flag 3 (Bit 3): reserved 227 - Flag 4 (Bit 4): ODU2 multiplexing into ODU3 228 - Flag 5 (Bit 5) to 8 (Bit 8): reserved 230 A bit value of 1 indicates that the multiplexing capability is 231 supported while a bit value of 0 indicates that the multiplexing 232 capability is not supported. For instance, the support of ODU1 and 233 ODU2 into ODU3 multiplexing is defined by setting the Flag 1 and the 234 Flag 4 to one. 236 Reserved Flags must be set to zero. When Flags 1 to 8 are set to 237 zero (in addition to the reserved field), ODUk multiplexing is not 238 supported on the TE link: the corresponding ODUk signal(s) is not 239 further structured. 241 2.2 TE Link ODUk virtual Concatenation Capability TLV (LD-CC TLV) 243 ODUk virtual concatenation refers to the concatenation of two or 244 more identical ODUk signals as defined in [ITUT-G709]. The resulting 245 signal is defined as an ODUk-Xv. The ODUk-Xv signal can then 246 transport a non-OTN client signal. For instance, an ODU2-4v may 247 transport an STM-256 client signal. 249 The characteristic information of a virtual concatenated ODUk (ODUk- 250 Xv) layer network is transported via a set of X ODUk LSP, each LSP 251 having its own transfer delay. The egress G.709 node terminating the 252 ODUk-Xv LSP has to compensate this differential delay in order to 253 provide a contiguous payload at the output. 255 In IS-IS, the TE Link ODUk Concatenation Capability TLV (LD-CC TLV) 256 is defined as a sub-TLV of the Extended IS Reachability TLV whose 257 Type is TBD. In OSPF, this TLV is a sub-TLV of the TE Link TLV, with 258 type TBD. 260 OSPF TE Link ODUk virtual Concatenation Capability TLV (LD-CC TLV) 261 coding: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length (n*4) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Signal Type | CT | Res. | LT | List Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 D.Papadimitriou et al. � Expires December 2002 5 272 | NCC | . . . | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | NCC | . . . | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 // . . . // 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Signal Type | CT | Res. | LT | List Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | NCC | . . . | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | NCC | . . . | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ISIS TE Link ODUk virtual Concatenation Capability TLV coding (Sub- 288 TLV Type TBD and Length = n*4): 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Signal Type | CT | Res. | LT | List Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | NCC | . . . | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | NCC | . . . | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | 300 // . . . // 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Signal Type | CT | Res. | LT | List Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | NCC | . . . | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | NCC | . . . | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Signal Type (8 bits): 312 The Signal Type field values are defined in [GMPLS-G709]. 314 CT � Concatenation Type (4 bits): 316 The CT field is defined as a 4-bit vector of flags (with bit 1 317 defined as the low order bit) indicating the supported 318 concatenation type(s): 320 Flag 1 (Bit 1): Reserved 321 Flag 2 (Bit 2): Virtual Concatenation 322 Flag 3 (Bit 3): Reserved 323 Flag 4 (Bit 4): Reserved 325 D.Papadimitriou et al. � Expires December 2002 6 326 Reserved (4 bits): 328 The Reserved field bits must be set to zero when sent and 329 should be ignored when received. 331 LT � List Type (4 bits): 333 The LT field indicates the type of the list; the following 334 values are defined (the values to which multiple lists refer 335 must be mutually disjoint): 337 0x0000 Reserved 338 0x0001 Inclusive list 339 0x0010 Exclusive list 340 0x0011 Inclusive range (one or more Minimum/Maximum pairs) 341 0x0100 Exclusive range (one or more Minimum/Maximum pairs) 343 Values ranging from 0x0101 to 0x1111 are reserved. 345 List Length (12 bits): 347 The List Length indicates the number of NCC elements included 348 within a given sub-list. Zero is an invalid value. 350 NCC - Number of Concatenated Components (16 bits): 352 The NCC field indicates the supported number X of ODU 353 components with respect to the Signal Type and the CT values 354 (here, in fact limited to virtual concatenation) that can 355 compose an ODUk-Xv signal on the corresponding TE Link. 357 When the LT field value equals 1 or 2, at least one number X1 358 (i.e. one NCC field) must be included in the list. When list of 359 numbers X1,..,Xn is included, with Xi < Xj (i < j), each Xi 360 indicates the number of ODU�s supported (or not supported, 361 respectively) in a virtually concatenated signal. 363 When the LT field value equals 3 or 4, at least one pair of 364 numbers X1 and X2 (i.e. two NCC fields) must be included in the 365 list, with X1 < X2. The first one indicates the minimum number 366 X1 of ODU�s and the second one the maximum number X2 of ODU�s 367 supported (or not supported, respectively) in a virtually 368 concatenated signal. 370 3. TE-Link Dynamic Component Allocation 372 To detail the actual status of a TE-link (representing either a 373 single component link or a bundled link), the following Component 374 Allocation TLVs are defined: 376 - LD-CA TLV : Link ODUk Component Allocation TLV 377 - LO-CA TLV : Link OCh Component Allocation TLV 379 D.Papadimitriou et al. � Expires December 2002 7 380 3.1 Digital Path Layer 382 The TE Link ODUk Component Allocation TLV (LD-CA TLV) represents the 383 number of unallocated (free) ODU timeslots also referred to as 384 components, per ODUk Signal Type value (k = 1, 2, 3) on a given TE 385 link. Therefore, when advertised for the first time, this TLV 386 represents the total capacity in terms of number of ODU timeslot per 387 TE link i.e. the Maximum Number of ODUk components supported on this 388 TE link. 390 The LD-CA TLV is defined in IS-IS as a sub-TLV of the Extended IS 391 Reachability TLV whose Type is TBD. In OSPF, this TLV is a sub-TLV 392 of the Link TLV whose Type is TBD. The length of this sub-TLV is 393 max(k)*4, where max(k) is the maximum value of the k index supported 394 on the corresponding TE link. 396 OSPF Link ODUk Component Allocation TLV (LD-CA TLV) coding: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length = max(k)*4 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Signal Type | Number of Unallocated ODU TimeSlots | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 | . . . | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Signal Type | Number of Unallocated ODU TimeSlots | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 ISIS TE Link ODUk Component Allocation TLV coding (Sub-TLV Type TBD 413 and Length = max(k)*4): 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Signal Type | Number of Unallocated ODU TimeSlots | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 | . . . | 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Signal Type | Number of Unallocated ODU TimeSlots | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 When two Number of Unallocated ODU Timeslots fields with the same 428 Signal Type value are advertised, the second one indicates the 429 number of contiguous block of unallocated ODU timeslots. Thus, when 430 advertised initially the corresponding value equal 1. 432 D.Papadimitriou et al. � Expires December 2002 8 433 Note: since currently the maximum value of the k index is 3 the 434 maximum length of the LD-CA TLV is 12 octets except when the blocks 435 of unallocated ODU timeslots are advertised. 437 3.2 Optical Channel (OCh) Layer 439 The TE Link OCh Component Allocation TLV (LO-CA TLV) represents the 440 number of optical channel actually allocated on a given TE link. 441 This TE Link can, by definition, include one (single link) or more 442 than one (bundled link) OTM-nr.m or OTM-n.m interface. This 443 allocation is expressed in terms of the Number of Unallocated 444 Optical Channel per bit-rate, represented here as OCh1 (2.5 Gbps), 445 OCh2 (10 Gbps) and OCh3 (40 Gbps), respectively. Therefore, when 446 advertised for the first time, the Number of Unallocated OCh1, OCh2 447 and OCh3 represents the Maximum Number of optical channels supported 448 on a given TE link at each bit rate, respectively. 450 The LO-CA TLV is defined in IS-IS as a sub-TLV of the Extended IS 451 Reachability TLV whose Type is TBD. In OSPF, this TLV is a sub-TLV 452 of the Link TLV whose Type is TBD. The length of this sub-TLV is 453 max(m)*4 octets, where max(m) is the maximum value of the m index (m 454 = 1, 2, 3) supported on the corresponding TE link. The Signal Type 455 field values are defined in [GMPLS-G709]. 457 OSPF TE Link OCh Component Allocation TLV (LO-CA TLV) coding: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type | Length = max(m)*4 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Signal Type |R| Number of Unallocated OCh | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 | . . . | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Signal Type |R| Number of Unallocated OCh | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 ISIS TE Link OCh Component Allocation TLV coding (Sub-TLV Type TBD 474 and Length = max(m)*4 octets): 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Signal Type |R| Number of Unallocated OCh | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 | . . . | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Signal Type |R| Number of Unallocated OCh | 487 D.Papadimitriou et al. � Expires December 2002 9 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 The R bit indicates the functionality of the corresponding OTM- 491 n.m/OTM-nr.m interface(s). When R = 0, the interface signal refers 492 to an OTM-n.m (reduced functionality OChr) while R = 1, to an OTM- 493 nr.m (full functionality OCh). The value of this bit is irrelevant 494 in any other situation. 496 Therefore this encoding allows for TE links including both OTM-nr.m 497 and OTM-n.m interfaces. Each component link belonging to the same TE 498 Link can have independently from each other a reduced OR a full 499 functionality stack support. Thus, reduced AND full optical channels 500 at 2.5, 10 or 40 Gbps can compose TE links. 502 Since currently the maximum value of the m index is 3, the maximum 503 length of the LO-CA TLV is 24 octets: 2 x (3 x 4) octets. 505 Note: OCh Multiplexing Capability 507 As described in [ITUT-G709], with reduced stack functionality: up to 508 n (n >= 1) OCCr are multiplexed into an OCG-nr.m using wavelength 509 division multiplexing. The OCCr tributary slots of the OCG-nr.m can 510 be of different size (depending on the m value with m = 1, 2, 3). 511 The number of OCCr that can be multiplexed into an OCG-nr.m is 512 bounded by the following formula: 1 =< i + j + k =< n where i 513 (respectively, k and j) represents the number of OChr carrying an 514 OTU1 (respectively, OTU2 and OTU3). The OCG-nr.m is transported via 515 the OTM-nr.m. 517 With full stack functionality: up to n (n >= 1) OCC are multiplexed 518 into an OCG-n.m using wavelength division multiplexing. The OCC 519 tributary slots of the OCG-n.m can be of different size (depending 520 on the m value with m = 1, 2, 3). The number of OCC that can be 521 multiplexed into an OCG-n.m is bounded by the following formula: 1 522 =< i + j + k =< n where i (respectively, k and j) represents the 523 number of OCh carrying an OTU1 (respectively, OTU2 and OTU3). The 524 OCG-n.m is transported via the OTM-n.m. 526 4. Security Considerations 528 Routing protocol related security considerations are identical to 529 the on referenced in [OSPF-TE] and [ISIS-TE]. 531 5. References 533 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 534 Label Switching (GMPLS) Architecture�, Internet Draft, 535 Work in progress, draft-ietf-ccamp-gmpls-architecture- 536 02.txt, February 2002. 538 [GMPLS-G709] D.Papadimitriou (Editor) et al., �Generalized MPLS 539 Signalling Extensions for G.709 Optical Transport 541 D.Papadimitriou et al. � Expires December 2002 10 542 Networks�, Internet Draft, Work in progress, draft- 543 ietf-ccamp-gmpls-g709-01.txt, June 2002. 545 [GMPLS-ISIS] K.Kompella et al., �IS-IS Extensions in Support of 546 Generalized MPLS,� Internet Draft, Work in progress, 547 draft-ietf-isis-gmpls-extensions-12.txt, May 2002. 549 [GMPLS-LDP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 550 CR-LDP Extensions�, Internet Draft, Work in progress, 551 draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002. 553 [GMPLS-OSPF] K.Kompella et al., �OSPF Extensions in Support of 554 Generalized MPLS,� Internet Draft, Work in progress, 555 draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, April 556 2002 558 [GMPLS-RSVP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 559 RSVP-TE Extensions�, Internet Draft, Work in progress, 560 draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002. 562 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS - Signaling 563 Functional Description�, Internet Draft, Work in 564 progress, draft-ietf-mpls-generalized-signaling-08.txt, 565 April 2002. 567 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., 568 "GMPLS extensions for SONET and SDH control", Internet 569 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- 570 sdh-05.txt, June 2002. 572 [ISIS-TE] T.Li et al.,�IS-IS Extensions for Traffic Engineering�, 573 Internet Draft, Work in Progress, draft-ietf-isis- 574 traffic-04.txt, August 2001. 576 [ITUT-G707] ITU-T G.707 Recommendation, �Network node interface for 577 the synchronous digital hierarchy (SDH)�, ITU-T, 578 October 2000. 580 [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment 581 1), �Interface for the Optical Transport Network 582 (OTN)�, ITU-T, October 2001. 584 [MPLS-BDL] K.Kompella et al., �Link Bundling in MPLS Traffic 585 Engineering,� Internet Draft, draft-ietf-mpls-bundle- 586 03.txt, May 2002. 588 [OSPF-TE] D.Katz, D.Yeung et K.Kompella, "Traffic Engineering 589 Extensions to OSPF", draft-katz-yeung-ospf-traffic- 590 06.txt, Internet Draft, Work in progress, October 2001. 592 [RFC-2370] R. Coltun, RFC 2370, Standard Track, "The OSPF Opaque 593 LSA Option", IETF, July 1998. 595 D.Papadimitriou et al. � Expires December 2002 11 596 6. Acknowledgments 598 The authors would like to thank Alberto Bellato, Michele Fontana, 599 and Jim Jones for their constructive comments and inputs leading to 600 the current version of this document. 602 7. Author's Addresses 604 Germano Gasparini (Alcatel) 605 Via Trento 30, 606 I-20059 Vimercate, Italy 607 Phone: +39 039 686-7670 608 Email: germano.gasparini@netit.alcatel.it 610 Gert Grammel (Alcatel) 611 Via Trento 30, 612 I-20059 Vimercate, Italy 613 Phone: +39 039 686-7060 614 Email: gert.grammel@netit.alcatel.it 616 Dimitri Papadimitriou (Alcatel) 617 Francis Wellesplein 1, 618 B-2018 Antwerpen, Belgium 619 Phone: +32 3 240-8491 620 Email: dimitri.papadimitriou@alcatel.be 622 D.Papadimitriou et al. � Expires December 2002 12 623 Appendix 1 � Abbreviations 625 1R Re-amplification 626 2R Re-amplification and Re-shaping 627 3R Re-amplification, Re-shaping and Re-timing 628 AI Adapted information 629 AIS Alarm Indication Signal 630 APS Automatic Protection Switching 631 BDI Backward Defect Indication 632 BEI Backward Error Indication 633 BI Backward Indication 634 BIP Bit Interleaved Parity 635 CBR Constant Bit Rate 636 CI Characteristic information 637 CM Connection Monitoring 638 EDC Error Detection Code 639 EXP Experimental 640 ExTI Expected Trace Identifier 641 FAS Frame Alignment Signal 642 FDI Forward Defect Indication 643 FEC Forward Error Correction 644 GCC General Communication Channel 645 IaDI Intra-Domain Interface 646 IAE Incoming Alignment Error 647 IrDI Inter-Domain Interface 648 MFAS MultiFrame Alignment Signal 649 MS Maintenance Signal 650 naOH non-associated Overhead 651 NNI Network-to-Network interface 652 OCC Optical Channel Carrier 653 OCG Optical Carrier Group 654 OCI Open Connection Indication 655 OCh Optical Channel (with full functionality) 656 OChr Optical Channel (with reduced functionality) 657 ODU Optical Channel Data Unit 658 OH Overhead 659 OMS Optical Multiplex Section 660 OMU Optical Multiplex Unit 661 OOS OTM Overhead Signal 662 OPS Optical Physical Section 663 OPU Optical Channel Payload Unit 664 OSC Optical Supervisory Channel 665 OTH Optical transport hierarchy 666 OTM Optical transport module 667 OTN Optical transport network 668 OTS Optical transmission section 669 OTU Optical Channel Transport Unit 670 PCC Protection Communication Channel 671 PLD Payload 672 PM Path Monitoring 673 PMI Payload Missing Indication 674 PRBS Pseudo Random Binary Sequence 675 PSI Payload Structure Identifier 677 D.Papadimitriou et al. � Expires December 2002 13 678 PT Payload Type 679 RES Reserved 680 RS Reed-Solomon 681 SM Section Monitoring 682 TC Tandem Connection 683 TCM Tandem Connection Monitoring 684 UNI User-to-Network Interface 686 Appendix 2 � G.709 Indexes 688 - Index k: The index "k" is used to represent a supported bit rate 689 and the different versions of OPUk, ODUk and OTUk. k=1 represents 690 an approximate bit rate of 2.5 Gbit/s, k=2 represents an 691 approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate 692 of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s 693 (under definition). The exact bit-rate values are in kbits/s: 694 OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 695 ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 696 OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 698 - Index m: The index "m" is used to represent the bit rate or set of 699 bit rates supported on the interface. This is a one or more digit 700 �k�, where each �k� represents a particular bit rate. The valid 701 values for m are (1, 2, 3, 12, 23, 123). 703 - Index n: The index "n" is used to represent the order of the OTM, 704 OTS, OMS, OPS, OCG and OMU. This index represents the maximum 705 number of wavelengths that can be supported at the lowest bit rate 706 supported on the wavelength. It is possible that a reduced number 707 of higher bit rate wavelengths are supported. The case n=0 708 represents a single channel without a specific wavelength assigned 709 to the channel. 711 - Index r: The index "r", if present, is used to indicate a reduced 712 functionality OTM, OCG, OCC and OCh (non-associated overhead is 713 not supported). Note that for n=0 the index r is not required as 714 it implies always reduced functionality. 716 D.Papadimitriou et al. � Expires December 2002 14 717 Full Copyright Statement 719 "Copyright (C) The Internet Society (date). All Rights Reserved. 720 This document and translations of it may be copied and furnished to 721 others, and derivative works that comment on or otherwise explain it 722 or assist in its implementation may be prepared, copied, published 723 and distributed, in whole or in part, without restriction of any 724 kind, provided that the above copyright notice and this paragraph 725 are included on all such copies and derivative works. However, this 726 document itself may not be modified in any way, such as by removing 727 the copyright notice or references to the Internet Society or other 728 Internet organizations, except as needed for the purpose of 729 developing Internet standards in which case the procedures for 730 copyrights defined in the Internet Standards process must be 731 followed, or as required to translate it into languages other than 732 English. 734 The limited permissions granted above are perpetual and will not be 735 revoked by the Internet Society or its successors or assigns. 737 This document and the information contained herein is provided on an 738 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 739 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 740 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 741 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 742 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 744 D.Papadimitriou et al. � Expires December 2002 15