idnits 2.17.1 draft-ashok-ccamp-gmpls-ospf-g709-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 176 instances of too long lines in the document, the longest one being 28 characters in excess of 72. ** There are 33 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC4328], [G.709-v1], [G.709-v3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 504 has weird spacing: '...I field must ...' == Line 538 has weird spacing: '...(s)" of a bun...' == Line 574 has weird spacing: '... BW" of a bun...' == Line 639 has weird spacing: '...erarchy provi...' == Line 746 has weird spacing: '...(s)" of a bun...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 14, 2011) is 4791 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) == Missing Reference: 'RFC 4202' is mentioned on line 396, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 444, but not defined == Unused Reference: 'RFC4204' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'RFC5339' is defined on line 1102, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5212 ** Downref: Normative reference to an Informational RFC: RFC 5339 -- Possible downref: Non-RFC (?) normative reference: ref. 'G.709-v3' Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Ashok Kunjidhapatham 3 Internet-Draft Rajan Rao 4 Intended status: Proposed Standard Biao Lu 5 Expires: September 15, 2011 Snigdho Bardalai 6 Khuzema Pithewan 7 Infinera Corp 8 John E Drake 9 Juniper Networks 10 Steve Balls 11 Metswitch Networks 12 March 14, 2011 14 OSPF TE Extensions for Generalized MPLS (GMPLS) Control of 15 G.709 Optical Transport Networks 16 draft-ashok-ccamp-gmpls-ospf-g709-03.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 As OTN network capabilities continue to evolve, there is an increased 57 need to support GMPLS control for the same. [RFC4328] introduced 58 GMPLS signaling extensions for supporting the early version of G.709 59 [G.709-v1]. The basic routing considerations from signaling 60 perspective is also specified in [RFC4328]. 62 The recent revision of ITU-T Recommendation G.709 [G.709-v3] and 63 [GSUP.43] have introduced new ODU containers (both fixed and 64 flexible) and additional ODU multiplexing capabilities, enabling 65 support for optimal service aggregation. 67 This document describes OSPF protocol extensions to support 68 Generalized MPLS (GMPLS) control for routing services over the 69 standardized OTU/ODU containers in support of ODU based TDM 70 switching. Routing support for Optical Channel Layer switching 71 (Lambda switching) is not covered in this document. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Conventions used in this document . . . . . . . . . . . . . . . 5 77 3. OTU/ODU Link Representation . . . . . . . . . . . . . . . . . . 5 78 3.1. OTUk TE-Link . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2. ODUk TE-Link . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.3. ODUj TE-Link . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.4. Bundled TE-Link . . . . . . . . . . . . . . . . . . . . . . 7 82 3.5. OTU/ODU Link Property Agreement . . . . . . . . . . . . . . 7 83 4. OTU/ODU Link Bandwidth Model . . . . . . . . . . . . . . . . . . 8 84 5. OSPF TE-LSA Extension . . . . . . . . . . . . . . . . . . . . . 9 85 5.1. Maximum Bandwidth . . . . . . . . . . . . . . . . . . . . . 9 86 5.2. Maximum Reservable Bandwidth . . . . . . . . . . . . . . . 9 87 5.3. Unreserved Bandwidth . . . . . . . . . . . . . . . . . . . 9 88 5.4. Interface Switch Capability Descriptor . . . . . . . . . . 9 89 5.4.1 ODU Switching . . . . . . . . . . . . . . . . . . . . 11 90 5.4.2. ODUk Switch Capability Specific Information . . . . 11 91 5.4.2.1 Bandwidth sub TLV for fixed ODUj . . . . . . . . 12 92 5.4.2.2 Bandwidth sub-TLV for ODUflex . . . . . . . . . 13 93 5.5. Interface Multiplexing Capability Descriptor . . . . . . 13 94 5.5.1 Multiplex Layers and Hierarchical LSP . . . . . . . . 14 95 5.5.2 IMCD format . . . . . . . . . . . . . . . . . . . . . 15 96 5.5.2.1 G-PID . . . . . . . . . . . . . . . . . . . . . 16 97 5.5.2.2 Available Bandwidth . . . . . . . . . . . . . . 17 98 5.5.3 Controlling IMCD advertisement . . . . . . . . . . . 17 99 5.5.4 How to use IMCDs for FA creation . . . . . . . . . . 18 100 5.5.5 IMCD and non OTN services . . . . . . . . . . . . . . 18 101 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 6.1. Network with no IMCD advertisement (no FA support) . . . 19 103 6.2. Network with IMCD advertisement for FA support . . . . . 20 104 6.3. Link bundle with similar muxing capabilities . . . . . . 22 105 6.4. Link bundle with dissimilar muxing capabilities: Layer 106 relation . . . . . . . . . . . . . . . . . . . . . . . . 23 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 10.1. Normative References . . . . . . . . . . . . . . . . . 25 110 10.2. Informative References . . . . . . . . . . . . . . . . 25 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 112 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 Appendix A: Abbreviations & Terminology . . . . . . . . . . . . 28 114 A.1 Abbreviations: . . . . . . . . . . . . . . . . . . . . . . 28 115 A.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 28 116 Appendix B : Optimization Techniques . . . . . . . . . . . . . . 30 117 B.1 Multiple ISCDs Vs. Single ISCD . . . . . . . . . . . . . . 30 118 B.1 Multiple IMCDs Vs. Single IMCD . . . . . . . . . . . . . . 30 119 B.1 Eight priorities Vs. restricted number of priorities . . . 30 120 Appendix C: Relation with MLN & MRN . . . . . . . . . . . . . . . 30 121 Appendix D : AMP, BMP & GMP Mapping . . . . . . . . . . . . . . . 30 123 1. Introduction 125 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 126 MPLS from supporting Packet Switching Capable (PSC) interfaces and 127 switching to include support of four new classes of interfaces and 128 switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), 129 Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional 130 description of the extensions to MPLS signaling that are needed to 131 support these new classes of interfaces and switching is provided in 132 [RFC3471]. OSPF extensions for supporting GMPLS are defined in 133 [RFC4203]. 135 ITU-T Recommendations G.709 and G.872 provide specifications for OTN 136 interface and network architecture respectively. As OTN network 137 capabilities continue to evolve; there is an increased need to 138 support GMPLS control for the same. 140 GMPLS signaling extensions to support G.709 OTN interfaces are 141 specified in [RFC4328]. The basic routing considerations from 142 signaling perspective is specified. G.709 specifications evolved 143 rapidly over the last few years. Following are the features added 144 in OTN since the first version [G.709-v1]. 146 (a) OTU Containers: 147 Pre-existing Containers: OTU1, OTU2 and OTU3 148 New Containers introduced in [G.709-v3]: OTU2e and OTU4 149 New Containers introduced in [GSUP.43]: OTU1e, OTU3e1 and OTU3e2 151 (b) Fixed ODU Containers: 152 Pre-existing Containers: ODU1, ODU2 and ODU3 153 New Containers introduced in [G.709-v3]: ODU0, ODU2e and ODU4 154 New Containers introduced in [GSUP.43]: ODU1e, ODU3e1 and ODU3e2 156 (c) Flexible ODU Containers: 157 ODUflex for CBR and GFP-F mapped services. ODUflex uses 'n' 158 number of OPU Tributary Slots where 'n' is different from the 159 number of OPU Tributary Slots used by the Fixed ODU Containers. 161 (d) Tributary Slot Granularity: 162 OPU2 and OPU3 support two Tributary Slot Granularities: 163 (i) 1.25Gbps and (ii) 2.5Gbps. 165 (e) Multi-stage ODU Multiplexing: 166 Multi-stage multiplexing of LO-ODUs into HO-ODU is supported. 167 Also, multiplexing could be heterogeneous (meaning LO-ODUs of 168 different rates can be multiplexed into a HO-ODU). 170 OTN networks support switching at two layers: (i) ODU Layer - TDM 171 Switching and (ii) OCH Layer - Lambda (LSC) Switching. The nodes on 172 the network may support one or both the switching types. When 173 multiple switching types are supported MRN/MLN based routing 174 [RFC5212] and [RFC6001] is assumed. 176 This document covers OSPF extensions to support routing over the 177 standardized OTU/ODU containers in support of ODU Layer based TDM 178 switching as outlined in the framework document [G.709-FRAME]. 179 The Interface Switch Capability Descriptor extensions for ODU Layer 180 switching and bandwidth representation for ODU containers are 181 defined in this document. 183 Routing support for Optical Channel Layer switching (LSC) is beyond 184 the scope of this document. Refer to [WSON-FRAME] for further 185 details. 187 2. Conventions used in this document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document is to be interpreted as described in RFC-2119 [RFC2119]. 193 In addition, the reader is assumed to be familiar with the 194 terminology used in ITU-T [G.709-v3], [G.872] and [GSUP.43], as 195 well as [RFC4201] and [RFC4203]. Abbreviations used in this 196 document is detailed in Appendix A. 198 3. OTU/ODU Link Representation 200 G.709 OTU/ODU Links are represented as TE-Links in GMPLS Traffic 201 Engineering Topology for supporting ODU layer switching. These 202 TE-Links can be modeled in multiple ways. Some of the prominent 203 representations are captured below. 205 3.1. OTUk TE-Link 207 OTUk Link can be modeled as a TE-Link. Switching at ODUk layer 208 and ODUj layer (including multi-stage multiplexing) can be managed on 209 OTUk TE-Link. Figure-1 below provides an illustration of this link 210 type. 212 When a LO-ODU layer being switched on an OTUk interface involves 213 multi-stage multiplexing, all the HO-ODU layer(s) should 214 necessarily terminate between the same pair of nodes as the OTUk 215 layer in this case. For example, if ODU1 layer switching is 216 configured on a OTU3 link via multiplexing hierarchy 217 ODU3<-ODU2<-ODU1, HO-ODUs (namely ODU3 & ODU2) should terminate 218 between the same pair of nodes as OTU3 layer. 220 +-------+ +-------+ +-------+ 221 | OTN | | OTN | | OTN | 222 |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch | 223 | A | | B | | C | 224 +-------+ +-------+ +-------+ 226 |<-- TE-Link -->| |<-- TE-Link -->| 228 Figure-1: OTUk TE-Link 230 3.2. ODUk TE-Link 232 When ODUk layer does not terminate on the same pair of nodes 233 as OTUk layer, ODUk link should be modeled as a TE-Link. As 234 bandwidth is directly managed on the ODUk link, associated OTUk 235 links are not significant in this case. Switching at ODUj layer 236 (including multi-stage multiplexing) can be managed on ODUk TE-Link. 237 Figure-2 below provides an illustration of this link type. 239 When a LO-ODU layer being switched on the ODUk interface involves 240 multi-stage multiplexing, all the HO-ODU layer(s) should necessarily 241 terminate between the same pair of nodes as ODUk in this case. For 242 example, if ODU1 layer switching is configured on an ODU3 link via 243 multiplexing hierarchy ODU3<-ODU2<-ODU1, HO-ODU (namely ODU2) 244 should terminate between the same pair of nodes as ODU3. 246 +-------+ +-------+ +-------+ 247 | OTN | | OTN | | OTN | 248 |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch | 249 | A | | B | | C | 250 +-------+ +-------+ +-------+ 251 ODUk Switched 253 |<------------- ODUk Link ------------->| 254 |<-------------- TE-Link--------------->| 256 Figure-2: ODUk TE-Link 258 3.3. ODUj TE-Link 260 When a LO-ODUj within a HO-ODUk does not terminate on the same 261 pair of nodes as HO-ODUk layer, Separate TE-Links needs to be 262 modeled for ODUk link and ODUj link. Also, ODUk link shall 263 no longer manage the bandwidth associated with the ODUj link. 264 Switching at sub-ODUj layer (including multi-stage multiplexing) 265 can be supported on this ODUj TE-Link. Figure-3 below provides 266 an illustration of this link type. 268 When a LO-ODU layer being switched on an ODUj interface involves 269 multi-stage multiplexing, all the HO-ODU layer(s) should necessarily 270 terminate between the same pair of nodes as ODUj in this case. For 271 example, if ODU0 layer switching is configured on an ODU2 link via 272 multiplexing hierarchy ODU2<-ODU1<-ODU0, HO-ODU (namely ODU1) 273 should terminate between the same pair of nodes as ODU2. 275 +-----+ +-----+ +-----+ +-----+ 276 | OTN | | OTN | | OTN | | OTN | 277 | SW |<-OTUk Link->| SW |<-OTUk Link->| SW |<-OTUk Link->| SW | 278 | A | | B | | C | | D | 279 +-----+ +-----+ +-----+ +-----+ 280 ODUj Switched ODUk Switched 282 |<--------- ODUk Link ---------->| 283 |<--------- TE-Link #1 --------->| 285 |<-------------------- ODUj Link ------------------->| 286 |<-------------------- TE-Link #2 ------------------>| 288 Figure-3: ODUj TE-Link 290 3.4. Bundled TE-Link 292 Any mix of OTU and ODU links of dissimilar rates that terminates on 293 same pair of nodes and meets the entire bundling criterion specified in 294 TE-Link Bundling specification [RFC4201] can be pulled together to 295 form a Bundle TE-Link. This is required for better scalability. 297 3.5. OTU/ODU Link Property Agreement 299 The OTN interfaces (associated with peer nodes) participating in a 300 TE-Link may not be fully compatible in terms of OTN interface 301 properties. The lowest common denominator between the two links 302 endpoints need to be used for forming the TE link. Some of OTN 303 specific link properties that need to be agreed upon between 304 the two link endpoints (on peer nodes) are: 306 (a) OPU Tributary Slot Granularity for OPU2 and OPU3. 308 (b) Multiplexing hierarchies supported - both number of stages and 309 specific LO-ODUs supported in each stage. This includes both 310 Fixed and Flexible ODU containers. 312 These link properties either can be configured or discovered through 313 Link discovery mechanism. The details of such mechanism is beyond the 314 scope of this document. 316 4. OTU/ODU Link Bandwidth Model 318 Bandwidth allocation/management on OTU/ODU links is done in terms 319 of discrete units called OPU Tributary Slots. OPU Tributary Slots 320 occurs in two granularities (1.25Gbps and 2.5Gbps) and the actual 321 bit-rate of the OPU Tributary Slot slightly varies for different 322 ODU container types (i.e., ODU1, ODU2, ODU3 and ODU4). As a result 323 of this disparity, number of Tributary Slots required to map a 324 LO-ODU on different HO-ODU container types could vary. For example, 325 ODU2e requires 9 OPU TSs on ODU3 and 8 OPU TSs on ODU4. 327 The basic objectives of OTN interface bandwidth model are as 328 follows: 330 (a) Support ODU multi-stage multiplexing hierarchy and yet not 331 require advertisement of complete hierarchy tree. 333 (b) Account for bandwidth fragmentation that can result due to 334 the restricted multiplexing hierarchy supported on an OTN 335 interface. For example, assume that an ODU3 interface 336 supports direct multiplexing of ODU2 only. Here, mapping 337 of ODU1 and ODU0 is possible only through second stage 338 multiplexing underneath ODU2. If two ODU1 are created under 339 two different ODU2, only two ODU2 can be created further on 340 the interface although 28 Tributary Slots (1.25Gbps) are 341 available on the interface (ODU hierarchy). 343 (c) Hide the complexities in Tributary Slot Granularities (1.25Gbps 344 and 2.5Gbps) from bandwidth model and thereby simplify the 345 end-to-end path computation. As explained in the previous 346 section, this needs to be negotiated as a part of link 347 discovery or pre-configured locally on the either ends. 349 (d) Hide the complexities in Tributary Slot Size disparities (among 350 ODU containers) and number of Tributary Slots required to map 351 a LO-ODU. This can be achieved by advertising the number of 352 LO-ODU containers that can be mapped on an OTN interface rather 353 than number of Tributary Slots or absolute bandwidth in 354 bytes/sec. 356 (e) For ODU-Flex service, Absolute bandwidth required (for CBR 357 or GFP mapped service) needs to be mapped to 'n' Tributary 358 Slots of certain bit rate. This needs Tributary Slot bit-rate 359 and number of Tributary slots to be advertised. 361 5. OSPF TE-LSA Extension 363 This section describes the OSPF TE-LSA Extensions to support 364 bandwidth encoding for OTU/ODU TE-Links. 366 5.1. Maximum Bandwidth 368 The format and interpretation of this attribute must be consistent 369 with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support 370 [RFC4201] specifications. The OPUk payload nominal rate (in bytes 371 per sec) as specified in [G.709-v3] shall be encoded in this 372 attribute. 374 5.2. Maximum Reservable Bandwidth 376 The format and interpretation of this attribute must be consistent 377 with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support 378 [RFC4201] specifications. 380 5.3. Unreserved Bandwidth 382 The format and interpretation of this attribute must be consistent 383 with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support 384 [RFC4201] specifications. 386 Unreserved Bandwidth in bytes per second is not of much value for 387 OTU/ODU interfaces. Unreserved Bandwidth per ODU rate is more 388 appropriate and useful in this case. Implementations may choose to 389 ignore this attribute and consider per ODU-rate Unreserved Bandwidth 390 defined in Interface Switch Capability Descriptor for "G.709 ODUk" 391 encoding type. See section 5.4.1 for details. 393 5.4. Interface Switch Capability Descriptor 395 The Interface Switching Capability Descriptor describes switching 396 capability of an interface [RFC 4202]. This document defines a new 397 Switching Capability value for OTN [G.709-v3] as follows: 399 Value Type 400 ----- ---- 401 250 OTN-TDM capable (OTN-TDM) 403 Nodes advertising ODUk switching BW for for its links must use 404 Switching Type and Encoding values as follows: 406 Switching Type = OTN-TDM 407 Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328] 408 Both fixed ODUk (where k=0,1,2,3,4,1e,2e) and flexible ODUs (ODUflex) 409 use same switching type and encoding values. 411 When Swithcing Type and Encoding fields are set to values as stated 412 above, the Interface Switching Capability Descriptor should be 413 interpreted as follows: 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 | Switching Cap | Encoding | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Max LSP Bandwidth at priority 0 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Max LSP Bandwidth at priority 1 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Max LSP Bandwidth at priority 2 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Max LSP Bandwidth at priority 3 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Max LSP Bandwidth at priority 4 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Max LSP Bandwidth at priority 5 | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Max LSP Bandwidth at priority 6 | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Max LSP Bandwidth at priority 7 | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | ODUk - Switch Capability Specific Information | 437 | (variable length) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Maximum LSP Bandwidth 442 This field should be encoded with Nominal Rate of the ODUj (j<= k) for 443 which Bandwidth is advertised. The bandwidth unit is in bytes per second & 444 the encoding is in IEEE floating point format [RFC 3471]. The discrete values 445 for varous ODUj(s) is shown in the table below. 447 For an unbundled link, the Maximum LSP Bandwidth at priority 'p' is set to 448 Nominal rate of the ODUj for which bandwidth is advertised in Switch 449 Capability Specific Information (SCSI). 451 For bundled link too, the Maximum LSP Bandwidth at priority 'p' is set to 452 Nominal rate of the ODUj for which bandwidth is advertised in Switch 453 Capability Specific Information (SCSI). 455 ODU type Nomial Rate(bytes/s) Value in Byes/Sec (IEEE format) 456 ----------- ----------------- ------------------------------ 457 ODU0 15552000 458 ODU1 312346890.75 459 ODU2 1254659240.50 460 ODU2e 1299940664.50 461 ODU1e 462 ODU3 5039902372.875 463 ODU4 13099305726.875 464 ODUflex Any 466 The Maximum LSP bandwidth field is used to identify the ODUj type. 468 5.4.1 ODU Switching 470 When Switching Capability is set to OTN-TDM, it means the node is capable of 472 - terminating OTUk layer 473 - Switching of HO-ODU (ODUk) 474 - switching of LO-ODU (ODUj) if HO-ODU supports mux/demux 475 (termination of HO-ODU is required for mux/demux operation) 477 Multiple ISCDs would be advertised if an interface supports more than one 478 type of ODUk switching. There would be one ISCD advertisement per ODUj 479 independent of the OTN multiplexing branch it belongs to. 481 For e.g. If an OTU3 interface supports ODU0, ODU1 and ODU2 switching, there 482 would be three ISCDs one for each ODU type. 484 Refer to examples in section 7.0. 486 5.4.2. ODUk Switch Capability Specific Information 488 This SCSI field contains bandwidth information for fixed 489 ODUj(j=0,1,2,3,4,2e,1e) or ODUflex. 491 The type of ODUj/ODuflex is identified by Maximum LSP bandwidth field and 492 BW sub TLV Type field as follows. 494 If bandwidth advertisement is for fixed size ODUj, then 495 - set BW sub TLV Type = 1 496 - Encode nominal rate of the ODUj in Max LSP BW field 497 - Encode avaialble number of ODUj(s) as shown below 499 If bandwidth advertisment is for ODUflex, then 500 - set BW sub TLV Type = 2 501 - Encode available BW in Max LSP BW field 502 - Encode avaialble Bandwidth as shown below 504 The SCSI field must be included when Switching Capability is "OTN-TDM". 506 5.4.2.1 Bandwidth sub TLV for fixed ODUj 508 The format of Bandwidth sub TLV for fixed size ODUj is shown below; 509 (j=0,1,2,3,4,2e,1e). The TLV Type must be set to 1 for fixed ODUs. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type=1 (for fixed ODUj) | Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Available ODUj count at priority 0 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Available ODUj count at priority 1 | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Available ODUj count at priority 2 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Available ODUj count at priority 3 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Available ODUj count at priority 4 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Available ODUj count at priority 5 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Available ODUj count at priority 6 | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Available ODUj count at priority 7 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Available ODUj(s): 535 This field (32 bits) indicates the maximum number of Containers 536 of a given ODUj-Type at priority 'p' available on this TE-Link. 538 The "Available ODUj(s)" of a bundled link at priority p is defined 539 to be the sum of "Available ODUj(s)" at priority p of all of its 540 component links. 542 5.4.2.2 Bandwidth sub-TLV for ODUflex 544 The format of Bandwidth sub TLV for ODUflex is shown below. 545 The TLV Type is set to 2 for flexible ODUs. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type=2 (for ODUflex) | length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Available ODUflex BW in bytes/sec priority 0 | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Available ODUflex BW in bytes/sec priority 1 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Available ODUflex BW in bytes/sec priority 2 | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Available ODUflex BW in bytes/sec priority 3 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Available ODUflex BW in bytes/sec priority 4 | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Available ODUflex BW in bytes/sec priority 5 | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Available ODUflex BW in bytes/sec priority 6 | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Available ODUflex BW in bytes/sec priority 7 | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Available BW (in bytes/sec) 571 Available BW (in bytes/sec) is represented in IEEE float-point 572 format similar to Max-Lsp-Bandwidth in ISCD. 574 The "Available BW" of a bundled link at priority p is defined 575 to be the sum of "Available BW" at priority p of all of its 576 component links. 578 This information may be used to route LSPs over links which 579 have most bandwidth available. 581 5.5. Interface Multiplexing Capability Descriptor 583 The OTN multiplexing hierarchy involves one or more ODU layers. The 584 server ODU layer is called the higher order ODU(HO-ODU) and the layer 585 multiplexed into a server ODU layer is called lower order ODU (LO-ODU). 587 A HO-ODU can carry (mux/demux) one or more LO-ODUs as specified in G.709. 588 Termination of HO-ODU is necessary to mux/demux LO-ODUs. For e.g. 590 a) on a OTU2 interface with OTU2-ODU2-ODU0 muxing stack, 591 it is necessary to terminate ODU2(H) in order to mux/demux 592 contained ODU0s. 594 b) on a OTU2 interface with OTU2-ODU2-ODU1-ODU0 muxing stack, 595 it is necessary to terminate ODU2 and ODU1 layers to mux/demux 596 contained ODU0s. 598 An OTN interface supporting multi-stage multiplexing requires termination 599 of more than one HO-ODU to access one or more LO-ODUs for switching purposes. 600 For e.g. on an interface with OTU3-ODU3-ODU2-ODU0 multiplexing stack/hierarchy, 601 ODU3 and ODU2 layers should be terminated to access ODU0s for switching purposes. 603 5.5.1 Multiplex Layers and Hierarchical LSP 605 It is possible to construct H-LSP(s) using different HO-ODU muxing layer(s). 606 While creation of H-LSP is optional, it becomes necessary in network 607 scenarios where switching restrictions exist for LO-ODUs. 609 Example #1: 611 - Nodes A, B, D & E are ODU0 and ODU2 switching capable; 612 - Nodes C is ODU2 switching capable only. 614 An ODU2-FA between nodes B & D is necessary to support E2E ODU0-LSP(s) 616 A-----B---------C--------D-----E 618 <-----ODU2-FA------> 619 <------------ODU0-LSP --------> 621 Example #2: ODU0-LSP over G.709-v1 capable node (legacy node) 623 - Nodes A, B, D & E are ODU0 & ODU1 switch capable nodes; 624 - Node C is ODU1 switching capable 626 An ODU1-FA between nodes B & D is necessary to support E2E ODU0-LSPs 628 A-----B---------C--------D-----E 630 <-----ODU1-FA------> 631 <------------ODU0-LSP --------> 633 In order to support identification of potential FA boundary points, it is 634 necessary to flood mux/demux information. This includes information about: 636 - the HO-ODU layer which can be terminated 637 - the LO-ODUs available upon HO-ODU termination (muxing hierarchy) 639 The multiplexing hierarchy provides information about 640 specific branch(es) of the OTN muxing hierarchy. This includes 642 - one or more HO-ODU(s) which needs to be terminated and 643 - a LO-ODU layer which can be accessed after termination 645 The HO-ODUs which are terminate-able are potential FA end points. 646 FA becomes necessary when switching bandwidth is not available at all 647 nodes along the path for an LSP (specifically for LSPs at LO-ODU layers). 649 This draft proposes the use of IMCD (Interface Multiplexing Capability 650 Descriptor) to distribute OTN mux/demux information of Te-end points. 652 5.5.2 IMCD format 654 The Interface Multiplexing Capability Descriptor (IMCD) describes 655 "Multiplexing" capability of an interface. It is a sub-TLV of the 656 Link TLV (Type TBD). The format of value field is as shown below: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | G-PID | Reserved | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Available HO-ODUj count at priority 0 | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Available HO-ODUj count at priority 1 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Available HO-ODUj count at priority 2 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Available HO-ODUj count at priority 3 | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Available HO-ODUj count at priority 4 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Available HO-ODUj count at priority 5 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Available HO-ODUj count at priority 6 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Available HO-ODUj count at priority 7 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 5.5.2.1 G-PID 682 The G-PID field is a 16 bit field as defined in [RFC3471]. 683 New G-PID values are defined in addition to those defined in [RFC3471]. 684 Within OTN context, the new G-PID values identify multiplexing stack 685 supported by the Te-end point. 687 The table below shows newly defined values for G-PID: 689 Value G-PID Meaning 690 ----- ------ ---------------------------- 691 60 ODU1-ODU0 ODU1 termination required 692 61 ODU2-ODU0 ODU2 termination required 693 62 ODU2-ODU1 ODU2 termination required 694 63 ODU2-ODU1-ODU0 ODU2 & ODU1 termination required 695 64 ODU2-ODUflex ODU2 termination required 696 65 ODU3-ODU0 ODU3 termination required 697 66 ODU3-ODU1 ODU3 termination required 698 67 ODU3-ODU1-ODU0 ODU3 & ODU1 termination required 699 68 ODU3-ODU2 ODU3 termination required 700 69 ODU3-ODU2-ODU0 ODU3 & ODU2 termination required 701 70 ODU3-ODU2-ODU1 ODU3 & ODU2 termination required 702 71 ODU3-ODU2-ODU1-ODU0 ODU3 & ODU2 & ODU1 termination required 703 72 ODU3-ODU2-ODUflex ODU3 & ODU2 termination required 704 73 ODU3-ODUflex ODU3 termination required 705 74 ODU3-ODU2e ODU3 termination required 706 75 ODU4-ODU0 ODU4 termination required 707 76 ODU4-ODU1 ODU4 termination required 708 77 ODU4-ODU1-ODU0 ODU4 & ODU1 termination required 709 78 ODU4-ODU2 ODU4 termination required 710 79 ODU4-ODU2-ODU0 ODU4 & ODU2 termination required 711 80 ODU4-ODU2-ODU1 ODU4 & ODU2 termination required 712 81 ODU4-ODU2-ODU1-ODU0 ODU4 & ODU2 & ODU1 termination required 713 82 ODU4-ODU2-ODUflex ODU4 & ODU2 termination required 714 83 ODU4-ODU3 ODU4 termination required 715 84 ODU4-ODU3-ODU0 ODU4 & ODU3 termination required 716 85 ODU4-ODU3-ODU1 ODU4 & ODU3 termination required 717 86 ODU4-ODU3-ODU1-ODU0 ODU4 & ODU3 & ODU1 termination required 718 87 ODU4-ODU3-ODU2 ODU4 & ODU3 termination required 719 88 ODU4-ODU3-ODU2-ODU0 ODU4 & ODU3 & ODU2 termination required 720 89 ODU4-ODU3-ODU2-ODU1 ODU4 & ODU3 & ODU2 termination required 721 90 ODU4-ODU3-ODU2-ODU1-ODU0 ODU4 & ODU3 & ODU2 & ODU1 termination 722 required 723 91 ODU4-ODU3-ODU2-ODUflex ODU4 & ODU3 & ODU2 termination required 724 92 ODU4-ODU3-ODUflex ODU4 & ODU3 termination required 725 93 ODU4-ODU3-ODU2e ODU4 & ODU3 termination required 726 94 ODU4-ODUflex ODU4 termination required 727 95 ODU4-ODU2e ODU4 termination required 728 96 ODU1 ODU1 termination required 729 97 ODU2 ODU2 termination required 730 98 ODU3 ODU3 termination required 731 99 ODU4 ODU4 termination required 732 100 ODU2-GFP-10GBE ODU2 termination for Ethernet 733 101 ODU2e-10GBE ODU2e termination for Ethernet 734 102 ODU2-OC192 ODU2 termination for SONET 736 5.5.2.2 Available Bandwidth 738 The available bandwidth advertised in "Available HO-ODUj" field 739 indicates the number of "Terminations" possible at HO-ODUj layer. 740 The HO-ODUj layer (Parent ODU) is identified by G-PID field. 742 This field (32 bits) indicates maximum number of Containers 743 of a given HO-ODUj at priority 'p' available on the TE-Link; 744 where {j=1,2,3,4}. 746 The "Available HO-ODUj(s)" of a bundled link at priority 'p' is 747 defined to be the sum of "Available HO-ODUj(s)" at priority 'p' of all 748 of its component links for that specific G-PID. 750 Example#1: Unbundled link with ODU2-ODU0 muxing hierarchy support 752 A ---------- B 754 IMCD advertised would be as follows: 755 o G-PID= ODU2-ODU0 756 o Available HO-ODUj count = 1 ( refers to ODU2 layer) 758 The ODU2 termination implies ability to mux/demux 8xODU0s. 760 Example#2: Bundled Te-link with ODU2-ODU0 muxing hierarchy support (3 links) 762 A ========== B 764 IMCD advertised would be as follows: 765 o G-PID= ODU2-ODU0 766 o Available HO-ODUj count = 3 (refers to ODU2 layer) 768 The ODU2 termination implies ability to mux/demux 24xODU0s in total. 770 5.5.3 Controlling IMCD advertisement 772 The IMCD advertisement is not mandatory and it is required only 773 when FA support is needed. 775 The network operators can selectively enable IMCD advertisement 776 for specific HO-ODU mux layer(s). This can be done on a 777 link by link basis, node basis or network basis. The mechanism 778 to achieve this is outside the scope of this document. 780 5.5.4 How to use IMCDs for FA creation 782 When computing path for an FA (induced or otherwise), the path 783 computing node should look for matching G-PIDs at the FA boundary nodes. 784 For example, to create ODU1-FA for ODU0 service, the path computation 785 should look for matching G-PID = ODU1-ODU0 at nodes B & D 787 The need for FA is due to Node-C's ability to switch ODU1 only. 789 A-----B---------C--------D-----E 791 <-----ODU1-FA------> 792 <------------ODU0-LSP --------> 794 5.5.5 IMCD and non OTN services 796 In certain deployments it may be beneficial to advertise ODU 797 termination bandwidth without the LO-ODU information. The intent is to 798 allow signaling to decide non-OTN signal to adapt at the time 799 of path establishment. 801 The G-PID values 96, 97, 98, 99 defined in section 5.5.2.1 are meant for 802 this purpose. 804 The path computation can also be preformed for specific clients over 805 an ODUj using G-PID values 100, 101 & 102 (e.g. 10GBE mapping to 806 ODU2 using GFP). 808 6. Examples 810 This sections presents some use-cases for bandwidth encoding 811 and usage. 813 6.1. Network with no IMCD advertisement (no FA support) 815 A-------B------C------D-----E 817 Suppose Muxing Hierarchy supported at the end points as shown: 819 Link A-B: Mux hierarchy at A & B ends is as follows: 821 ODU1 ODU0 822 \ / 823 \ / 824 ODU2 825 | 826 OTU2 828 Link B-C: Mux hierarchy at B & C ends is as follows: 830 ODU0 831 | 832 ODU1 ODU0 833 \ / 834 \ / 835 ODU2 836 | 837 OTU2 839 Link C-D: mux hierarchy at C & D ends is as follows: 841 ODU0 842 | 843 ODU1 844 | 845 ODU2 846 | 847 OTU2 849 a) The ISCD advertisement by nodes A, B, C & D would be as follows 851 ISCD1: 852 Max LSP BW = ODU2 nominal rate in bytes/sec 853 Available ODU2 count at priority 'p' = 1 855 ISCD2: 856 Max LSP BW = ODU1 nominal rate in bytes/sec 857 Available ODU1 count at priority 'p' = 4 859 ISCD3: 860 Max LSP BW = ODU0 nominal rate in bytes/sec 861 Available ODU0 count at priority 'p' = 8 863 b) BW advertisement after an ODU0-LSP creation from A to D. 864 The bandwidth is no longer available at ODU2 rate. 866 ISCD1: 867 Max LSP BW = ODU1 nominal rate in bytes/sec 868 Available ODU1 count at priority 'p' = 3 870 ISCD2: 871 Max LSP BW = ODU0 nominal rate in bytes/sec 872 Available ODU0 count at priority 'p' = 7 874 6.2. Network with IMCD advertisement for FA support 876 A-------B------C------D-----E 877 <---ODU1-FA---> 878 <---------- ODU0-LSP -------> 880 The above network can support FA at ODU2 and ODU1 layers. 881 To support FA origination/termination, the IMCDs would be advertised 882 as follows. This is in addition to ISCD advertisement. 884 The ISCD1, ISCD2 & ISCD3 advertisement by A, B, C & D is same as in section 7.1 886 The IMCD advertisement by A & B for link A-B: 887 IMCD1: 888 G-PID = ODU2-ODU1 889 Available HO-ODUj count at Pi = 1 (ODU2) 891 IMCD2: 892 G-PID = ODU2-ODU0 893 Available HO-ODUj count at Pi = 1 (ODU2) 895 The IMCD advertisement by B & C for link B-C: 896 IMCD1: 898 G-PID = ODU2-ODU1 899 Available HO-ODUj count at Pi = 1 (ODU2) 901 IMCD2: 902 G-PID = ODU2-ODU0 903 Available HO-ODUj count at Pi = 1 (ODU2) 905 IMCD3: 906 G-PID = ODU1-ODU0 907 Available HO-ODUj count at Pi = 4 (ODU1) 909 The IMCDs advertised by C & D for link C-D would be as follows: 910 IMCD1: 911 G-PID = ODU2-ODU1 912 Available HO-ODUj count at Pi = 1 (ODU2) 914 IMCD2: 915 G-PID = ODU2-ODU1-ODU0 916 Available HO-ODUj count at Pi = 1 (ODU2) 918 IMCD3: 919 G-PID = ODU1-ODU0 920 Available HO-ODUj count at Pi = 4 (ODU1) 922 The IMCD advertisement by B & C for link B-C after ODU1-FA creation: 923 IMCD1: 924 G-PID = ODU1-ODU0 925 Available HO-ODUj count at Pi = 3 (ODU1) 927 The IMCD advertisement by C & D for link C-D after ODU1-FA creation: 928 IMCD1: 929 G-PID = ODU1-ODU0 930 Available HO-ODUj count at Pi = 3 (ODU1) 932 6.3. Link bundle with similar muxing capabilities 934 Consider a Bundled Te-link with 2xOTU3 links between Nodes A & B with 935 multiplexing hierarchy as shown: 937 ODU1 ODU0 938 \ / ODU0 939 \ / | 940 ODU2 ODU1 ODU0 ODUflex 941 | / / / 942 ---------------- 943 | 944 ODU3 945 | 946 OTU3 947 A ===================== B 949 The ISCDs and IMCDs advertised by A & B would be as follows: 951 ISCD1: 952 Max LSP BW = ODU3 nominal rate in bytes/sec 953 Available ODU3 count at priority 'p' = 2 955 ISCD2: 956 Max LSP BW = ODU2 nominal rate in bytes/sec 957 Available ODU2 count at priority 'p' = 8 959 ISCD3: 960 Max LSP BW = ODU1 nominal rate in bytes/sec 961 Available ODU1 count at priority 'p' = 32 963 ISCD4: 964 Max LSP BW = ODU0 nominal rate in bytes/sec 965 Available ODU0 count at priority 'p' = 64 967 ISCD5: 968 Max LSP BW = ODU3 nominal rate in bytes/sec 969 Available ODUflex BW = 2xODU3 BW in byte/sec 971 To support FAs at ODU3, ODU2 & ODU1 rates, the following IMCDs are advertised 973 IMCD1: 974 G-PID = ODU3-ODU2 975 Available HO-ODUj count at Pi = 2 (ODU3) 977 IMCD2: 978 G-PID = ODU3-ODU2-ODU1 979 Available HO-ODUj count at Pi = 2 (ODU3) 981 IMCD3: 982 G-PID = ODU3-ODU2-ODU0 983 Available HO-ODUj count at Pi = 2 (ODU3) 985 IMCD4: 986 G-PID = ODU3-ODU1 987 Available HO-ODUj count at Pi = 2 (ODU3) 989 IMCD5: 990 G-PID = ODU3-ODU1-ODU0 991 Available HO-ODUj count at Pi = 2 (ODU3) 993 IMCD6: 994 G-PID = ODU3-ODU0 995 Available HO-ODUj count at Pi = 2 (ODU3) 997 IMCD7: 998 G-PID = ODU2-ODU1 999 Available HO-ODUj count at Pi = 8 (ODU2) 1001 IMCD8: 1002 G-PID = ODU2-ODU0 1003 Available HO-ODUj count at Pi = 8 (ODU2) 1005 IMCD9: 1006 G-PID = ODU1-ODU0 1007 Available HO-ODUj count at Pi = 32 (ODU1) 1009 IMCD9: 1010 G-PID = ODU3-ODUflex 1011 Available HO-ODUj count at Pi = 3 (ODUflex) 1013 6.4. Link bundle with dissimilar muxing capabilities: Layer relation 1015 A---------B---------C--------D-------E 1016 |------ODU2-FA-----| 1017 |------ODU1-FA-------------| 1018 |----------------ODU0-LSP------------| 1020 Link A-B: Hierarchy at both ends is OTU2-ODU2-ODU0 1021 Link B-C: Is a bundled Te-link with 3 component links with 1022 multiplexing hierarchy at both ends as shown: 1024 Component link#1: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1-ODU0 1025 Component link#2: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1 1026 Component link#3: OTU1 link with mux hierarchy: OTU1-ODU1-ODU0 1027 Link C-D: 1028 - Hierarchy at C end is OTU2-ODU2 1029 - Hierarchy at D end is OTU2-ODU2-ODU1 1031 Link D-E: 1032 - Hierarchy at D end is OTU1-ODU1 1033 - Hierarchy at E end is OTU1-ODU1-ODU0 1035 The IMCDs advertised for B-C would include the following: 1036 IMCD1: 1037 G-PID = ODU2-ODU1 1038 Available HO-ODUj count at Pi = 2 (ODU2) 1040 IMCD2: 1041 G-PID = ODU1-ODU0 1042 Available HO-ODUj count at Pi = 5 (ODU1) 1044 IMCD3: 1045 G-PID = ODU2-ODU1-ODU0 1046 Available HO-ODUj count at Pi = 1 (ODU2) 1048 In this example, we need two FAs to originate from the same point (at node-B). 1049 It is necessary to advertise IMCD3 as we can not conclude full mux 1050 relation from IMCD1 & IMCD2. 1052 7. Backward Compatibility 1054 If backwards compatibility is required with G.709-v1, then [RFC4328] 1055 based ISCDs should be a advertised in addition to ISCDs/IMCDs specified 1056 in this document. 1058 8. Security Considerations 1060 There are no additional security implications to OSPF routing 1061 protocol due to the extensions captured in this document. 1063 9. IANA Considerations 1065 The memo introduces two new sub-TLVs of the Interface Switch Capability 1066 Descriptor Sub-TLV of TE-LSA. [RFC3630] says that the sub-TLVs of the 1067 TE Link TLV in the range 10-32767 must be assigned by Expert Review, 1068 and must be registered with IANA. 1070 10. References 1072 10.1. Normative References 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels". 1077 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1078 (TE) Extensions to OSPF Version 2", RFC 3630 1080 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1081 (GMPLS) Signaling Functional Description", RFC 3471, 1082 January 2003. 1084 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 1085 MPLS Traffic Engineering (TE)" 1087 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of 1088 Generalized Multi-Protocol Label Switching (GMPLS)" 1090 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 1091 4204, October 2005. 1093 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 1094 Switching (GMPLS) Signaling Extensions for G.709 Optical 1095 Transport Networks Control", RFC 4328, January 2006. 1097 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1098 M., and D. Brungard, "Requirements for GMPLS-Based 1099 Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 1100 5212, July 2008. 1102 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 1103 GMPLS Protocols against Multi-Layer and Multi-Region 1104 Networks (MLN/MRN)", RFC 5339, September 2008. 1106 [RFC6001] D. Papadimitriou, et al, Generalized MPLS (GMPLS) 1107 Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) 1109 [G.709-v3] ITU-T, "Interfaces for the Optical Transport Network 1110 (OTN)", G.709 Recommendation, December 2009. 1112 [GSUP.43] ITU-T, "Proposed revision of G.sup43 (for agreement)", 1113 December 2008. 1115 10.2. Informative References 1117 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1118 (GMPLS) Architecture", RFC 3945, October 2004. 1120 [G.709-v1] ITU-T, "Interface for the Optical Transport Network 1121 (OTN)," G.709 Recommendation (and Amendment 1), February 1122 2001 (October 2001). 1124 [G.872] ITU-T, "Architecture of optical transport networks", 1125 November 2001 (11 2001). 1127 [G.709-FRAME] F. Zhang, D. Li, H. Li, S. Belotti, "Framework for 1128 GMPLS and PCE Control of G.709 Optical Transport 1129 Networks", draft-zhang-ccamp-gmpls-g709-framework-02, 1130 work in progress. 1132 [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 1133 and PCE Control of Wavelength Switched Optical Networks 1134 (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in 1135 progress. 1137 11. Acknowledgements 1139 Special thanks to Daniele Ceccarelli, Lyndon Ong, Sergio Belotti, 1140 Pietro Grandi, Jonathan Sadler, Remi Theillaud, Fatai Zhang and 1141 Diego Caviglia for discussions on various modeling options. 1143 Authors would like to thank Lou Berger,Ping Pan, Radhakrishna 1144 Valiveti and Mohit Misra for review comments and suggestions. 1146 Author's Addresses 1148 Ashok Kunjidhapatham 1149 Infinera Corporation 1150 169, Java Drive 1151 Sunnyvale, CA-94089 1152 USA 1153 Email: akunjidhapatham@infinera.com 1155 Rajan Rao 1156 Infinera Corporation 1157 169, Java Drive 1158 Sunnyvale, CA-94089 1159 USA 1160 Email: rrao@infinera.com 1162 Snigdho Bardalai 1163 Infinera Corporation 1164 169, Java Drive 1165 Sunnyvale, CA-94089 1166 USA 1167 Email: sbardalai@infinera.com 1169 Khuzema Pithewan 1170 Infinera Corporation 1171 169, Java Drive 1172 Sunnyvale, CA-94089 1173 USA 1174 Email: kpithewan@infinera.com 1176 Biao Lu 1177 Infinera Corporation 1178 169, Java Drive 1179 Sunnyvale, CA-94089 1180 USA 1181 Email: blu@infinera.com 1183 John Drake 1184 Juniper Networks 1185 USA 1186 Email: jdrake@juniper.net 1188 Steve Balls 1189 Metaswitch Networks 1190 100 Church Street 1191 Enfield 1192 EN2 6BQ U.K. 1193 Email: steve.balls@metaswitch.com 1195 Xihua Fu, 1196 ZTE 1197 China 1198 fu.xihua@zte.com.cn 1200 Appendix A: Abbreviations & Terminology 1202 A.1 Abbreviations: 1204 CBR Constant Bit Rate 1205 GFP Generic Framing Procedure 1206 HO-ODU Higher Order ODU 1207 LSC Lambda Switch Capable 1208 LSP Label Switched Path 1209 LO-ODU Lower Order ODU 1210 ISCD Interface Switch Capability Descriptor 1211 OCC Optical Channel Carrier 1212 OCG Optical Carrier Group 1213 OCh Optical Channel (with full functionality) 1214 OChr Optical Channel (with reduced functionality) 1215 ODTUG Optical Date Tributary Unit Group 1216 ODU Optical Channel Data Unit 1217 OMS Optical Multiplex Section 1218 OMU Optical Multiplex Unit 1219 OPS Optical Physical Section 1220 OPU Optical Channel Payload Unit 1221 OSC Optical Supervisory Channel 1222 OTH Optical Transport Hierarchy 1223 OTM Optical Transport Module 1224 OTN Optical Transport Network 1225 OTS Optical Transmission Section 1226 OTU Optical Channel Transport Unit 1227 OTUkV Functionally Standardized OTUk 1228 SCSI Switch Capability Specific Information 1229 TDM Time Division Multiplex 1231 A.2 Terminology 1233 1. ODUk and ODUj 1235 ODUk refers to the ODU container that is directly mapped to an 1236 OTU container. ODUj refers to the lower order ODU container that 1237 is mapped to an higher order ODU container via multiplexing. 1239 2. LO-ODU and HO-ODU 1241 LO-ODU refers to the ODU client layer of lower rate that is mapped 1242 to an ODU server layer of higher rate via multiplexing. HO-ODU 1243 refers to the ODU server layer of higher rate that supports 1244 mapping of one or more ODU client layers of lower rate. 1246 In multi-stage multiplexing case, a given ODU layer can be a 1247 client for one stage (interpreted as LO-ODU) and at the same 1248 time server for another stage (interpreted as HO-ODU). In this 1249 case, the notion of LO-ODU and HO-ODU needs to be interpreted in a 1250 recursive manner. 1252 ODU0 | (LO-ODU) 1253 | | 1254 | | Stage #1 1255 V | 1256 (LO-ODU) | ODU1 | (HO-ODU) 1257 | | 1258 Stage #2 | | 1259 | V 1260 (HO-ODU) | ODU2 | (LO-ODU) 1261 | | 1262 | | Stage #3 1263 V | 1264 ODU3 | (HO-ODU) 1266 Figure-4 : LO-ODU and HO-ODU 1268 Appendix B : Optimization Techniques 1270 Optimization techniques can be used to reduce TE-LSA size. The following 1271 sub sections describe available options. 1273 B.1 Multiple ISCDs Vs. Single ISCD 1275 It is possible to encode ISCDs corresponding to different ODU layers 1276 into SCSI field of a single ISCD. This options was shown in previous 1277 version of this draft (draft-ashok-ccamp-gmpls-ospf-g709-02). 1279 Doing so will reduce the LSA size by a factor of: 1280 10 words x (#ODUjs - 1) 1282 It is possible to reduce LSA size further by reducing the size of BW field 1283 to half word. Doing so will reduce LSA size by a factor of: 1284 4 words x (#ODUjs) 1286 B.1 Multiple IMCDs Vs. Single IMCD 1288 This optimization doesn't save much. The shrinking of BW field to 1/2 word 1289 helps reduce LSA size to some extent. The size reduction depends on the number of ODUs supported. 1291 4 words x (#ODUjs) 1293 B.1 Eight priorities Vs. restricted number of priorities 1295 It is possible to further optimize by advertising BW only for supported 1296 priorities. This can be easily achieved by having a bit vector as described 1297 in previous version of this draft. 1299 Appendix C: Relation with MLN & MRN 1301 The ISCD and IMCDs defined in this draft doesn't repalce IACDs. 1302 All three (ISCD, IMCD & IACD) can co-exist in a network and 1303 serve different purposes. 1305 Appendix D : AMP, BMP & GMP Mapping 1307 The G.709 defines various mapping schemes for LO-ODUs into HO-ODUs. 1308 From G.709 descriptions, the AMP & GMP mapping appears to be fixed for 1309 a given LO-ODU to HO-ODU based on the time slot granularity. 1310 Since the mapping is fixed we do not see value in advertising this 1311 information in TE-LSAs.