idnits 2.17.1 draft-zhang-ccamp-gmpls-evolving-g709-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 3 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 -- The document date (September 22, 2009) is 5323 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: 'RFC4606' is mentioned on line 282, but not defined == Missing Reference: 'G.709' is mentioned on line 341, but not defined -- Possible downref: Normative reference to a draft: ref. 'VCAT-LCAS' -- No information found for draft-zhang-ccamp-gmpls-g - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OTN-LMP' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Daniele Ceccarelli 8 Ericsson 9 Expires: March 2010 September 22, 2009 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-03.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 March 22, 2010. 39 Abstract 41 Recent progress in ITU-T Recommendation G.709 standardization has 42 introduced new ODU containers (ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and 43 ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. 45 Several recent documents have proposed ways to modify GMPLS signaling 46 protocols to support these new OTN features. 48 It is important that a single solution is developed for use in GMPLS 49 signaling and routing protocols. This solution must support ODUk 50 multiplexing capabilities, address all of the new features, be 51 acceptable to all equipment vendors, and be extensible considering 52 continued OTN evolution. 54 This document describes the extensions to the Generalized Multi- 55 Protocol Label Switching (GMPLS) signaling to control the evolutive 56 Optical Transport Networks (OTN) addressing ODUk multiplexing and new 57 features including ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Table of Contents 67 1. Introduction...................................................3 68 2. Terminology....................................................4 69 3. GMPLS Extensions for the Evolutive G.709 - Overview............4 70 3.1. Extensions for Traffic Parameters for the Evolutive G.709 5 71 4. Generalized Label..............................................7 72 4.1. New definition of ODUk label..............................7 73 4.2. Examples..................................................9 74 4.3. Label Distribution Procedure.............................11 75 4.4. Backward Compatibility Considerations....................11 76 4.4.1. Control Plane Backward Compatibility Considerations.11 77 4.4.2. Data Plane Backward Compatibility Considerations....13 78 4.5. Collision management.....................................13 79 5. Security Considerations.......................................14 80 6. IANA Considerations...........................................14 81 7. References....................................................14 82 7.1. Normative References.....................................14 83 7.2. Informative References...................................14 84 8. Authors' Addresses............................................15 85 Acknowledgment...................................................16 87 1. Introduction 89 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 90 MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplex 91 (e.g., SONET/SDH, PDH, and ODU), Wavelength (OCh, Lambdas) Switching, 92 and Spatial Switching (e.g., incoming port or fiber to outgoing 93 port or fiber). [RFC3471] presents a functional description of the 94 extensions to Multi-Protocol Label Switching (MPLS) signaling 95 required to support Generalized MPLS. RSVP-TE-specific formats and 96 mechanisms and technology specific details are defined in [RFC3473]. 98 With the evolution and deployment of G.709 technology, it is 99 necessary that appropriate enhanced control technology support be 100 provided for G.709. [RFC4328] describes the control technology 101 details that are specific to foundation G.709 Optical Transport 102 Networks (OTN), as specified in the ITU-T G.709 recommendation [ITUT- 103 G709], for ODUk deployments without multiplexing. 105 In addition to increasing need to support ODUk multiplexing, the 106 evolution of OTN has introduced additional containers and new 107 flexibility. For example, ODU0, ODU2e, ODU4 containers as described 108 in [G709-Amd3], ODU3e1, ODU3e2 described in [Gsup43], and ODUflex 109 being developed in [G709draft-v3]. 111 In addition, the following issues require consideration: 113 - Support for ODUflex resizing capabilities, potentially hitless 114 (similar to LCAS, as defined in [VCAT-LCAS]), which is under 115 discussion in ITU-T. 117 - Support for Tributary Port Number. The Tributary Port Number 118 has to be negotiated on each link for flexible assignment of 119 tributary ports to tributary slots in case of LO-ODU over HO-ODU 120 (e.g., ODU2 into ODU3). Alternatively, the nodes of the network 121 are supposed to run AutoMSI mode. 123 Therefore, it is clear that [RFC4328] has to be updated or replaced 124 in order to support ODUk multiplexing, as well as other ODU 125 enhancements introduced by evolution of OTN standards. 127 This document updates RFC4328 extending the G.709 ODUk traffic 128 parameters and also presents a new OTN label format which is very 129 flexible and scalable. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. GMPLS Extensions for the Evolutive G.709 - Overview 139 The new features for the evolutive OTN are described in the separate 140 ITU-T documents, for example, ODU0, ODU2e,ODU4 are described in 141 [G709-Amd3] and ODU3e1, ODU3e2 are described in [Gsup43] and ODUflex 142 is being developed in [G709draft-v3]. 144 [Editors note] The signal types described in [Gsup43] (i.e., ODU3e1, 145 ODU3e2) are non standard, should IETF address this kind of signals? 147 The new signal types of digital wrapper layer for the evolutive OTN 148 are listed as follows: 150 - Optical Channel Transport Unit (OTUk): 151 . OTU4 152 . OTU2e 153 . OTU3e1 154 . OTU3e2 155 - Optical Channel Data Unit (ODUk): 156 . ODU0 157 . ODU2e 158 . ODU3e1 159 . ODU3e2 160 . ODU4 161 . ODUflex 163 A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is introduced 164 in [G709-Amd3]. At this point there are two TS granularities for the 165 original ODU1, ODU2, ODU3. The TS granularity at 2.5 Gbps is used on 166 legacy interfaces while the new 1.25 Gbps will be used for the new 167 interfaces. 169 New ITU-T documents not only introduce new signal types but also 170 define the new multiplexing hierarchy for the evolutive OTN. In 171 addition to the support of ODUk mapping into OTUk (k = 1, 2, 2e, 3, 172 3e1, 3e2, 4), G.709 and its amendments, support ODUk multiplexing. 173 For the evolutive OTN, the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, 174 flex) into an ODUk (k > j) signal can be depicted as follows: 176 - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) 178 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps 179 TS granularity) 181 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 183 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing 184 (with 1.25Gbps TS granularity) 186 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 188 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 189 multiplexing (with 1.25Gbps TS granularity) 191 - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) 193 - ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity) 195 [RFC4328] describes GMPLS signaling extensions to support the control 196 for G.709 Optical Transport Networks (OTN) [ITUT-G709].However, 197 [RFC4328] need to be updated because it does not provide the means to 198 signal all the new signal types and related mapping and multiplexing 199 functionalities. Moreover, it supports only the optional auto-MSI 200 mode which assumes that the Tributary Port Number is automatically 201 assigned in the transmit direction and not checked in the receive 202 direction. 204 This document extends the G.709 traffic parameters described in 205 [RFC4328] and also presents a new OTN label format which is very 206 flexible and scalable. 208 [Editors note] There are several possibilities to include the 209 Tributary Port Number information in the signaling. Note that ITU-T 210 has not yet given a clear interpretation of the Tributary Port number 211 information in case of bidirectional paths, so the adoption of any 212 solution should be kept on hold until ITU-T provides an approved 213 definition. 215 3.1. Extensions for Traffic Parameters for the Evolutive G.709 217 The traffic parameters for G.709 are defined in [RFC4328] as follows: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Signal Type | Reserved | NMC | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | NVC | Multiplier (MT) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Reserved | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 [Editors note] NMC field in RFC4328 had the meaning to indicate how 230 many labels have to be expected. This information allows the 231 protocol to operate without specific knowledge of the signal type. 232 The same effect could be obtained either indicating the bit map 233 length or indicating the number of labels. 235 [Editors note] In the case ODUflex, Bit Rate and Bit Rate Tolerance 236 (BR, BRT) should be indicated in the Traffic Parameters. For example, 237 if an ODUflex connection with (2.5Gbps,+-20ppm) is requested, a HO 238 OPU2 TS is a maximum of 1.249 494 145 Gbps, so the ODUflex GDPS 2.5G 239 requires 3 TS in a HO OPU2. However, a HO OPU4 TS is a maximum of 240 1.301 711 855 Gbps, so the ODUflex requires only 2 TS in a HO OPU4. 241 Therefore, (BR, BRT) should be transmitted in the signaling End to 242 End, and it will be reflected in the Traffic Parameters in the next 243 version of this draft. 245 It is obvious that the Signal Type should be extended to cover the 246 new Signal Type introduced by the evolutive OTN. The new Signal Type 247 is extended as follows: 249 Value Type 251 ----- ---- 252 0 Not significant 253 1 ODU1 (i.e., 2.5 Gbps) 254 2 ODU2 (i.e., 10 Gbps) 255 3 ODU3 (i.e., 40 Gbps) 256 4 ODU4 (i.e., 100 Gbps) 257 5 Reserved (for future use) 258 6 OCh at 2.5 Gbps 259 7 OCh at 10 Gbps 260 8 OCh at 40 Gbps 261 9 OCh at 100 Gbps 262 10~19 Reserved (for future use) 263 20 ODU0 (i.e., 1.25 Gbps) 264 21~30 Reserved (for future use) 265 31 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 266 32 ODU3e1 267 33 ODU3e2 268 34 ODUflex (i.e., 1.25*N Gbps) 269 35~255 Reserved (for future use) 271 4. Generalized Label 273 [RFC3471] has defined the Generalized Label which extends the 274 traditional label by allowing the representation of not only labels 275 which travel in-band with associated data packets, but also labels 276 which identify time-slots, wavelengths, or space division multiplexed 277 positions. The format of the corresponding RSVP-TE Generalized Label 278 object is defined in the Section 2.3 of [RFC3473]. 280 However, for different technologies, we usually need use specific 281 label rather than the Generalized Label. For example, the label 282 format described in [RFC4606] could be used for SDH/SONET, the label 283 format in [RFC4328] for G.709. 285 According to the ODUk label format defined in [RFC4328], it could be 286 updated to support new signal types defined in G.709 amendment 3 and 287 G.sup43 but would hardly be further enhanced to support possible new 288 signal types. Furthermore such label format can face big problems 289 related to scalability matters due to the high number of labels 290 needed. For example, when ODU3 is mapped into ODU4 with 1.25G 291 tributary slots, it will need thirty-two labels (32*4*8=1024 bits) to 292 be allocated for one ODU3 connection. If ODUflex into ODU4, it may 293 need up to eighty labels (80*4*8=2560 bits) to be allocated for one 294 ODUflex connection. 296 In this document, a new ODUk label format is defined. The new ODUk 297 label format is very flexible and scalable. 299 4.1. New definition of ODUk label 301 In order to be compatible with new types of ODU signal and new types 302 of tributary slot, the following new ODUk label format is defined: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | ODUj |OD(T)Uk| T | Reserved | Bit Map | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | ......... | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ODUj and OD(T)Uk (4 bits respectively): indicate that ODUj is 313 multiplexed into ODUk(k>j), or ODUj is mapped into OTUk (j=k). 315 ODUj field Signal type 317 ---------- ----------- 318 0 ODU0 319 1 ODU1 320 2 ODU2 321 3 ODU3 322 4 ODU4 323 5 ODU2e 324 6 ODUflex 325 7-15 Reserved (for future use) 327 OD(T)Uk field Signal type 329 ---------- ----------- 330 0 Reserved (for future use) 331 1 ODU1/OTU1 332 2 ODU2/OTU2 333 3 ODU3/OTU3 334 4 ODU4/OTU4 335 5 OTU2e 336 6 OTU3e1 337 7 OTU3e2 338 8-15 Reserved (for future use) 340 T (2 bits): indicates the type of tributary slot of OD(T)Uk. 341 Currently, two types of tributary slot are defined in [G.709], the 342 1.25Gbps tributary slot and the 2.5Gbps tributary slot. 344 T field TS type 345 ------- ------- 346 0 1.25Gbps TS granularity 347 1 2.5Gbps TS granularity 348 2-3 Reserved (for future use) 350 Bit Map (variable): indicates which tributary slots in ODUk that the 351 ODUj will be multiplexed into. The sequence of the Bit Map is 352 consistent with the sequence of the tributary slots in ODUk. Each bit 353 in the bit map represents the corresponding tributary slot in ODUk 354 with a value of 1 or 0 indicating whether the tributary slot will be 355 used by ODUj or not. 357 The size of the bit map equals to the total number of the tributary 358 slots of ODUk. 360 Padded bits are added behind the Bit Map to make the whole label a 361 multiple of four bytes if necessary. Padded bit MUST be set to 0 and 362 MUST be ignored. 364 In case of an ODUk mapped into OTUk, it's no need to indicate which 365 tributary slots will be used by ODUk, so the size of Bit Map is 0. 367 [Editors note] Tributary Port Number information to be inserted as 368 soon as clarification from ITU has been provided. 370 4.2. Examples 372 The following examples are given in order to illustrate the label 373 format described in the previous sections of this document. 375 (1) ODUk in OTUk mapping: 377 In such conditions, the downstream node along an LSP returns a label 378 indicating that the ODU1 (ODU2 or ODU3 or ODU4) is directly mapped 379 into the corresponding OTU1 (OTU2 or OTU3 or ODU4). The following 380 example label indicates an ODU1 mapped into OTU1 with 2.5Gbps TS 381 granularity. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |0 0 0 1|0 0 0 1|0 1| Reserved | Padded Bits (0) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 (2) ODUj into ODUk multiplexing: 390 In such conditions, this label indicates that an ODUj is multiplexed 391 into several tributary slots of OPUk and then mapped into OTUk. Some 392 instances are shown as follow: 394 - ODU0 into ODU2 Multiplexing: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |0 0 0 0|0 0 1 0|0 0| Reserved |0 1 0 0 0 0 0 0|Padded Bits (0)| 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 This above label indicates an ODU0 multiplexed into the second 403 tributary slot of ODU2, wherein the type of the tributary slot is 404 1.25Gbps. 406 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |0 0 0 1|0 0 1 0|0 0| Reserved |0 1 0 1 0 0 0 0|Padded Bits (0)| 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 This above label indicates an ODU1 multiplexed into the 2nd, 4th 415 tributary slot of ODU2, wherein the type of the tributary slot is 416 1.25Gbps. 418 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |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| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 427 and 7th tributary slot of ODU3, wherein the type of the tributary 428 slot is 2.5Gbps. 430 4.3. Label Distribution Procedure 432 This document does not change the existing label distribution 433 procedures [RFC4328] for GMPLS except that the new ODUk label should 434 be processed as follows. 436 When a node receives a generalized label request for setting up an 437 ODUj LSP from its upstream node, the node should generate an ODU 438 label according to the signal type of the requested LSP and the free 439 resources (i.e., free tributary slots of ODUk) that will be reserved 440 for the LSP, and send the label to its upstream node. Note that these 441 labels can also be specified by the source node of the connection. 443 In case of ODUj to ODUk multiplexing, the node should firstly 444 determine the size of the Bit Map field according to the signal type 445 and the tributary slot type of ODUk, and then set the bits to 1 in 446 the Bit Map field corresponding to the reserved tributary slots. 448 In case of ODUk to OTUk mapping, the node only needs to fill the ODUj 449 and the ODUk fields with corresponding values in the label. Other 450 bits are reserved and MUST be set to 0. 452 When receiving an ODU label from its downstream node, the node should 453 learn which ODU signal type is multiplexed or mapped into which ODU 454 signal type by analyzing the ODUj and the ODUk fields. 456 In case of ODUj to ODUk multiplexing, the node should firstly 457 determine the size of the Bit Map field according to the signal type 458 and the tributary slot type of ODUk, and then obtain which tributary 459 slots in ODUk are reserved by its downstream node according to the 460 position of the bits that are set to 1 in the Bit Map field, so that 461 the node can multiplex the ODUj into the reserved tributary slots of 462 ODUk after the LSP is established. 464 In case of ODUk to OTUk mapping, the size of Bit Map field is 0 and 465 no additional procedure is needed. 467 4.4. Backward Compatibility Considerations 469 4.4.1. Control Plane Backward Compatibility Considerations 471 Since the [RFC4328] has been deployed in the network for the nodes 472 which support the [ITUT-G709] (herein we call them "old nodes"), the 473 backward compatibility SHOULD be take into consideration when the new 474 nodes (i.e., nodes that support the [G709-Amd3] or [Gsup43] or 475 [G709draft-v3]) and the old nodes are interworking. 477 For backward compatibility consideration, the new node SHOULD have 478 the ability to generate and parse old labels. 480 - For the old node, it always generates and sends old label to its 481 upstream node, no matter the upstream node is new or old, as 482 described in [RFC4328]. 484 - For the new node, it will generate and send old label if its 485 upstream node is an old one, and generate and send new label if 486 its upstream node is a new one. 488 One backward compatibility example is shown below: 490 Path Path Path Path 491 +-----+ ----> +-----+ ----> +-----+ ----> +-----+ ----> +-----+ 492 | | | | | | | | | | 493 | A +-------+ B +-------+ C +-------+ D +-------+ E | 494 |(new)| |(new)| |(old)| |(old)| |(new)| 495 +-----+ <---- +-----+ <---- +-----+ <---- +-----+ <---- +-----+ 496 Resv Resv Resv Resv 497 (new label) (old label) (old label) (old label) 499 As described above, for backward compatibility considerations, it is 500 necessary for a new node to know whether the neighbor node is new or 501 old. 503 One optional method is manual configuration. But it is recommended to 504 use LMP to discover the capability of the neighbor node automatically, 505 as described in [OTN-LMP]. 507 When performing the HO ODU link capability negotiation: 509 o If the neighbor node only support the 2.5Gbps TS and only support 510 ODU1/ODU2/ODU3, the neighbor node should be treated as an old node. 512 o If the neighbor node can support the 1.25Gbps TS, or can support 513 other LO ODU types defined in [G709-Amd3] or [Gsup43] or 514 [G709draft-v3]), the neighbor node should be treated as new node. 516 o If the neighbor node returns a LinkSummaryNack message including 517 an ERROR_CODE indicating nonsupport of HO ODU link capability 518 negotiation, the neighbor node should be treated as an old node. 520 4.4.2. Data Plane Backward Compatibility Considerations 522 As described in chapter 3.1 and 4.1 of [OTN-LMP], the node supporting 523 1.25Gbps TS can interwork with the other nodes that supporting 524 2.5Gbps TS by combining Specific TSs together in data plane. The 525 control plane MUST support this TS combination. 527 Take the following figure as an example. Assume that there is an ODU2 528 link between node A and B, where node A only supports the 2.5Gbps TS 529 while node B supports the 1.25Gbps TS. In this case, the TS#i and 530 TS#i+4 (where i<=4) of node B are combined together. When creating an 531 ODU1 service in this ODU2 link, node B reserves the TS#i and TS#i+4 532 with the granularity of 1.25Gbps. But in the label sent from B to A, 533 it is indicated that the TS#i with the granularity of 2.5Gbps is 534 reserved. 536 Path 537 +----------+ ------------> +----------+ 538 | TS1==|===========\--------+--TS1 | 539 | TS2==|=========\--\-------+--TS2 | 540 | TS3==|=======\--\--\------+--TS3 | 541 | TS4==|=====\--\--\--\-----+--TS4 | 542 | | \ \ \ \----+--TS5 | 543 | | \ \ \------+--TS6 | 544 | | \ \--------+--TS7 | 545 | | \----------+--TS8 | 546 +----------+ <------------ +----------+ 547 node A Resv node B 549 In the contrary direction, when receiving a label from node A 550 indicating that the TS#i with the granularity of 2.5Gbps is reserved, 551 node B will reserved the TS#i and TS#i+4 with the granularity of 552 1.25Gbps in its control plane. 554 4.5. Collision management 556 [Editors note] This chapter should indicate the procedure in case of 557 collision between Tributary Port Numbers and/or Tributary Slots e.g. 558 two different LSP setups may choose a disjoint set of Tributary Slots 559 but they may request the same Tributary Port Number value (same MSI 560 in G.709 OPUk field). 562 In this case the first signaling should be successful and the second 563 one must fail. 565 5. Security Considerations 567 TBD. 569 6. IANA Considerations 571 TBD. 573 7. References 575 7.1. Normative References 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 581 Switching (GMPLS) Signaling Extensions for G.709 Optical 582 Transport Networks Control", RFC 4328, Jan 2006. 584 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 585 Switching (GMPLS) Signaling Functional Description", 586 RFC 3471, January 2003. 588 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 589 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 590 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 592 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 593 (GMPLS) Architecture", RFC 3945, October 2004. 595 [VCAT-LCAS] G. Bernstein, Ed., "Operating Virtual Concatenation (VCAT) 596 and the Link Capacity Adjustment Scheme (LCAS) with 597 Generalized Multi-Protocol Label Switching (GMPLS)", draft- 598 bernstein-ccamp-gmpls-vcat-lcas, July 29, 2009. 600 [OTN-LMP] Fatai Zhang, Ed., "Link Management Protocol (LMP) 601 extensions for G.709 Optical Transport Networks", draft- 602 zhang-ccamp-gmpls-g.709-lmp-discovery-00.txt, Sep 19, 2009. 604 7.2. Informative References 606 [ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)," 607 G.709 Recommendation (and Amendment 1), February 2001 (October 2001). 609 [G709-Amd3] ITU-T, "Interface for the Optical Transport Network (OTN)," 610 G.709 Recommendation Amendment3), December 2008. 612 [Gsup43] ITU-T, " Proposed revision of G.sup43 (for agreement),", 613 December 2008. 615 [G709draft-v3] ITU-T, "Draft revised G.709, version 3,", May 2009. 617 8. Authors' Addresses 619 Fatai Zhang 620 Huawei Technologies 621 F3-5-B R&D Center, Huawei Base 622 Bantian, Longgang District 623 Shenzhen 518129 P.R.China 624 Phone: +86-755-28972912 625 Email: zhangfatai@huawei.com 627 Guoying Zhang 628 China Academy of Telecommunication Research of MII 629 11 Yue Tan Nan Jie Beijing, P.R.China 630 Phone: +86-10-68094272 631 Email: zhangguoying@mail.ritt.com.cn 633 Sergio Belotti 634 Alcatel-Lucent 635 Optics CTO 636 Via Trento 30 20059 Vimercate (Milano) Italy 637 +39 039 6863033 638 Email: sergio.belotti@alcatel-lucent.it 640 Daniele Ceccarelli 641 Ericsson 642 Via A. Negrone 1/A 643 Genova - Sestri Ponente 644 Italy 645 Email: daniele.ceccarelli@ericsson.com 647 Yi Lin 648 Huawei Technologies 649 F3-5-B R&D Center, Huawei Base 650 Bantian, Longgang District 651 Shenzhen 518129 P.R.China 652 Phone: +86-755-28972914 653 Email: linyi_hw@huawei.com 655 Yunbin Xu 656 China Academy of Telecommunication Research of MII 657 11 Yue Tan Nan Jie Beijing, P.R.China 658 Phone: +86-10-68094134 659 Email: xuyunbin@mail.ritt.com.cn 661 Pietro Grandi 662 Alcatel-Lucent 663 Optics CTO 664 Via Trento 30 20059 Vimercate (Milano) Italy 665 +39 039 6864930 666 Email: pietro_vittorio.grandi@alcatel-lucent.it 668 Diego Caviglia 669 Ericsson 670 Via A. Negrone 1/A 671 Genova - Sestri Ponente 672 Italy 673 Email: diego.caviglia@ericsson.com 675 Acknowledgment 677 TBD. 679 Intellectual Property 681 The IETF Trust takes no position regarding the validity or scope of 682 any Intellectual Property Rights or other rights that might be 683 claimed to pertain to the implementation or use of the technology 684 described in any IETF Document or the extent to which any license 685 under such rights might or might not be available; nor does it 686 represent that it has made any independent effort to identify any 687 such rights. 689 Copies of Intellectual Property disclosures made to the IETF 690 Secretariat and any assurances of licenses to be made available, or 691 the result of an attempt made to obtain a general license or 692 permission for the use of such proprietary rights by implementers or 693 users of this specification can be obtained from the IETF on-line IPR 694 repository at http://www.ietf.org/ipr 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary 698 rights that may cover technology that may be required to implement 699 any standard or specification contained in an IETF Document. Please 700 address the information to the IETF at ietf-ipr@ietf.org. 702 The definitive version of an IETF Document is that published by, or 703 under the auspices of, the IETF. Versions of IETF Documents that are 704 published by third parties, including those that are translated into 705 other languages, should not be considered to be definitive versions 706 of IETF Documents. The definitive version of these Legal Provisions 707 is that published by, or under the auspices of, the IETF. Versions of 708 these Legal Provisions that are published by third parties, including 709 those that are translated into other languages, should not be 710 considered to be definitive versions of these Legal Provisions. 712 For the avoidance of doubt, each Contributor to the IETF Standards 713 Process licenses each Contribution that he or she makes as part of 714 the IETF Standards Process to the IETF Trust pursuant to the 715 provisions of RFC 5378. No language to the contrary, or terms, 716 conditions or rights that differ from or are inconsistent with the 717 rights and licenses granted under RFC 5378, shall have any effect and 718 shall be null and void, whether published or posted by such 719 Contributor, or included with or in such Contribution. 721 Disclaimer of Validity 723 All IETF Documents and the information contained therein are provided 724 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 725 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 726 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 727 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 728 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 729 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 730 FOR A PARTICULAR PURPOSE. 732 Full Copyright Statement 734 Copyright (c) 2009 IETF Trust and the persons identified as the 735 document authors. All rights reserved. 737 This document is subject to BCP 78 and the IETF Trust's Legal 738 Provisions Relating to IETF Documents in effect on the date of 739 publication of this document (http://trustee.ietf.org/license-info). 740 Please review these documents carefully, as they describe your rights 741 and restrictions with respect to this document.