idnits 2.17.1 draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-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 ([MULTI-STAGES-MULTIPLEXING-CONFIG-REQ], [MULTI-STAGES-MULTIPLEXING-CONFIG-FRW]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 26, 2010) is 5085 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: 'MULTI-STAGES-MULTIPLEXING-CONFIG-REQ' is mentioned on line 17, but not defined == Missing Reference: 'MULTI-STAGES-MULTIPLEXING-CONFIG-FRW' is mentioned on line 18, but not defined == Missing Reference: 'MULTI-STAGES-MULTIPLEXING-CONFIG-OSPFTE-EXT' is mentioned on line 113, but not defined == Missing Reference: 'RFC3209' is mentioned on line 131, but not defined == Missing Reference: 'RFC3473' is mentioned on line 489, but not defined == Missing Reference: 'RFC4874' is mentioned on line 136, but not defined == Missing Reference: 'RFC4206' is mentioned on line 463, but not defined == Missing Reference: 'RFC4203' is mentioned on line 489, but not defined == Missing Reference: 'RFC4205' is mentioned on line 489, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'RFC4204' is mentioned on line 490, but not defined == Missing Reference: 'RFC5440' is mentioned on line 490, but not defined == Missing Reference: 'GMPLS-SEC' is mentioned on line 490, but not defined == Unused Reference: 'I-D.kern-ccamp-rsvpte-hop-attributes' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-gmpls-g709-framework' is defined on line 513, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-00 Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft M. Betts 4 Intended status: Standards Track ZTE Corporation 5 Expires: October 28, 2010 R. Jing 6 X. Huo 7 China Telecom 8 April 26, 2010 10 RSVP-TE Extension for Multi Stages Multiplexing Configuration in G.709 11 Optical Transport Network 12 draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-00 14 Abstract 16 Multi stages multiplexing configuration requirement is defined in 17 [MULTI-STAGES-MULTIPLEXING-CONFIG-REQ] document. Multi stages 18 multiplexing configuration framework is diefined in [MULTI-STAGES- 19 MULTIPLEXING-CONFIG-FRW] document. They describe some scenarios for 20 the interworking between regions with 1.25G TS and 2.5G TS and the 21 multi-domain OTN applications based on the tunnel design. Multi 22 stages multiplexing is desirable to facilitate the introduction of 23 new ODU0 and ODUflex signals to an existing network without having to 24 upgrade every node in the network. So ODU0/ODUflex can be mapped 25 into ODU1/ODU2/ODU3 transit across the 2.5G TS region. Multi stages 26 multiplexing/demultiplexing are also used to support the multi-domain 27 OTN applications based on the tunnel design. This document describes 28 the RSVP-TE extension for multi stages multiplexing configuration in 29 G.709 Optical Transport Network. 31 Conventions Used In This Document 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 28, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. RSVP-TE Extension for Multi Stages Multiplexing 73 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Multi Stages Multiplexing Hierarchy Sub-TLV . . . . . . . 5 75 2.2. Signaling Procedure for Multi Stages Multiplexing 76 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Signaling Procedure Example . . . . . . . . . . . . . . . 8 78 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 G.709 has supported a single stage of ODU multiplexing. The 88 practical consequence of this in OTNv1 is an ODU1 can be mapped 89 directly to a tributary slot of an ODU3, without having to be first 90 mapped into an ODU2. The motivation for this architecture is 91 reducing complexity. In the normal progression of things, new 92 additions to the OTN were expected to be at faster bit rates, and 93 thus the single stage concept could be easily maintained going 94 forward. 96 The introduction of ODU0 and ODUflex to the OTN hierarchy creates a 97 situation where the newly added ODUk signals have a bit rate that is 98 lower than any of the existing signals, which presents some different 99 challenges because the new signals can be clients of the existing 100 signals. As a result, there are clear applications where multi 101 stages of multiplexing would be desirable to facilitate the 102 introduction of these new ODU0 and ODUflex signals to an existing 103 network without having to upgrade every node in the network. Using 104 multi stages of multiplexing at the domain boundary allows the 105 operator to confine the new rates to only those nodes that need to 106 support them. 108 A second potential application for multi stages outside of an upgrade 109 scenario would be a network design based on tunnels. Multi stages 110 multiplexing are used to support the multi-domain OTN applications 111 based on the tunnel design. 113 Based on the [MULTI-STAGES-MULTIPLEXING-CONFIG-OSPFTE-EXT], path 114 computation entity can get multi stages multiplexing/demultiplexing 115 capability of each gateway nodes for path computation. So the path 116 computation entity must select some proper kinds of multi stages 117 multiplexing/demultiplexing for different gateway nodes along a 118 specific end-to-end connection. All kinds of multi stages 119 multiplexing which has been determined for all gateway nodes along 120 one end-to-end connection by path computation entity must be carried 121 with signaling message. After one gateway node receives the 122 signaling message who carries one kind of multi stages multiplexing 123 for it, it must config this kind of multi stages multiplexing to its 124 data plane. 126 This document describes the RSVP-TE extension for multi stages 127 multiplexing configuration in G.709 Optical Transport Network. 129 2. RSVP-TE Extension for Multi Stages Multiplexing Configuration 131 The Explicit Route Object [RFC3209] allows the ingress node to 132 partially or fully specify the route of an LSP. The route is encoded 133 as a sequence of hops that identifies a node or interface that must 134 be crossed. Further attributes assigned to each hop can be added to 135 the route such as per-hop label control [RFC3473] and list of 136 prohibited resources between two nodes [RFC4874]. 138 After path computation entity gets multi stages multiplexing/ 139 demultiplexing capability information of each gateway nodes, it must 140 determine a proper kind of multi stages multiplexing of each gateway 141 nodes along one end-to-end connection. All kinds of multi stages 142 multiplexing of each gateway nodes can be carried in ERO object. 143 After one gateway node receives the signaling message who carries one 144 kind of multi stages multiplexing for it, the gateway node must 145 determine what tunnel must be created between both gateway nodes 146 located at the domain boundary for one end-to-end connection whose 147 bandwidth is lower than it by the multi stages multiplexing 148 hierarchy. So the tunnel can be triggered based on [RFC4206]. It 149 must config this kind of multi stages multiplexing to its data plane. 151 In order to carry the multi stages multiplexing information in ERO, 152 it is desirable to extend the ERO object. [HOP_ATTRIBUTES] introduce 153 a new ERO sub-object that encodes attributes relevant to a particular 154 node or interface within the node. The HOP_ATTRIBUTES subobject can 155 be inserted into ERO, SERO, RRO and SRRO. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |0| Type | Length | Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Attribute TLVs | 163 ~ ~ 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 2.1. Multi Stages Multiplexing Hierarchy Sub-TLV 168 This document extends the HOP_ATTRIBUTES defined in document 169 [HOP_ATTRIBUTES]. It defineds a new Attributes TLV. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type (TBD) (IANA) | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | MSMH | ...Multi Stages Multiplexing Capability... | padding | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 MSMH and MSMC indicate the multi stages multiplexing hierarchy 179 detailed information. 181 o Type: Indicates the type of Attribute TLV. 183 o MSMH (Multi Stages Multiplexing Hierarchies): Indicates the number 184 of Multi Stages Multiplexing Hierarchies relevant to a particular 185 internal node or interface of the LSP. 187 o MSMC (Multi Stages Multiplexing Capability): Indicates the kind of 188 multi stages multiplexing capability relevant to a particular 189 internal node or interface of the LSP. The length of Multi Stages 190 Multiplexing Capability (MSMC) information depends on the number 191 of multi stages multiplexing hierarchies (MSMH). So the length of 192 MSMC is (MSMH+1) * 4. Each ODUk (k=1, 2, 3, 4, 2e, flex) is 193 indicated by 4 bits. Following is the Signal Type for G.709 194 Amendment 3. 196 Value Type 197 ----- ---- 198 0000 ODU0 199 0001 ODU1 200 0010 ODU2 201 0011 ODU3 202 0100 ODU4 203 0101 ODU2e 204 0110 ODUflex 205 7-15 Reserved (for future use) 207 o The padding is used to make the Multi Stages Multiplexing 208 Capability sub-TLV 32-bits aligned. 210 2.2. Signaling Procedure for Multi Stages Multiplexing Configuration 212 In this section we describe signaling procedures for multi stages 213 multiplexing configuration. The path computation entity computes and 214 returns an end-to-end ODUk path to ingress LSR converted to an 215 Explicit Route Object (ERO) for use in RSVP-TE signaling. What 216 tunnel must be determined between both gateway nodes located at the 217 domain boundary for one end-to-end connection whose bandwidth is 218 lower than it by the multi stages multiplexing hierarchy of gateway 219 nodes. Establishment/termination of ODUk tunnel may be triggered 220 either by mechanisms outside of GMPLS (e.g., via Management Plane 221 and/or planning tool), or by mechanisms within GMPLS ([RFC4206]).So 222 the tunnel can be created based on [RFC4206]. If this ODUk (lower 223 ODUk) path is to be tunneled over an FA-LSP (Higher ODUk) between a 224 pair of gateway nodes, all kinde of multi stages multiplexing encoded 225 into ERO determined by path computation entity or Management Plane 226 must be carried by Path message. One pairs or multiple pairs of 227 gateway nodes can be carried in Path message. 229 The end-to-end ODUk connection setup procedure is described below: 231 1. Ingress node initiates the setup of end-to-end connection. A 232 specific kind of multi stages multiplexing hierarchy relevant to 233 a particular gateway node or interface within this gateway node 234 along the path is included in a HOP_ATTRIBUTES subobject, which 235 is inserted into the ERO. 237 2. On reception of a Path message containing HOP_ATTRIBUTES whose 238 type of Attributes TLV is Multi States Multiplexing Hierarchy 239 Sub-TLV, the receiver of message along the path must check the 240 local data plane capability to see if this kind of multi stages 241 multiplexing/demultiplexing is acceptable on specific interface 242 or gateway node. If there is an acceptable kind of multi stages 243 multiplexing/demultiplexing, then this kind of multi stages 244 multiplexing/demultiplexing hierarchy must be configed into the 245 data plane, and forward the Path message to the downstream node. 246 Otherwise the Path message will be terminated, and a PathErr 247 message with a "Routing problem/Multi Stages Multiplexing 248 Hierarchy not Acceptable" indication will be generated. 250 3. A node that does not recognize the type of a Attribute TLV 251 carried in the HOP_ATTRIBUTES object must reject the PATH message 252 and issue a PathErr message with Error Code "Unknown Attribute 253 TLV" and the Error Value is set to the type code of the unknown 254 TLV. 256 4. The multi stages multiplexing configuration must be together with 257 cross-connection configuration. So if the cross-connection is 258 configed during the Resv message, the kind of multi stages 259 multiplexing which is received by Path message must be stored 260 into internal node. When a Resv message is received at an 261 gateway node, if there is a kind of multi stages multiplexing 262 which has not yet been configed, the gateway node must check the 263 local data plane capability to see if this kind of multi stages 264 multiplexing/demultiplexing is acceptable on specific interface 265 or gateway node. If there is an acceptable kind of multi stages 266 multiplexing/demultiplexing, then this kind of multi stages 267 multiplexing/demultiplexing hierarchy must be configed into the 268 data plane 270 2.3. Signaling Procedure Example 272 In Figure 1, node 4, 5, 6 and 7 have ODU1 and ODU2 switching 273 capability. All nodes only support 2.5G TS granularity. They can't 274 support ODU0/ODUflex directly. They could not have any visibility to 275 the ODU0/ODUflex. 277 -- 278 /|12|\ 279 / -- \ 280 / \ 281 -- / ODU2 \-- 282 |11| Network 4 |13| 283 -- \ / -- 284 \ / 285 \ - / 286 \| |/ 287 - Gateway4 288 | 289 | 290 - - - 291 /|2|\ /|5|\ /|8|\ 292 / - \ / - \ / - \ 293 / \ / \ / \ 294 - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- 295 |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| 296 - \ / - - \ / - - \ / -- 297 \ /Gateway1 \ / Gateway3\ / 298 \ - / \ - / \ - / 299 \|3|/ \|6|/ \|9|/ 300 - - - 302 There are three 10G OTN networks are deployed, such as ODU2 Network 303 1, ODU 2 Network 3 and ODU2 Network 4. All ODU2 networks are 304 interconnected with ODU3 network by OTU3 link. All nodes of three 305 ODU2 networks support the 1.25G TS granularity and are based on G.709 306 v3. All nodes in ODU2 Network 1 and ODU2 Network 4 can support ODU0, 307 ODU1 and ODUflex switching capability. 309 ODU2 Network 3 is only desirable to support GigE and ODUflex 310 services, so all nodes in ODU2 Network 3 only support ODU0 and 311 ODUflex for more economical cost. It doesn't support ODU1 (e.g., 312 STM-16) application. 314 The operator limits the ODUflex application of ODU2 Network 4 to the 315 local network. There is no any multi-domain ODUflex application 316 which goes into ODU2 Network 4 and vice versa. 318 In order for the interworking between 1.25G TS and 2.5G TS networks, 319 there should be some gateway nodes (i.e., Gateway 1, Gateway 3 and 320 Gateway 4) which are added in order to support ODU0/ODUflex. Within 321 the gateway nodes, multi stages multiplexing/demultiplexing allow 322 ODU0/ODUflex to be supported across the legacy network. ODU0/ODUflex 323 is mapped first to ODU1 or ODU2, and that ODU1/2 is then mapped into 324 ODU3. 326 Gateway 1 is supposed to support the following multi stages 327 multiplexing/demultiplexing capability. 329 o ODU0-ODU1-ODU3 331 o ODU0-ODU2-ODU3 333 o ODU1-ODU2-ODU3 335 o ODUflex-ODU2-ODU3 337 Gateway 3 is supposed to support the following multi stages 338 multiplexing/demultiplexing capability. 340 o ODU0-ODU2-ODU3 342 o ODUflex-ODU2-ODU3 344 Gateway 4 is supposed to support the following multi stages 345 multiplexing/demultiplexing capability. There is no any multi-domain 346 ODUflex application which goes into ODU2 Network 4 and vice versa. 347 The operator limits the ODUflex application to the local network. It 348 doesn't support the ODUflex-ODU2-ODU3 multiplexing. 350 o ODU0-ODU1-ODU3 352 o ODU0-ODU2-ODU3 354 For a end-to-end ODU0 connection between node 1 and node 10, path 355 computation entity return a path to ingress LSR. The routing of path 356 is 1, 3, Gateway 1, 4, 6, 7, Gateway 3, 9 and 10. This ODU0 357 connection is to be tunneled over an FA-LSP (i.e., ODU2 tunnel) 358 between Gateway 1 and Gateway 3. The two stages multiplexing 359 hierarchy ODU0-ODU2-ODU3 must be configed in Gateway 1 and Gateway 3. 361 1. Ingress node 1 initiates the setup of end-to-end connection. The 362 two stages multiplexing hierarchy ODU0-ODU2-ODU3 relevant to 363 Gateway 1 and Gateway 3 are included in a Attribute TLV of 364 HOP_ATTRIBUTES subobject which is inserted into different ERO 365 subobject (i.e., Gateway 1 and Gateway 3). 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type (TBD)(IANA) | Length(4) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |0 0 1 0|0 0 0 0|0 0 1 0|0 0 1 1| padding | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 2. On reception of a Path message containing HOP_ATTRIBUTES whose 376 type of Attributes TLV is Multi States Multiplexing Hierarchy 377 Sub-TLV, Gateway 1 check the local data plane capability to see 378 if this kind of multi stages multiplexing/demultiplexing is 379 acceptable on specific interface or gateway node. There is an 380 acceptable kind of multi stages multiplexing/demultiplexing, 381 Gateway 1 determin an ODU2 tunnel must be created between Gateway 382 1 and Gateway 3. So it creates a ODU2 tunnel based on [RFC4206] 383 for this ODU0 end-to-end connection which will tunnel over it. 385 3. The creation of ODU0 connection is to be continued. The kind of 386 multi stages multiplexing/demultiplexing (i.e., ODU0-ODU2-ODU3) 387 is configed into the data plane of Gateway 1. Gateway 1 forward 388 the Path message to the downstream node. 390 4. On reception of a Path message containing HOP_ATTRIBUTES whose 391 type of Attributes TLV is Multi States Multiplexing Hierarchy 392 Sub-TLV, Gateway 3 check the local data plane capability to see 393 if this kind of multi stages multiplexing/demultiplexing is 394 acceptable on specific interface or gateway node. There is an 395 acceptable kind of multi stages multiplexing/demultiplexing, so 396 this kind of multi stages multiplexing/demultiplexing (i.e., 397 ODU0-ODU2-ODU3) is configed into the data plane. Gateway 3 398 forward the Path message to the downstream node. 400 For a end-to-end ODUflex (e.g., Bandwidth is 5*1.25G TS) connection 401 between node 1 and node 8, path computation entity return a path to 402 ingress LSR. Both ODUflex and ODU0 connection transport a same pair 403 of gateway node (i.e., Gateway 1 and Gateway3). They can share a 404 same ODU2 tunnel. The routing of this ODUflex connection is 1, 3, 405 Gateway 1, 4, 6, 7, Gateway 3, and 8. This ODUflex connection is to 406 be tunneled over an FA-LSP (i.e., ODU2 tunnel) which has been 407 created. The two stages multiplexing hierarchy ODUflex-ODU2-ODU3 408 must be configed in Gateway 1 and Gateway 3. 410 1. Ingress node 1 initiates the setup of end-to-end connection. The 411 two stages multiplexing hierarchy ODUflex-ODU2-ODU3 relevant to 412 Gateway 1 and Gateway 3 are included in a Attribute TLV of 413 HOP_ATTRIBUTES subobject which is inserted into different ERO 414 subobject (i.e., Gateway 1 and Gateway 3). 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type (TBD)(IANA) | Length(4) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 |0 0 1 0|0 1 1 0|0 0 1 0|0 0 1 1| padding | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 2. On reception of a Path message containing HOP_ATTRIBUTES whose 425 type of Attributes TLV is Multi States Multiplexing Hierarchy 426 Sub-TLV, Gateway 1 and Gateway 3 check the local data plane 427 capability to see if this kind of multi stages multiplexing/ 428 demultiplexing is acceptable on specific interface or gateway 429 node. There is an acceptable kind of multi stages multiplexing/ 430 demultiplexing, so this kind of multi stages multiplexing/ 431 demultiplexing (i.e., ODUflex-ODU2-ODU3) is configed into the 432 data plane. Gateway 3 forward the Path message to the downstream 433 node. 435 For a end-to-end ODU0 connection between node 2 and node 12, path 436 computation entity return a path to ingress LSR. The routing of path 437 is 2, Gateway 1, 4, 5, Gateway 4, 11 and 12. This ODU0 connection is 438 to be tunneled over an FA-LSP (i.e., ODU1 tunnel) between Gateway 1 439 and Gateway 4. The two stages multiplexing hierarchy ODU0-ODU1-ODU3 440 must be configed in Gateway 1 and Gateway 4. 442 1. Ingress node 2 initiates the setup of end-to-end connection. The 443 two stages multiplexing hierarchy ODU0-ODU1-ODU3 relevant to 444 Gateway 1 and Gateway 4 are included in a Attribute TLV of 445 HOP_ATTRIBUTES subobject which is inserted into different ERO 446 subobject (i.e., Gateway 1 and Gateway 4). 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type (TBD)(IANA) | Length(4) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |0 0 1 0|0 0 0 0|0 0 0 1|0 0 1 1| padding | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 2. On reception of a Path message containing HOP_ATTRIBUTES whose 457 type of Attributes TLV is Multi States Multiplexing Hierarchy 458 Sub-TLV, Gateway 1 check the local data plane capability to see 459 if this kind of multi stages multiplexing/demultiplexing is 460 acceptable on specific interface or gateway node. There is an 461 acceptable kind of multi stages multiplexing/demultiplexing, 462 Gateway 1 determin an ODU1 tunnel must be created between Gateway 463 1 and Gateway 4. So it creates a ODU1 tunnel based on [RFC4206] 464 for this ODU0 end-to-end connection which will tunnel over it. 466 3. The creation of ODU0 connection is to be continued. The kind of 467 multi stages multiplexing/demultiplexing (i.e., ODU0-ODU1-ODU3) 468 is configed into the data plane of Gateway 1. Gateway 1 forward 469 the Path message to the downstream node. 471 4. On reception of a Path message containing HOP_ATTRIBUTES whose 472 type of Attributes TLV is Multi States Multiplexing Hierarchy 473 Sub-TLV, Gateway 4 check the local data plane capability to see 474 if this kind of multi stages multiplexing/demultiplexing is 475 acceptable on specific interface or gateway node. There is an 476 acceptable kind of multi stages multiplexing/demultiplexing, so 477 this kind of multi stages multiplexing/demultiplexing (i.e., 478 ODU0-ODU1-ODU3) is configed into the data plane. Gateway 4 479 forward the Path message to the downstream node. 481 3. Security Considerations 483 The use of control plane protocols for signaling, routing, and path 484 computation opens an OTN to security threats through attacks on those 485 protocols. The data plane technology for an OTN does not introduce 486 any specific vulnerabilities, and so the control plane may be secured 487 using the mechanisms defined for the protocols discussed. For 488 further details of the specific security measures refer to the 489 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 490 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 491 security vulnerabilities and protection mechanisms for the GMPLS 492 control plane. 494 4. IANA Considerations 496 TBD 498 5. References 500 5.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 5.2. Informative References 507 [I-D.kern-ccamp-rsvpte-hop-attributes] 508 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 509 intermediate hops using RSVP-TE", 510 draft-kern-ccamp-rsvpte-hop-attributes-00 (work in 511 progress), October 2009. 513 [I-D.ietf-ccamp-gmpls-g709-framework] 514 Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts, 515 M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE 516 Control of G.709 Optical Transport Networks", 517 draft-ietf-ccamp-gmpls-g709-framework-00 (work in 518 progress), April 2010. 520 Authors' Addresses 522 Xihua Fu 523 ZTE Corporation 525 Email: fu.xihua@zte.com.cn 527 Malcolm Betts 528 ZTE Corporation 530 Email: malcolm.betts@zte.com.cn 532 Ruiquan Jing 533 China Telecom 535 Email: jingrq@ctbri.com.cn 537 Xiaoli Huo 538 China Telecom 540 Email: huoxl@ctbri.com.cn