idnits 2.17.1 draft-zihc-ccamp-otn-b100g-signalling-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G.709-2016]), 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 -- The document date (March 6, 2017) is 2608 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'G.709-2012' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'G.709.1' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'G.798' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'G.872-2012' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'G.872-2017' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC7062' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC7096' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 420, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Wang, Ed. 3 Internet-Draft ZTE 4 Intended status: Informational R. Valiveti 5 Expires: September 7, 2017 I. Hussain 6 R. Rao 7 Infinera Corp 8 H. Helvoort 9 Hai Gaoming B.V 10 Y. Xu 11 CAICT 12 March 6, 2017 14 GMPLS Signalling Extensions for control of B100G OTUCn/ODUCn Network 15 draft-zihc-ccamp-otn-b100g-signalling-00 17 Abstract 19 This document provides extensions to GMPLS signalling to control the 20 B100G OTUCn/ODUCn Network, as a result of the introduction of new 21 beyond 100G OTUCn/ODUCn signals in ITU-T Recommendation G.709 22 [G.709-2016]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 7, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Overview of the GMPLS Extensions for Support of OTUCn/ODUCn . 3 62 5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4 63 5.1. LSP Encoding Type . . . . . . . . . . . . . . . . . . . . 4 64 5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709 4 65 6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Label Format . . . . . . . . . . . . . . . . . . . . . . 5 67 6.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The 2016 version of G.709 [G.709-2016] introduces support for higher 78 rate OTU and ODU signals, termed OTUCn and ODUCn (which have a 79 nominal rate of 100n Gbps). The newly introduced OTUCn and ODUCn 80 represent a very powerful extension to the OTN capabilities, and one 81 which naturally scales to transport any newer clients with bit rates 82 in excess of 100G, as they are introduced. 84 B100G framework document [I-D.zih-ccamp-otn-b100g-fwk] provides a 85 framework to allow the development of protocol extensions to support 86 GMPLS control of OTN as specified in [G.709-2016]. Based on this 87 framework, this document provide Resource Reservation Protocol - 88 Traffic Engineering (RSVP-TE) extensions to support control of OTUCn/ 89 ODUCn introduced in [G.709-2016]. 91 Note: the RSVP-TE signalling extensions in this document will try to 92 reuse the extensions defined in RFC4328 [RFC4328] and RFC7139 93 [RFC7139]. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Terminology 103 OPUCn Optical Payload Unit-Cn 105 ODUCn Optical Data Unit-Cn 107 OTUCn completely standardized Optical Transport Unit-Cn 109 OTUCn-M Optical Transport Unit-Cn with n OxUC overhead instances and 110 M 5G tributary slots 112 OTUCn completely standardized Optical Transport Unit-Cn 114 4. Overview of the GMPLS Extensions for Support of OTUCn/ODUCn 116 New OTUCn/ODUCn are specified in [G.709-2016]. The corresponding new 117 Signal Types are defined below: 119 completely standardized Optical Transport Unit-Cn (OTUCn) 121 Optical Transport Unit-Cn with n OxUC overhead instances and M 5G 122 tributary slots (OTUCn-M) 124 Optical Data Unit-Cn (ODUCn) 126 A new tributary slot granularity (i.e., 5 Gbps) is described in 127 [G.709-2016]. But this kind of tributary slot (TS) can only be used 128 at ODUCn capable interfaces. 130 Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) 131 and ODUCn is not supported by [G.709-2016] any more. 133 The implementation of the OTUCn/ODUCn Signal which has been briefly 134 described in [I-D.zih-ccamp-otn-b100g-fwk] is achieved through the 135 bonding of FlexO interfaces, which can also be referred to as PHYs. 136 Higher rate OTUCn is split into n instances of OTUC at the FlexO 137 source nodes. One or more OTUC instances are associated with one 138 FlexO interface. Several end-to-end FlexO connections (PHYs) are 139 bonded together as one FlexO group to carry the OTUCn. The FlexO 140 layer are used as the server layer of the OTUCn signal. 142 5. Generalized Label Request 144 As desfined in RFC3471 [RFC3471], the Generalized Label Request 145 includes a common part (i.e., used for any switching technology) and 146 a technology dependent part (i.e., the traffic parameters). Both of 147 these two parts are extended in RFC4328 [RFC4328] and RFC7139 148 [RFC7139] to accommodate GMPLS Signalling to the G.709 transport 149 plane recommendation. 151 In this document, the LSP Encoding Type in the common part and the 152 traffic parameter in the technology dependent part are extended/ 153 refined to accommodate the G.709 Recommendation [G.709-2016]. The 154 other parts are not changed. 156 5.1. LSP Encoding Type 158 In [G.709-2016], the ODUCn is used as a high-order signal only. Only 159 other lower-rate (i.e. low-order) ODUs can be multiplexed into an 160 ODUCn signal; in other words, no non-OTN client signals can be 161 directly mapped to an ODUCn signal. 163 A new code-points for the LSP LSP Encoding Type is defined: 165 ================================================= 167 Value Type 168 ----- ---- 169 XX G.709 ODUCn (Digital Path) 171 ================================================= 173 Figure 1 175 5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709 177 Section 3.2 of RFC4328 [RFC4328] defines the initial traffic 178 parameters, and RFC7139 [RFC7139] extend the format by adding the 179 Bit_Rate field and deleting the NMC (Number of Multiplexed 180 Components). 182 This document refine the Traffic Parameter format defined in section 183 5 RFC7139 [RFC7139]. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Signal Type | n | Multiplier (MT) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Bit_Rate | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2 195 Signal Type: three new signal types (i.e., OTUCn, OTUCn-M, ODUCn) are 196 defined in this document. 198 n (8 bits): "n" is an positive integer and contained in "OTUCn/OTUCn- 199 M/ODUCn", and it can used to represent the bandwidth resource being 200 requested. Also "n" is equal to the number of the OTUC/ODUC/OPUC 201 instances. 203 NVC (Number of Virtual Components) defined in RFC7139 [RFC7139] is 204 not used any more, because virtual concatenation is not support in 205 the [G.709-2016]. 207 MT (Multiplexer): defined in section 3.2.4 of RFC4328 [RFC4328]. 209 Bit_Rate: defined in section 5 of RFC7139 [RFC7139]. 211 This Traffic Parameters for the OTN-TDM-capable Switching Type are 212 carried in the OTN-TDM SENDER_TSPEC object in the Path message and 213 the OTN-TDM FLOWSPEC object in the Resv message. 215 6. Generalized Label 217 This section defines the format of the OTUCn/OTUCn-M/ODUCn 218 Generalized Label. 220 6.1. Label Format 222 Following is the GENERALIZED_LABEL object format for OTUCn/OTUCn-M/ 223 ODUCn. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | TPN | IF Type | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |Bit Map of Available/Unavailable Slots | Resvd | NUS | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | ...... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |Bit Map of Available/Unavailable Slots | Resvd | NUS | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 3 239 This GENERALIZED_LABEL object is used to indicate how the ODU client 240 signal is multiplexed into the ODUCn link. Note that the LO OUDj 241 Signal Type is indicated by Traffic Parameters, while the type of 242 ODUCn link is identified by the bonding FlexO capable interfaces 243 carried in the IF_ID RSVP_HOP object. 245 TPN: defined in section 6.1 of RFC7139 [RFC7139]. 247 IF (Interface) Type (8 bits): indicate the interface type of the port 248 that provide support for OTUCn/OTUCn-M/ODUCn, which can be 249 100G/200G/400G Ethernet PHY interfaces. 251 Length (12 bits): indicates the number of bits of the Bit Map field. 252 This field can also be used to indicate the number of the OTUC/ODUC 253 instances being requested. For example, the number of OTUC/ODUC 254 instances can be derived through the length number divided by 4. 256 Bit Map of Available/Unavailable Slots: when the label is used to set 257 up OTUCn-M path, this field is used to represent the position of 258 unavailable slots, when the label is used to set up ODUCn path, this 259 field is used to represent the slots resource allocated for client. 261 NUS (Number of Unavailable Slots): indicate the number of unavailable 262 slots. 264 This GENERALIZED_LABEL object contains several label blocks, with 265 each block correspond to one OTUC instance. 267 Compatibility: actually, there will be different FlexO interfaces 268 used for carrying OTUCn signal, and the length of the bit map may be 269 different. The label format defined in this document can only 270 support the 100G interface. If the label format is used in the case 271 of 200G/400G interfaces, the bit map field can be extended to 272 accommodate the slots number. Besides this, byte alignment also 273 needs to be taken into consideration. 275 6.2. Procedures 277 This section does not change the procedure of RSVP-TE protocol 278 described in section 6.2 of RFC7139 [RFC7139], like birdirectional 279 LSP, LABEL_SET object, except the process procedure at the node. 281 When a downstream node or egress node receives a Path message 282 containing a GENERALIZED_LABEL_REQUEST object for setting up an 283 ODUflex LSP over an ODUCn connection from its upstream neighbor node. 284 The node need to check if there are n Ethernet PHYs (FlexO capable) 285 available for transport ODUflex LSP. 287 When an upstream node receives a Resv message containing a 288 GENERALIZED_LABEL object, it MUST first identify which ODU Signal 289 Type is multiplexed or mapped into which ODU Signal Type according to 290 the Traffic Parameters and the IF_ID RSVP_HOP object in the received 291 message. The IF_ID RSVP_HOP object contains several TLVs, and each 292 of them has an one-to-one relationship with one label block. In 293 another word, which component FlexO interface is used to carry a 294 specific OTUC instance needs to be explicitly specified. 296 In the case of ODUCn-to-OTUCn mapping, the TPN field MUST be set 297 to 0. Bit Map information is not required and MUST NOT be 298 included, so the Length field MUST be set to 0 as well. The NUS 299 field should be set to 0. 301 In the case of ODUCn-to-OTUCn-M mapping, the NUS field is set to 302 indicate the number of unavailable in this connection, and the 303 postions of these slots are indicated by the Bit map field. 304 Unavailable slots can not be assigned to ODUCn. This information 305 is required when provide resource for ODUCn client signal. 307 In the case of ODU Client-to-ODUCn multiplexing, the node MUST 308 retrieve the reserved tributary slots in the ODUCn by its 309 downstream neighbor node according to the position of the bits 310 that are set to 1 in the Bit Map field. The TS granularity is 5G, 311 so that the node can multiplex the ODU Client into the ODUCn based 312 on the TS granularity. The node MUST also retrieve the TPN value 313 assigned by its downstream neighbor node from the label and fill 314 the TPN into the related MSI byte(s) in the OPUCn overhead in the 315 data plane. 317 A new LSP_ATTRIBUTE object needs to be extended to collect the number 318 and position of the unavailable slots at each link in the connection, 319 so the destination node can compute a proper label. 321 When PCE is involved, an ERO can be used to indicate the nodes and 322 ports passed according to the resouce information at each nodes and 323 ports. Thus the LSP_ATTRIBUTE object used to collect unavailable 324 slots information are not needed any more. 326 7. Security Considerations 328 TBD 330 8. IANA Considerations 332 The signal types documented in this draft needs to be allocate by 333 IANA. 335 9. References 337 9.1. Normative References 339 [G.709-2012] 340 ITU, "Optical Transport Network Interfaces", 341 ITU Recommendation G.709, February 2012, 342 . 344 [G.709-2016] 345 ITU, "Optical Transport Network Interfaces", 346 ITU Recommendation G.709, July 2016, 347 . 349 [G.709.1] ITU, "Flexible OTN short-reach interface", 350 ITU Recommendation G.709.1, October 2016. 352 [G.798] ITU, "Characteristics of optical transport network 353 hierarchy equipment functional blocks", ITU Recommendation 354 G.798, February 2014, 355 . 357 [G.872-2012] 358 ITU, "The Architecture of Optical Transport Networks", 359 ITU Recommendation G.872, October 2012, 360 . 362 [G.872-2017] 363 ITU, "The Architecture of Optical Transport Networks", 364 ITU Recommendation G.872, October 2012, 365 . 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 373 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 374 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 375 . 377 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 378 Switching (GMPLS) Signaling Functional Description", 379 RFC 3471, DOI 10.17487/RFC3471, January 2003, 380 . 382 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 383 Switching (GMPLS) Signaling Resource ReserVation Protocol- 384 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 385 DOI 10.17487/RFC3473, January 2003, 386 . 388 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 389 Switching (GMPLS) Signaling Extensions for G.709 Optical 390 Transport Networks Control", RFC 4328, 391 DOI 10.17487/RFC4328, January 2006, 392 . 394 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 395 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 396 Optical Transport Networks", RFC 7062, 397 DOI 10.17487/RFC7062, November 2013, 398 . 400 [RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., 401 Caviglia, D., Zhang, F., and D. Li, "Evaluation of 402 Existing GMPLS Encoding against G.709v3 Optical Transport 403 Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January 404 2014, . 406 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 407 and K. Pithewan, "GMPLS Signaling Extensions for Control 408 of Evolving G.709 Optical Transport Networks", RFC 7139, 409 DOI 10.17487/RFC7139, March 2014, 410 . 412 9.2. Informative References 414 [I-D.zih-ccamp-otn-b100g-fwk] 415 Wang, Q., Zhang, Y., Valiveti, R., Hussain, I., Rao, R., 416 and H. Helvoort, "GMPLS Routing and Signaling Framework 417 for B100G", draft-zih-ccamp-otn-b100g-fwk-00 (work in 418 progress), February 2017. 420 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 421 Switching (GMPLS) Architecture", RFC 3945, 422 DOI 10.17487/RFC3945, October 2004, 423 . 425 Authors' Addresses 427 Qilei Wang (editor) 428 ZTE 429 Nanjing 430 CN 432 Email: wang.qilei@zte.com.cn 434 Radha Valiveti 435 Infinera Corp 436 169 Java Drive 437 Sunnyvale, CA 94089 438 USA 440 Email: rvaliveti@infinera.com 442 Iftekhar Hussain 443 Infinera Corp 444 169 Java Drive 445 Sunnyvale, CA 94089 446 USA 448 Email: IHussain@infinera.com 450 Rajan Rao 451 Infinera Corp 452 169 Java Drive 453 Sunnyvale, CA 94089 454 USA 456 Email: rrao@infinera.com 457 Huub van Helvoort 458 Hai Gaoming B.V 460 Email: huubatwork@gmail.com 462 Yunbin Xu 463 CAICT 464 Beijing 465 CN 467 Email: xuyunbin@ritt.cn