idnits 2.17.1 draft-zhang-ccamp-gmpls-evolving-g709-05.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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - In case of ODUj mapped into OTUk (j=k), the TPN is not needed and this object SHOULD not appear in the RSVP-TE message. -- The document date (July 9, 2010) is 5040 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: 'G.709-V3' is mentioned on line 163, but not defined == Missing Reference: 'RFC4606' is mentioned on line 349, but not defined == Unused Reference: 'G709-V2' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'G798-V2' is defined on line 798, but no explicit reference was found in the text -- No information found for draft-zhang-ccamp-gmpls-g - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OTN-LMP' Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Huawei 3 Category: Standards Track Guoying Zhang 4 CATR 5 Sergio Belotti 6 Alcatel-Lucent 7 D. Ceccarelli 8 Ericsson 9 Expires: January 2011 July 9, 2010 11 Generalized Multi-Protocol Label Switching (GMPLS) Signaling 12 Extensions for the evolving G.709 Optical Transport Networks Control 14 draft-zhang-ccamp-gmpls-evolving-g709-05.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 9, 2011. 39 Abstract 41 Recent progress in ITU-T Recommendation G.709 standardization has 42 introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and 43 enhanced Optical Transport Networking (OTN) flexibility. Several 44 recent documents have proposed ways to modify GMPLS signaling 45 protocols to support these new OTN features. 47 It is important that a single solution is developed for use in GMPLS 48 signaling and routing protocols. This solution must support ODUk 49 multiplexing capabilities, address all of the new features, be 50 acceptable to all equipment vendors, and be extensible considering 51 continued OTN evolution. 53 This document describes the extensions to the Generalized Multi- 54 Protocol Label Switching (GMPLS) signaling to control the evolving 55 Optical Transport Networks (OTN) addressing ODUk multiplexing and new 56 features including ODU0, ODU4, ODU2e and ODUflex. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 Table of Contents 66 1. Introduction..................................................3 67 2. Terminology...................................................4 68 3. GMPLS Extensions for the Evolving G.709 - Overview............4 69 4. Extensions for Traffic Parameters for the Evolving G.709......5 70 4.1. Usage of ODUflex Traffic Parameter.......................6 71 4.2. Example of ODUflex Traffic Parameter.....................7 72 5. Generalized Label.............................................8 73 5.1. New definition of ODUk Label.............................9 74 5.2. Examples................................................10 75 5.3. Label Distribution Procedure............................12 76 5.4. Backward Compatibility Considerations...................13 77 5.4.1. Control Plane Backward Compatibility Considerations13 78 5.4.2. Data Plane Backward Compatibility Considerations...14 79 6. Tributary Port Number Assignment.............................15 80 6.1. TPN Object..............................................15 81 6.2. Procedure of TPN Assignment.............................16 82 6.2.1. Downstream Node Assignment by Control Plane........16 83 6.2.2. Upstream Node Assignment by Control Plane..........16 84 6.3. Collision Management....................................17 85 7. Security Considerations......................................17 86 8. IANA Considerations..........................................17 87 9. References...................................................18 88 9.1. Normative References....................................18 89 9.2. Informative References..................................19 91 10. Authors' Addresses..........................................19 92 Acknowledgment..................................................21 94 1. Introduction 96 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 97 MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplex 98 (e.g., SONET/SDH, PDH, and ODU), Wavelength (OCh, Lambdas) Switching, 99 and Spatial Switching (e.g., incoming port or fiber to outgoing port 100 or fiber). [RFC3471] presents a functional description of the 101 extensions to Multi-Protocol Label Switching (MPLS) signaling 102 required to support Generalized MPLS. RSVP-TE-specific formats and 103 mechanisms and technology specific details are defined in [RFC3473]. 105 With the evolution and deployment of G.709 technology, it is 106 necessary that appropriate enhanced control technology support be 107 provided for G.709. [RFC4328] describes the control technology 108 details that are specific to foundation G.709 Optical Transport 109 Networks (OTN), as specified in the ITU-T Recommendation G.709[G709- 110 V1], for ODUk deployments without multiplexing. 112 In addition to increasing need to support ODUk multiplexing, the 113 evolution of OTN has introduced additional containers and new 114 flexibility. For example, ODU0, ODU2e, ODU4 containers and ODUflex 115 are developed in [G709-V3]. 117 In addition, the following issues require consideration: 119 - Support for hitless adjustment of ODUflex, which is to be 120 specified in ITU-T G.hao. 122 - Support for Tributary Port Number. The Tributary Port Number 123 has to be negotiated on each link for flexible assignment of 124 tributary ports to tributary slots in case of LO-ODU over HO- 125 ODU (e.g., ODU2 into ODU3). 127 Therefore, it is clear that [RFC4328] has to be updated or superceded 128 in order to support ODUk multiplexing, as well as other ODU 129 enhancements introduced by evolution of OTN standards. 131 This document updates RFC4328 extending the G.709 ODUk traffic 132 parameters and also presents a new OTN label format which is very 133 flexible and scalable. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. GMPLS Extensions for the Evolving G.709 - Overview 143 New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4 144 and ODUflex containers are specified in [G709-V3]. The corresponding 145 new signal types are summarized below: 147 - Optical Channel Transport Unit (OTUk): 148 . OTU4 150 - Optical Channel Data Unit (ODUk): 151 . ODU0 152 . ODU2e 153 . ODU4 154 . ODUflex 156 A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is also 157 described in [G709-V3]. Thus, there are now two TS granularities for 158 the foundation OTN ODU1, ODU2 and ODU3 containers. The TS granularity 159 at 2.5 Gbps is used on legacy interfaces while the new 1.25 Gbps will 160 be used for the new interfaces. 162 In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 4), 163 the evolving OTN [G.709-V3] encompasses the multiplexing of ODUj (j = 164 0, 1, 2, 2e, 3, flex) into an ODUk (k > j) as follows: 166 - ODU0 into ODU1 multiplexing (with 1.25Gbps TS granularity) 168 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 169 granularity) 171 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 173 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing 174 (with 1.25Gbps TS granularity) 176 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 178 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 179 multiplexing (with 1.25Gbps TS granularity) 181 [RFC4328] describes GMPLS signaling extensions to support the control 182 for G.709 Optical Transport Networks (OTN) [G709-V1]. However, 183 [RFC4328] needs to be updated because it does not provide the means 184 to signal all the new signal types and related mapping and 185 multiplexing functionalities. Moreover, it supports only the 186 deprecated auto-MSI mode which assumes that the Tributary Port Number 187 is automatically assigned in the transmit direction and not checked 188 in the receive direction. 190 This document extends the G.709 traffic parameters described in 191 [RFC4328] and presents a new OTN label format which is very flexible 192 and scalable. Additionally, procedures about Tributary Port Number 193 assignment through control plane are also provided in this document. 195 4. Extensions for Traffic Parameters for the Evolving G.709 197 The traffic parameters for G.709 are defined as follows: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Signal Type | Tolerance | NMC | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | NVC | Multiplier (MT) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Bit_Rate | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 The Signal Type should be extended to cover the new Signal Type 210 introduced by the evolving OTN. The new Signal Type is extended as 211 follows: 213 Value Type 214 ----- ---- 215 0 Not significant 216 1 ODU1 (i.e., 2.5 Gbps) 217 2 ODU2 (i.e., 10 Gbps) 218 3 ODU3 (i.e., 40 Gbps) 219 4 ODU4 (i.e., 100 Gbps) 220 5 Reserved (for future use) 221 6 OCh at 2.5 Gbps 222 7 OCh at 10 Gbps 223 8 OCh at 40 Gbps 224 9 OCh at 100 Gbps 225 10~19 Reserved (for future use) 226 20 ODU0 (i.e., 1.25 Gbps) 227 21~30 Reserved (for future use) 228 31 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 229 32 ODUflex (i.e., 1.25*N Gbps) 230 33~255 Reserved (for future use) 232 In case of ODUflex(CBR), the Bit_Rate and Tolerance fields are used 233 together to represent the actual bandwidth of ODUflex, where: 235 - The Bit_Rate field indicates the nominal bit rate of ODUflex(CBR) 236 encoded as a 32-bit IEEE single-precision floating-point number 237 (referring to [RFC4506] and [IEEE]). 239 - The Tolerance field indicates the bit rate tolerance (part per 240 million, ppm) of the ODUflex(CBR) encoded as an unsigned integer. 242 For example, for an ODUflex(CBR) service with Bit_Rate = 2.5Gbps and 243 Tolerance = 50ppm, the actual bandwidth of the ODUflex is: 245 2.5Gbps * (1 - 50ppm) ~ 2.5Gbps * (1 + 50ppm) 247 In case of other ODUk signal types, the Bit_Rate and Tolerance fields 248 are not necessary and MUST be filled with 0. 250 4.1. Usage of ODUflex Traffic Parameter 252 In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in 253 the ODUflex traffic parameter is used to determine the total number 254 of tributary slots N in the HO ODUk link to be reserved. Here: 256 N = Ceiling of 258 ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) 259 --------------------------------------------------------------------- 260 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 262 Therefore, a node receiving a Path message containing ODUflex(CBR) 263 traffic parameter can allocate precise number of tributary slots and 264 set up the cross-connection for the ODUflex service. 266 The table below shows the actual bandwidth of the tributary slot of 267 ODUk (in Gbps), referring to [G709-V3]. 269 ODUk Minimum Nominal Maximum 270 ------------------------------------------------------- 271 ODU2 1.249 384 632 1.249 409 620 1.249 434 608 272 ODU3 1.254 678 635 1.254 703 729 1.254 728 823 273 ODU4 1.301 683 217 1.301 709 251 1.301 735 285 275 Note that: 277 Minimum bandwidth of ODUTk.ts = 278 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 280 Maximum bandwidth of ODTUk.ts = 281 ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) 283 Where: HO OPUk bit rate tolerance = 20ppm 285 For different ODUk, the bandwidths of the tributary slot are 286 different, and so the total number of tributary slots to be reserved 287 for the ODUflex(CBR) may not be the same on different HO ODUk links. 288 This is why the traffic parameter should bring the actual bandwidth 289 information other than the NMC field. 291 [Editors note] In case of ODUflex(GFP), the calculation of the total 292 number of tributary slots to be reserved along the path is now under 293 discussion in ITU-T. Therefore, the traffic parameters for 294 ODUflex(GFP) is for further study. 296 4.2. Example of ODUflex Traffic Parameter 298 This section gives an example to illustrate the usage of ODUflex(CBR) 299 traffic parameter. 301 Assume there is an ODUflex(CBR) service requesting a bandwidth of 302 (2.5Gbps, +/-20ppm) from node A to node C. In other words, the 303 ODUflex traffic parameter indicates that Signal Type is 32 (ODUflex), 304 Bit_Rate is 2.5Gbps and Tolerance is 20ppm. 306 +-----+ +---------+ +-----+ 307 | +-------------+ +-----+ +-------------+ | 308 | ===============\| ODU |/=============== | 309 | ===============/| flex+-=============== | 310 | +-------------+ | |\=============== | 311 | +-------------+ +-----+ +-------------+ | 312 | | | | | | 313 | | ....... | | ....... | | 314 | A +-------------+ B +-------------+ C | 315 +-----+ HO ODU4 +---------+ HO ODU2 +-----+ 317 =========: TS occupied by ODUflex 318 ---------: free TS 320 - On the HO ODU4 link between node A and B: 322 The maximum bandwidth of the ODUflex equals 2.5Gbps * (1 + 20ppm), 323 and the minimum bandwidth of the tributary slot of ODU4 equals 324 1.301 683 217Gbps, so the total number of tributary slots N1 to 325 be reserved on this link is: 327 N1 = ceiling (2.5Gbps * (1 + 20ppm) / 1.301 683 217) = 2 329 - On the HO ODU2 link between node B and C: 331 The maximum bandwidth of the ODUflex equals 2.5Gbps * (1 + 20ppm), 332 and the minimum bandwidth of the tributary slot of ODU2 equals 333 1.249 384 632Gbps, so the total number of tributary slots N2 to 334 be reserved on this link is: 336 N2 = ceiling (2.5Gbps * (1 + 20ppm) / 1.249 384 632) = 3 338 5. Generalized Label 340 [RFC3471] has defined the Generalized Label which extends the 341 traditional label by allowing the representation of not only labels 342 which travel in-band with associated data packets, but also labels 343 which identify time-slots, wavelengths, or space division multiplexed 344 positions. The format of the corresponding RSVP-TE Generalized Label 345 object is defined in the Section 2.3 of [RFC3473]. 347 However, for different technologies, we usually need use specific 348 label rather than the Generalized Label. For example, the label 349 format described in [RFC4606] could be used for SDH/SONET, the label 350 format in [RFC4328] for G.709. 352 According to the ODUk label format defined in [RFC4328], it could be 353 updated to support new signal types defined in [G709-V3] but would 354 hardly be further enhanced to support possible new signal types. 355 Furthermore such label format can face large problems related to 356 scalability issues due to the high number of labels needed. For 357 example, when ODU3 is mapped into ODU4 with 1.25G tributary slots, it 358 will need thirty-one labels (31*4*8=992 bits) to be allocated for one 359 ODU3 connection. For ODUflex into ODU4, it may need up to eighty 360 labels (80*4*8=2560 bits) to be allocated for one ODUflex connection. 362 In this document, a new ODUk label format is defined. The new ODUk 363 label format is very flexible and scalable. 365 5.1. New definition of ODUk Label 367 In order to be compatible with new types of ODU signal and new types 368 of tributary slot, the following new ODUk label format is defined: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | ODUj |OD(T)Uk| T | Reserved | Bit Map | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | ......... | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 ODUj and OD(T)Uk (4 bits respectively): indicate that LO ODUj is 379 multiplexed into HO ODUk(k>j), or LO ODUj is mapped into OTUk (j=k). 381 ODUj field Signal type 382 ---------- ----------- 383 0 LO ODU0 384 1 LO ODU1 385 2 LO ODU2 386 3 LO ODU3 387 4 LO ODU4 388 5 LO ODU2e 389 6 LO ODUflex 390 7-15 Reserved (for future use) 392 OD(T)Uk field Signal type 393 ------------- ----------- 394 0 Reserved (for future use) 395 1 HO ODU1 / OTU1 396 2 HO ODU2 / OTU2 397 3 HO ODU3 / OTU3 398 4 HO ODU4 / OTU4 399 5-15 Reserved (for future use) 401 T (2 bits): indicates the type of tributary slot of HO ODUk. 402 Currently, two types of tributary slot are defined in [G709-V3], the 403 1.25Gbps tributary slot and the 2.5Gbps tributary slot. 405 T field TS type 406 ------- ------- 407 0 1.25Gbps TS granularity 408 1 2.5Gbps TS granularity 409 2-3 Reserved (for future use) 411 Bit Map (variable): indicates which tributary slots in HO ODUk that 412 the LO ODUj will be multiplexed into. The sequence of the Bit Map is 413 consistent with the sequence of the tributary slots in HO ODUk. Each 414 bit in the bit map represents the corresponding tributary slot in HO 415 ODUk with a value of 1 or 0 indicating whether the tributary slot 416 will be used by LO ODUj or not. 418 The size of the bit map equals to the total number of the tributary 419 slots of HO ODUk. 421 In case of an ODUk mapped into OTUk, it's no need to indicate which 422 tributary slots will be used, so the size of Bit Map is 0. 424 Padded bits are added behind the Bit Map to make the whole label a 425 multiple of four bytes if necessary. Padded bit MUST be set to 0 and 426 MUST be ignored. 428 5.2. Examples 430 The following examples are given in order to illustrate the label 431 format described in the previous sections of this document. 433 (1) ODUk into OTUk mapping: 435 In such conditions, the downstream node along an LSP returns a label 436 indicating that the ODU1 (ODU2 or ODU3 or ODU4) is directly mapped 437 into the corresponding OTU1 (OTU2 or OTU3 or ODU4). The following 438 example label indicates an ODU1 mapped into OTU1. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |0 0 0 1|0 0 0 1|0 1| Reserved | Padded Bits (0) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 (2) ODUj into ODUk multiplexing: 448 In such conditions, this label indicates that an ODUj is multiplexed 449 into several tributary slots of OPUk and then mapped into OTUk. Some 450 instances are shown as follow: 452 - ODU0 into ODU2 Multiplexing: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |0 0 0 0|0 0 1 0|0 0| Reserved |0 1 0 0 0 0 0 0|Padded Bits (0)| 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 This above label indicates an ODU0 multiplexed into the second 461 tributary slot of ODU2, wherein the type of the tributary slot is 462 1.25Gbps. 464 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |0 0 0 1|0 0 1 0|0 0| Reserved |0 1 0 1 0 0 0 0|Padded Bits (0)| 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 This above label indicates an ODU1 multiplexed into the 2nd and the 473 4th tributary slot of ODU2, wherein the type of the tributary slot is 474 1.25Gbps. 476 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |0 0 1 0|0 0 1 1|0 1| Reserved |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 484 and 7th tributary slot of ODU3, wherein the type of the tributary 485 slot is 2.5Gbps. 487 5.3. Label Distribution Procedure 489 This document does not change the existing label distribution 490 procedures [RFC4328] for GMPLS except that the new ODUk label should 491 be processed as follows. 493 When a node receives a generalized label request for setting up an 494 ODUj LSP from its upstream neighbor node, the node should generate an 495 ODU label according to the signal type of the requested LSP and the 496 free resources (i.e., free tributary slots of ODUk) that will be 497 reserved for the LSP, and send the label to its upstream neighbor 498 node. Note that these labels can also be specified by the source node 499 of the connection. 501 In case of ODUj to ODUk multiplexing, the node should firstly 502 determine the size of the Bit Map field according to the signal type 503 and the tributary slot type of ODUk, and then set the bits to 1 in 504 the Bit Map field corresponding to the reserved tributary slots. 506 In case of ODUk to OTUk mapping, the node only needs to fill the ODUj 507 and the ODUk fields with corresponding values in the label. Other 508 bits are reserved and MUST be set to 0. 510 When receiving an ODU label from its downstream neighbor node, the 511 node should learn which ODU signal type is multiplexed or mapped into 512 which ODU signal type by analyzing the ODUj and the ODUk fields. 514 In case of ODUj to ODUk multiplexing, the node should firstly 515 determine the size of the Bit Map field according to the signal type 516 and the tributary slot type of ODUk, and then obtain which tributary 517 slots in ODUk are reserved by its downstream neighbor node according 518 to the position of the bits that are set to 1 in the Bit Map field, 519 so that the node can multiplex the ODUj into the reserved tributary 520 slots of ODUk after the LSP is established. 522 In case of ODUk to OTUk mapping, the size of Bit Map field is 0 and 523 no additional procedure is needed. 525 5.4. Backward Compatibility Considerations 527 5.4.1. Control Plane Backward Compatibility Considerations 529 Since the [RFC4328] has been deployed in the network for the nodes 530 that support [G709-V1] (herein we call them "legacy nodes"), backward 531 compatibility SHOULD be taken into consideration when the new nodes 532 (i.e., nodes that support [G709-V3]) and the legacy nodes are 533 interworking. 535 For backward compatibility consideration, the new node SHOULD have 536 the ability to generate and parse legacy labels. 538 o For the legacy node, it always generates and sends legacy label to 539 its upstream node, no matter the upstream node is new or legacy, 540 as described in [RFC4328]. 542 o For the new node, it will generate and send legacy label if its 543 upstream node is a legacy one, and generate and send new label if 544 its upstream node is a new one. 546 One backwards compatibility example is shown below: 548 Path Path Path Path 549 +-----+ ----> +-----+ ----> +------+ ----> +------+ ----> +-----+ 550 | | | | | | | | | | 551 | A +-------+ B +-------+ C +-------+ D +-------+ E | 552 | new | | new | |legacy| |legacy| | new | 553 +-----+ <---- +-----+ <---- +------+ <---- +------+ <---- +-----+ 554 Resv Resv Resv Resv 555 (new label) (legacy label) (legacy label) (legacy label) 557 As described above, for backward compatibility considerations, it is 558 necessary for a new node to know whether the neighbor node is new or 559 legacy. 561 One optional method is manual configuration. But it is recommended to 562 use LMP to discover the capability of the neighbor node automatically, 563 as described in [OTN-LMP]. 565 When performing the HO ODU link capability negotiation: 567 o If the neighbor node only support the 2.5Gbps TS and only support 568 ODU1/ODU2/ODU3, the neighbor node should be treated as a legacy 569 node. 571 o If the neighbor node can support the 1.25Gbps TS, or can support 572 other LO ODU types defined in [G709-V3]), the neighbor node should 573 be treated as new node. 575 o If the neighbor node returns a LinkSummaryNack message including 576 an ERROR_CODE indicating nonsupport of HO ODU link capability 577 negotiation, the neighbor node should be treated as a legacy node. 579 5.4.2. Data Plane Backward Compatibility Considerations 581 As described in chapter 3.1 and 4.1 of [OTN-LMP], the node supporting 582 1.25Gbps TS can interwork with the other nodes that supporting 583 2.5Gbps TS by combining Specific TSs together in data plane. The 584 control plane MUST support this TS combination. 586 Take the following figure as an example. Assume that there is an ODU2 587 link between node A and B, where node A only supports the 2.5Gbps TS 588 while node B supports the 1.25Gbps TS. In this case, the TS#i and 589 TS#i+4 (where i<=4) of node B are combined together. When creating an 590 ODU1 service in this ODU2 link, node B reserves the TS#i and TS#i+4 591 with the granularity of 1.25Gbps. But in the label sent from B to A, 592 it is indicated that the TS#i with the granularity of 2.5Gbps is 593 reserved. 595 Path 596 +----------+ ------------> +----------+ 597 | TS1==|===========\--------+--TS1 | 598 | TS2==|=========\--\-------+--TS2 | 599 | TS3==|=======\--\--\------+--TS3 | 600 | TS4==|=====\--\--\--\-----+--TS4 | 601 | | \ \ \ \----+--TS5 | 602 | | \ \ \------+--TS6 | 603 | | \ \--------+--TS7 | 604 | | \----------+--TS8 | 605 +----------+ <------------ +----------+ 606 node A Resv node B 608 In the contrary direction, when receiving a label from node A 609 indicating that the TS#i with the granularity of 2.5Gbps is reserved, 610 node B will reserved the TS#i and TS#i+4 with the granularity of 611 1.25Gbps in its control plane. 613 6. Tributary Port Number Assignment 615 As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk 616 frame contains n (n = the total number of TSs of the ODUk) MSI 617 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 618 each of which is used to indicate the multiplex structure of one TS, 619 respectively. 621 When an LO ODUj is multiplexed into HO ODUk occupying one or more TSs, 622 a Tributary Port Number (TPN) is configured at the two end of the HO 623 ODUk link and is put into the related MSI byte(s) in the OPUk 624 overhead at the (traffic) ingress end of the link, so that the other 625 end of the link can learn which TS(s) is/are used by the LO ODUj in 626 the data plane. 628 For HO ODU2 or ODU3 link, the TPN value (6 bits) MUST be different 629 from each other for one type of LO ODU. For HO ODU4 link, the TPN 630 value (7 bits) MUST be different from each other for all types of LO 631 ODUj. 633 TPN needs to be assigned by management plane or control plane. For 634 the latter case, the RSVP-TE signaling is necessary to be extended to 635 support the TPN assignment function. 637 6.1. TPN Object 639 A new TPN object is introduced in the PATH and RESV message to 640 support TPN assignment. The TPN object is optional and has the 641 following format: 643 TPN Class-Num = xx (TBD), C_Type = 1 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 |D| Reserved | TPN | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 D (Downstream Assignment) (1 bit): indicates which node to assign the 652 TPN. When set, the TPN is assigned by the downstream node; when 653 cleared, the TPN is assigned by the upstream node. 655 TPN (16 bits): indicates the Tributary Port Number for the assigned 656 Tributary Slot(s). 658 - In case of LO ODUj multiplexed into HO ODU1/ODU2/ODU3, only the 659 lower 6 bits of TPN field is significant and the other bits of 660 TPN MUST be set to 0. 662 - In case of LO ODUj multiplexed into HO ODU4, only the lower 7 663 bits of TPN field is significant and the other bits of TPN MUST 664 be set to 0. 666 - In case of ODUj mapped into OTUk (j=k), the TPN is not needed 667 and this object SHOULD not appear in the RSVP-TE message. 669 6.2. Procedure of TPN Assignment 671 Since the TPN is not needed in case of ODU mapping, the following 672 sub-sessions are only applicable for the ODU multiplexing cases. 674 6.2.1. Downstream Node Assignment by Control Plane 676 In this case, the upstream node sends a PATH message, which contains 677 a TPN Object with the D bit set to 1, to its downstream neighbor node 678 to request creation of LO ODUj. The TPN field in this object is set 679 to 0 and MUST be ignored. 681 On receiving the PATH massage, the downstream neighbor node performs 682 a normal tributary slot selection and reservation in the selected HO 683 ODUk link. After that, the downstream node assigns a valid TPN, which 684 does not collided with other TPN value used by existing LO ODU 685 connections in the selected HO ODU link and configures the expected 686 multiplex structure identifier (ExMSI) using this TPN. Then, the 687 assigned TPN is filled into the TPN Object and sent to the upstream 688 neighbor node via the RESV message. 690 The upstream node, when receiving the RESV message, gets the TPN 691 assigned by its downstream neighbor node and fills the TPN into the 692 related MSI byte(s) in the OPUk overhead in the data plane, so that 693 the downstream neighbor node can check whether the TPN received from 694 the data plane is consistent with the ExMSI and determine whether 695 there is any mismatch defect. 697 6.2.2. Upstream Node Assignment by Control Plane 699 In this case, the upstream node performs a normal tributary slot 700 selection and reservation in the selected HO ODUk link for LO ODUj, 701 and then assigns a valid TPN, which does not collided with other TPN 702 value used by existing LO ODU connections in the selected HO ODU link, 703 for the reserved tributary slot(s). 705 Then, the upstream node sends a PATH message, which contains the 706 assigned TPN value in the TPN Object (D = 0) and contains the 707 selected tributary slots information (e.g., via the existing 708 LABEL_SET Object), to its downstream neighbor node to request 709 creation of LO ODUj. 711 The downstream neighbor node, based on the received tributary slots 712 information and the TPN value, configures the ExMSI in the data plane, 713 so that the data plane MSI procedure can be performed, as described 714 in the previous sub-session. 716 6.3. Collision Management 718 [Editors note] This chapter should indicate the procedure in case of 719 collision between Tributary Port Numbers and/or Tributary Slots e.g. 720 two different LSP setups may choose a disjoint set of Tributary Slots 721 but they may request the same Tributary Port Number value (same MSI 722 in G.709 OPUk field). 724 In this case the first signaling should be successful and the second 725 one must fail. 727 7. Security Considerations 729 This document introduces no new security considerations to the 730 existing GMPLS signaling protocols. Referring to [RFC3473], further 731 details of the specific security measures are provided. Additionally, 732 [GMPLS-SEC] provides an overview of security vulnerabilities and 733 protection mechanisms for the GMPLS control plane. 735 8. IANA Considerations 737 - TPN Object: 739 A new value is needed to be defined by IANA for this document: 741 o TPN Object (Session 6): Class-Num = xx (TBD), C-Type = 1 743 - G.709 SENDER_TSPEC and FLOWSPEC objects: 745 The traffic parameters, which are carried in the G.709 746 SENDER_TSPEC and FLOWSPEC objects, do not require any new object 747 class and type based on [RFC4328]: 749 o G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 [RFC4328] 751 o G.709 FLOWSPEC Object: Class = 9, C-Type = 5 [RFC4328] 753 - Generalized Label Object: 755 The new defined ODU label (session 5) is a kind of generalized 756 label. Therefore, the Class-Num and C-Type of the ODU label is 757 the same as that of generalized label described in [RFC3473], 758 i.e., Class-Num = 16, C-Type = 2. 760 9. References 762 9.1. Normative References 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 768 Switching (GMPLS) Signaling Extensions for G.709 Optical 769 Transport Networks Control", RFC 4328, Jan 2006. 771 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 772 Switching (GMPLS) Signaling Functional Description", RFC 773 3471, January 2003. 775 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 776 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 777 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 779 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 780 (GMPLS) Architecture", RFC 3945, October 2004. 782 [OTN-LMP] Fatai Zhang, Ed., "Link Management Protocol (LMP) 783 extensions for G.709 Optical Transport Networks", draft- 784 zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt, Oct 21, 2009. 786 9.2. Informative References 788 [G709-V1] ITU-T, "Interface for the Optical Transport Network (OTN)," 789 G.709 Recommendation (and Amendment 1), February 2001 790 (November 2001). 792 [G709-V2] ITU-T, "Interface for the Optical Transport Network (OTN)," 793 G.709 Recommendation, March 2003. 795 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network (OTN) 796 ", G.709/Y.1331, December 2009. 798 [G798-V2] ITU-T, "Characteristics of optical transport network 799 hierarchy equipment functional blocks", G.798, December 800 2006. 802 [G798-V3] ITU-T, "Characteristics of optical transport network 803 hierarchy equipment functional blocks", G.798v3, consented 804 June 2010. 806 [RFC4506] M. Eisler, Ed., "XDR: External Data Representation 807 Standard", RFC 4506, May 2006. 809 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 810 ANSI/IEEE Standard 754-1985, Institute of Electrical and 811 Electronics Engineers, August 1985. 813 [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS 814 Networks", Work in Progress, October 2009. 816 10. Authors' Addresses 818 Fatai Zhang 819 Huawei Technologies 820 F3-5-B R&D Center, Huawei Base 821 Bantian, Longgang District 822 Shenzhen 518129 P.R.China 823 Phone: +86-755-28972912 824 Email: zhangfatai@huawei.com 826 Guoying Zhang 827 China Academy of Telecommunication Research of MII 828 11 Yue Tan Nan Jie Beijing, P.R.China 829 Phone: +86-10-68094272 830 Email: zhangguoying@mail.ritt.com.cn 832 Sergio Belotti 833 Alcatel-Lucent 834 Optics CTO 835 Via Trento 30 20059 Vimercate (Milano) Italy 836 +39 039 6863033 837 Email: sergio.belotti@alcatel-lucent.it 839 Daniele Ceccarelli 840 Ericsson 841 Via A. Negrone 1/A 842 Genova - Sestri Ponente 843 Italy 844 Email: daniele.ceccarelli@ericsson.com 846 Yi Lin 847 Huawei Technologies 848 F3-5-B R&D Center, Huawei Base 849 Bantian, Longgang District 850 Shenzhen 518129 P.R.China 851 Phone: +86-755-28972914 852 Email: linyi_hw@huawei.com 854 Yunbin Xu 855 China Academy of Telecommunication Research of MII 856 11 Yue Tan Nan Jie Beijing, P.R.China 857 Phone: +86-10-68094134 858 Email: xuyunbin@mail.ritt.com.cn 860 Pietro Grandi 861 Alcatel-Lucent 862 Optics CTO 863 Via Trento 30 20059 Vimercate (Milano) Italy 864 +39 039 6864930 865 Email: pietro_vittorio.grandi@alcatel-lucent.it 867 Diego Caviglia 868 Ericsson 869 Via A. Negrone 1/A 870 Genova - Sestri Ponente 871 Italy 872 Email: diego.caviglia@ericsson.com 874 Acknowledgment 876 This document was prepared using 2-Word-v2.0.template.dot. 878 Intellectual Property 880 The IETF Trust takes no position regarding the validity or scope of 881 any Intellectual Property Rights or other rights that might be 882 claimed to pertain to the implementation or use of the technology 883 described in any IETF Document or the extent to which any license 884 under such rights might or might not be available; nor does it 885 represent that it has made any independent effort to identify any 886 such rights. 888 Copies of Intellectual Property disclosures made to the IETF 889 Secretariat and any assurances of licenses to be made available, or 890 the result of an attempt made to obtain a general license or 891 permission for the use of such proprietary rights by implementers or 892 users of this specification can be obtained from the IETF on-line IPR 893 repository at http://www.ietf.org/ipr 895 The IETF invites any interested party to bring to its attention any 896 copyrights, patents or patent applications, or other proprietary 897 rights that may cover technology that may be required to implement 898 any standard or specification contained in an IETF Document. Please 899 address the information to the IETF at ietf-ipr@ietf.org. 901 The definitive version of an IETF Document is that published by, or 902 under the auspices of, the IETF. Versions of IETF Documents that are 903 published by third parties, including those that are translated into 904 other languages, should not be considered to be definitive versions 905 of IETF Documents. The definitive version of these Legal Provisions 906 is that published by, or under the auspices of, the IETF. Versions of 907 these Legal Provisions that are published by third parties, including 908 those that are translated into other languages, should not be 909 considered to be definitive versions of these Legal Provisions. 911 For the avoidance of doubt, each Contributor to the IETF Standards 912 Process licenses each Contribution that he or she makes as part of 913 the IETF Standards Process to the IETF Trust pursuant to the 914 provisions of RFC 5378. No language to the contrary, or terms, 915 conditions or rights that differ from or are inconsistent with the 916 rights and licenses granted under RFC 5378, shall have any effect and 917 shall be null and void, whether published or posted by such 918 Contributor, or included with or in such Contribution. 920 Disclaimer of Validity 922 All IETF Documents and the information contained therein are provided 923 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 924 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 925 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 926 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 927 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 928 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 929 FOR A PARTICULAR PURPOSE. 931 Copyright Notice 933 Copyright (c) 2010 IETF Trust and the persons identified as the 934 document authors. All rights reserved. 936 This document is subject to BCP 78 and the IETF Trust's Legal 937 Provisions Relating to IETF Documents 938 (http://trustee.ietf.org/license-info) in effect on the date of 939 publication of this document. Please review these documents 940 carefully, as they describe your rights and restrictions with respect 941 to this document. Code Components extracted from this document must 942 include Simplified BSD License text as described in Section 4.e of 943 the Trust Legal Provisions and are provided without warranty as 944 described in the Simplified BSD License.