idnits 2.17.1 draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4206], [RFC5212]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2011) is 4676 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: 'RFC6001' is mentioned on line 507, but not defined == Missing Reference: 'RFC4873' is mentioned on line 286, but not defined == Missing Reference: 'RFC4874' is mentioned on line 491, but not defined == Missing Reference: 'RFC5920' is mentioned on line 597, but not defined == Unused Reference: 'RFC3209' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 640, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 5212 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-cl-requirement-04 == Outdated reference: A later version (-07) exists of draft-ceccarelli-ccamp-gmpls-ospf-g709-06 Summary: 3 errors (**), 0 flaws (~~), 12 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 Q. Wang 4 Intended status: Standards Track Y. Bao 5 Expires: January 9, 2012 ZTE Corporation 6 R. Jing 7 X. Huo 8 China Telecom 9 July 8, 2011 11 RSVP-TE Extension for MRN/MLN Application 12 draft-fuxh-ccamp-boundary-explicit-control-ext-03 14 Abstract 16 [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN). 17 [RFC4206] introduces a region boundary determination algorithm and a 18 Hierarchy LSP (H-LSP) creation method. However, in some scenarios, 19 there must be some additional information to facilitate hierarchy LSP 20 creation. This document extends RSVP-TE to meet this requirement. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 9, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 58 2. Requirement Identification . . . . . . . . . . . . . . . . . . 3 59 2.1. Indication of Server Layer . . . . . . . . . . . . . . . . 3 60 2.2. Requirement in OTN Multi-Layer Network . . . . . . . . . . 4 61 2.2.1. Indication of ODUk Signal Type . . . . . . . . . . . . 4 62 2.2.2. Indication of Multi Stages Multiplexing Hierarchy . . 4 63 3. Mechanism and Protocol Extensions . . . . . . . . . . . . . . 5 64 3.1. Controlling FA-LSPs Boundaries . . . . . . . . . . . . . . 5 65 3.1.1. Boundaries Determination . . . . . . . . . . . . . . . 6 66 3.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Explicit Route Boundary Object (ERBO) . . . . . . . . . . 7 68 3.2.1. Switching Capability subobject . . . . . . . . . . . . 8 69 3.2.2. Encoding Type subobject . . . . . . . . . . . . . . . 8 70 3.2.3. Signal Type subobject . . . . . . . . . . . . . . . . 9 71 3.2.4. Multiplexing Hierarchy subobject . . . . . . . . . . . 10 72 3.2.5. Signaling Procedure . . . . . . . . . . . . . . . . . 11 73 3.3. Exclude Route Object(XRO) . . . . . . . . . . . . . . . . 12 74 3.3.1. Encoding Type subobject . . . . . . . . . . . . . . . 12 75 3.3.2. Signal Type subobject . . . . . . . . . . . . . . . . 13 76 3.3.3. Multiplexing Hierarchy subobject . . . . . . . . . . . 13 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 This document describes some requirements of explicitly control 87 Multi-Region and Multi-Layer Network. It extends mechanisms and 88 protocols defined in [RFC4206] and [RFC6001] to meet these 89 requirement. 91 1.1. Conventions Used In This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Requirement Identification 99 2.1. Indication of Server Layer 101 [RFC4206] describes a region boundary determination algorithm and a 102 hierarchical LSP creation method. It is well applied to multi-region 103 network. However it isn't fully applied to multi-layer network 104 within the same switching capability. 106 In the following figure, three LSPs belong to the same TDM region and 107 different latyers, but boundary node (e.g., B) could not determine 108 that STM-N FA-LSP should be triggered according to the region 109 boundary determination algorithm defined in [RFC4206]. The solution 110 MUST support to explicitly indicate which server layer must be 111 triggered. 113 A B C D E F 114 +---+ STM-N +---+ STM-N +----+ OTUk +----+ STM-N +---+ STM-N +---+ 115 |VC4|-------|VC4|-------|ODUk|------|ODUk|-------|VC4|-------|VC4| 116 +---+ +---+ +----+ +----+ +---+ +---+ 118 |<-------------------------- VC4 LSP ------------------------->| 120 |<------------- STM-N LSP ------------>| 122 |<--ODUk LSP-->| 124 Figure 1: Example of Server Layer Indication 126 2.2. Requirement in OTN Multi-Layer Network 128 2.2.1. Indication of ODUk Signal Type 130 In Figure 2, node B and C in the OTN network are connected to 2.5G TS 131 network by two OTU3 links. They can support flexible multi stages 132 multiplexing hierarchies. There are two multi stages multiplexing 133 hierarchies for ODU0 being mapped into OTU3 link in B and C (i.e., 134 ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3). But boundary node (e.g., B) 135 could not determine which kind of ODUk FA-LSP (ODU1, ODU2 or ODU3) 136 should be triggered during one e2e ODU0 connection signaling 137 according to the region boundary determination algorithm defined in 138 [RFC4206]. 140 If path computation entity select the ODU0-ODU2-ODU3 multi stages 141 multiplexing hierarch in Node B and C for one end-to-end ODU0 service 142 from A to Z, there has to be an ODU2 or ODU3 FA-LSP between B and C. 143 The solution MUST support to explicitly indicate which type of ODUk 144 FA-LSP must be triggered for ODUj (k>j). 146 3/1/0 147 2/0 3/2/0 148 | _______ | 149 ___ _|_____ / \ _|_____ ___ 150 | A | | | B | | 40G | | | C | | Z | 151 | o-|-----------|-o o-|----| Network |----|-o o-|-----------|-o | 152 |___| OTU2 Link |_____|_|OTU3|(2.5G TS)|OTU3|_____|_| OTU2 Link |___| 153 (1.25G TS) | \_______/ | (1.25G TS) 154 | | 155 0/1/3 0/2 156 0/2/3 158 Figure 2 Example of ODUk Signal Type Indication 160 2.2.2. Indication of Multi Stages Multiplexing Hierarchy 162 In figure 2, if ODU3 FA-LSP will be triggered between B and C to 163 directly support one end-to-end ODU0 service from A to Z, B should be 164 informed which multi stages multiplexing hierarchy should be used for 165 ODU0 mapping into ODU3. So the solution MUST support to explicitly 166 indicate which multi stages multiplexing hierarchy must be applied to 167 a special interface. 169 3. Mechanism and Protocol Extensions 171 This section defines protocol mechanisms and extensions to achieve 172 the requirement described in the previous section. 174 o A generic boundaries determination mechanism is introduced first. 175 Path computation entity or interim LSR along one end-to-end LSP 176 which traverses multi-layer can rely on this mechnism to determine 177 the boundary nodes of FA-LSP. 179 o Path computation entity can determine regions' boundaries. After 180 PCE compute an end-to-end paths across multi-layer, the boundary 181 nodes and some limitation about how to create FA-LSP must be 182 inform to interim nodes during signaling. 184 A new object, Explicit Route Boundary Object(ERBO), is introduced 185 to explicitly indicate a pair of FA-LSP boundary nodes and some 186 attributes which indicates how to create FA-LSPs. 188 This document also introduces some new subobjects as part of the 189 XRO that explicitly indicate which Signal Type, Multiplexing 190 Hierarchy and Encoding Type have to be excluded before initiating 191 FA-LSP creation. 193 3.1. Controlling FA-LSPs Boundaries 195 The boundary determination mechanism in [RFC4206] depends on the 196 comparing of interface switching capabilities. For multi-layer 197 network within the same TDM switching capability, the comparing of 198 interface switching capabilities relies on the max LSP bandwidth of 199 interface. But one interface in OTN netowrk could support several 200 ODUk signal type, the max LSP bandwidth makes no any sense to path 201 computation entity. The mechanism in [RFC4206] isn't well applied to 202 OTN multi-layer network. The solution MUST support the boundaries 203 determination of ODUk FA-LSP. 205 This document introduces a generic mechanism to determine the 206 boundaries of FA-LSPs by using termination and switching capability 207 from IGP database. It can be applied to multi-layer network within 208 same switching capability (e.g, OTN network) and multi-region 209 network. So this mechanism is compatible with the one in [RFC4206]. 210 The switching and termination capability could be induced by IACD 211 [RFC6001] in multi-regin network. In OTN multi-layer network, the 212 switching and termiantion Capability [OTNv3-OSPF] is advertised by 213 using SCSI (Switch Capability Specific Information) within ISCD. 215 3.1.1. Boundaries Determination 217 Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, 218 node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i, 219 node-(i-1)] the interface that connects link-i to node-(i-1), and by 220 [link-i, node-i] the interface that connects link-i to node-i. 222 Suppose interface [link-(i+1), node-i] supports switching capability 223 of one signal type ST-x and termination capability of one signal type 224 ST-y. Interface [link-(i+1), node-(i+1)] supports switiching 225 capability of ST-y. Switching capability of ST-y (e.g., LSC) is 226 larger than ST-x (e.g., TDM/G.709) or ST-x (e.g., ODUj) could be 227 mapped into ST-y (e.g., ODUk (k>j)). So we say that the LSP has 228 crossed a region boundary at node-i. The 'other edge' of the region 229 with respect to the LSP path is node-k, where k is the smallest 230 number greater than i such that interface [link-k, node-(k-1)] 231 supports switching capability of ST-y and interface [link-k, node-k] 232 suuports switching capability of ST-x and termination capability of 233 ST-y. 235 3.1.2. Example 237 A multi-layer OTN network is illustrated in figure 3. Node B and D 238 support ODUj being mapping into ODUk (k>j). Interface IF-B and IF-D 239 support ODUj switching capability (ODUj(S)) and ODUk termination 240 capability (ODUk(T)). Interface within C only supports ODUk 241 switching capability. So Node B and D could be boundaries of ODUk 242 FA-LSP for ODUj LSP. 244 ODUj(S) ODUj(S) ODUk(S) ODUk(S) ODUj(S) 245 | | | | | | 246 __|_ _|___ _|_|_ ___|_ _|___ 247 | A| | | |B | | | | | | D| | | |E | 248 ...---|o o-|----|-o o-|----|-o o-|----|-o o-|----|-o o-|---... 249 |____| |___|_| |__C__| |_|___| |_____| 250 | | 251 |IF-B IF-D | 252 | | 253 ODUj(S)-- --ODUj(S) 254 \ / 255 | | 256 ODUk(T)<-/ \->ODUk(T) 258 Figure 3 Example of Controlling ODUk FA-LSPs Boundaries 260 A multi-region network is illustrated in figure 4. Node B and D 261 which are hybrid nodes support PSC being mapping into ODUk (e.g., by 262 GFP-F). Interface IF-B and IF-D support PSC switching capability 263 (PSC(S)) and ODUk termination capability (ODUk(T)). Interface within 264 C only supports ODUk switching capability. So Node B and D could be 265 boundaries of ODUk FA-LSP for PSC LSP. 267 PSC(S) PSC(S) ODUk(S) PSC(S) PSC(S) 268 | | | | | | 269 __|_ _|___ | | ___|_ _|___ 270 | A| | | |B | _|_|_ | | | | | 271 ...---|o o-|----|-o | | | | | | o-|----|-o o-|---... 272 |____| | o-|----|-o o-|----|-o | |_____| 273 |___|_| |_____| |_|___| 274 | | 275 |IF-B IF-D| 276 | | 277 PSC-ODUk IACD PSC-ODUK IACD 279 Figure 4 Example of Controlling ODUk FA-LSPs Boundaries 281 3.2. Explicit Route Boundary Object (ERBO) 283 In order to explicitly control hierarchy LSP creation, this document 284 introduce a new object (ERBO-Explicit Route Boundary Object) carried 285 in Path message. The format of ERBO object is the same as ERO. It 286 looks more like the SERO defined in [RFC4873]. 288 One or more ERBOs may be carried in Path message. Multiple ERBOs 289 could support cascading of FA easy. An ERBO must contain at least 290 two subobjects. The first and final one indicate the source and sink 291 node of a FA-LSP or Composite Link [CL-REQ] which will be passed by 292 one e2e LSP. Other subobjects may be inserted into ERBO between 293 source and sink node to indicates how to select the FA/Component Link 294 or create them. 296 The purpose is not to extend ERO and to limit the modifications to 297 existing RSVP-TE procedures. ERBO is a top object and parsed easy. 298 Many attributes could be inserted into ERBO in the future for other 299 requirements. 301 This document defines four subobjects (i.e., Switching Cap, Encoding 302 Type, Signal Type and Multiplexing Hierarchy) in ERBO. These 303 subobjects may be inserted into ERBO between source and sink node to 304 indicates how to select the FA/Component Link or create them. It is 305 very convenient to use these subobects independently or combine them. 307 For example, Signal Type and Multiplexing Hierarchy subobject are 308 enough for OTN multi-layer network application. 310 3.2.1. Switching Capability subobject 312 A new subobject, called the switching capability subobject, is 313 defined for use in the ERBO. The format of the switching capability 314 subobject is defined as follows: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |L| Type | Length | Reserved | Switching Cap | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 5 Switching Capability subobject in ERBO 324 o L-bit: 0 indicates that the attribute specified MUST be included. 325 1 indicates that the attribute specified SHOULD be included. 327 o Type: To be defined. 329 o Length: It is always 4. 331 o Switching Capability (SC): Indicates which corresponding server 332 layer should be triggered by the boundary node. The value of 333 switching capability is the same as the one in [RFC3471]. 335 3.2.2. Encoding Type subobject 337 A new subobject, called the encoding type subobject, is defined for 338 use in the ERBO. The format of the encoding type subobject is 339 defined as follows: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 |L| Type | Length | Reserved | Encoding Type | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 6 Encoding Type subobject in ERBO 349 o L-bit: 0 indicates that the attribute specified MUST be included. 350 1 indicates that the attribute specified SHOULD be included. 352 o Type: To be defined. 354 o Length: It is always 4. 356 o Encoding Type: It may need to further indicate which encoding type 357 (e.g., SDH/SONET or G.709 in TDM) should be triggered. It is the 358 same as the one in [RFC3471]. 360 3.2.3. Signal Type subobject 362 A new subobject, called the signal type subobject, is defined for use 363 in the ERBO. The format of the encoding type subobject is defined as 364 follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |L| Type | Length | Reserved | Signal Type | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 7 Signal Type subobject in ERBO 374 o L-bit: 0 indicates that the attribute specified MUST be included. 375 1 indicates that the attribute specified SHOULD be included. 377 o Type: To be defined. 379 o Length: It is always 4. 381 o Signal Type: If there are several sub-layers within one server 382 layer, it can further indicates which sub-layer should be 383 triggered by the boundary node. Following is the signal type in 384 OTN. 386 Value Type 387 ----- ---- 388 0 Not significant 389 1 ODU1 390 2 ODU2 391 3 ODU3 392 4 ODU4 393 5 ODU0 394 6 ODUflex 395 7 ODUflex(G.hao) 396 8 ODU2e 397 9 STM-1 398 10 STM-4 399 11 STM-16 400 12 STM-64 401 13-255 Reserved (for future use) 403 3.2.4. Multiplexing Hierarchy subobject 405 A new subobject, called the Multiplexing Hierarchy (MH) subobject, is 406 defined for use in the ERBO. The format of the multiplexing 407 hierarchy subobject is defined as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |L| Type | Length | Reserved | MH | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 8 Multiplexing Hierarchy subobject in ERBO 417 o L-bit: 0 indicates that the attribute specified MUST be included. 418 1 indicates that the attribute specified SHOULD be included. 420 o Type: To be defined. 422 o Length: It is always 4. 424 o Multiplexing Hierarchy (MH): It explicitly indicates the 425 multiplexing hierarchy used for boundary node to configure it to 426 the data plane and trigger one specific corresponding tunnel 427 creation. Following is the multiplexing hierarchy in current OTN. 429 Value Type 430 ----- ------ 431 0 ODU1-ODU0 432 1 ODU2-ODU0 433 2 ODU2-ODU1 434 3 ODU2-ODU1-ODU0 435 4 ODU2-ODUflex 436 5 ODU3-ODU0 437 6 ODU3-ODU1 438 7 ODU3-ODU1-ODU0 439 8 ODU3-ODU2 440 9 ODU3-ODU2-ODU0 441 10 ODU3-ODU2-ODU1 442 11 ODU3-ODU2-ODU1-ODU0 443 12 ODU3-ODU2-ODUflex 444 13 ODU3-ODUflex 445 14 ODU3-ODU2e 446 15 ODU4-ODU0 447 16 ODU4-ODU1 448 17 ODU4-ODU1-ODU0 449 18 ODU4-ODU2 450 19 ODU4-ODU2-ODU0 451 20 ODU4-ODU2-ODU1 452 21 ODU4-ODU2-ODU1-ODU0 453 22 ODU4-ODU2-ODUflex 454 23 ODU4-ODU3 455 24 ODU4-ODU3-ODU0 456 25 ODU4-ODU3-ODU1 457 26 ODU4-ODU3-ODU1-ODU0 458 27 ODU4-ODU3-ODU2 459 28 ODU4-ODU3-ODU2-ODU0 460 29 ODU4-ODU3-ODU2-ODU1 461 30 ODU4-ODU3-ODU2-ODU1-ODU0 462 31 ODU4-ODU3-ODU2-ODUflex 463 32 ODU4-ODU3-ODUflex 464 33 ODU4-ODU3-ODU2e 465 34 ODU4-ODUflex 466 35 ODU4-ODU2e 468 3.2.5. Signaling Procedure 470 In order to signal an end-to-end LSP across multi layer, the LSP 471 source node sends the RSVP-TE PATH message with ERO which indicates 472 LSP route and ERBO which indicates the LSP route boundary If. if 473 there are cascading FAs need to be created, there must be multiple 474 associated ERBOs. There must be nesting routing informatoin in ERO. 475 The first and final address of node in ERBO SHOULD also be listed in 476 the ERO. This ensures that they are along the LSP path. When a 477 interim node receives a PATH message, it will check ERBO to see if it 478 is the layer boundary node. If a interim node isn't a layer 479 boundary, it will process the PATH message as the normal one of 480 single layer LSP. If a interim node finds its address is in ERBO, it 481 is a layer boundary node. So it will directly extract another 482 boundary egress node from ERBO. If it is necessary, it must also 483 extract the server layer/sub-layer routing information from ERO based 484 on a pair of boundary node. Then the layer boundary node holds the 485 PATH message and selects or creates a server layer/sub-layer LSP 486 based on the detailed information of subobject carried in ERBO. 488 3.3. Exclude Route Object(XRO) 490 [RFC6001] introduce SC (Switching Capability) subobjects into XRO 491 [RFC4874] which enables (when desired) the explicit identification of 492 at least one switching capability to be excluded from the resource 493 selection process described multi-region signaling. This document 494 adds more subobjects into the XRO to make multi-region and multi- 495 layer signaling more flexible. 497 o Encoding Type: explicitly indicates the encoding type should be 498 excluded (e.g., SONET/SDH or G.709 in TDM). 500 o Signal Type (ST) : explicitly indicates at least one ODUk signal 501 type have to be excluded from the resource selection. 503 o Multiplexing Hierarchy (MH): explicitly indicates at least one MH 504 have to be excluded from the resource selection. 506 L bit and Attribute is the same as the Switching Capability (SC) 507 subobject defined in [RFC6001]. 509 3.3.1. Encoding Type subobject 511 A new subobject, called the encoding type subobject, is defined for 512 use in the XRO. The format of the encoding type subobject is defined 513 as follows: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 |L| Type | Length | Attribute | Encoding Type | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 9 Encoding Type subobject in XRO 523 o L-bit: 0 indicates that the attribute specified MUST be excluded. 524 1 indicates that the attribute specified SHOULD be avoided. 526 o Type: To be defined. 528 o Length: It is always 4. 530 o Attribute: 0 reserved value. 1 indicates that the specified 531 encoding type SHOULD be excluded or avoided with respect to the 532 preceding numbered or unnumbered interface subobject. 534 o Encoding Type: It indicates which Encoding Type has to excluded. 535 It is the same as the one in [RFC3471]. 537 3.3.2. Signal Type subobject 539 A new subobject, called the signal type subobject, is defined for use 540 in the XRO. The format of the encoding type subobject is defined as 541 follows: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |L| Type | Length | Attribute | Signal Type | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 10 Signal Type subobject in XRO 551 o L-bit: 0 indicates that the attribute specified MUST be excluded. 552 1 indicates that the attribute specified SHOULD be avoided. 554 o Type: To be defined. 556 o Length: It is always 4. 558 o Attribute: 0 reserved value. 1 indicates that the specified signal 559 type SHOULD be excluded or avoided with respect to the preceding 560 numbered or unnumbered interface subobject. 562 o Signal Type: It indicates which Signal Type has to be excluded. 563 The value of ST is the same as the one in ERBO. 565 3.3.3. Multiplexing Hierarchy subobject 567 A new subobject, called the Multiplexing Hierarchy (MH) subobject, is 568 defined for use in the XRO. The format of the multiplexing hierarchy 569 subobject is defined as follows: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |L| Type | Length | Attribute | MH | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 11 Multiplexing Hierarchy subobject in XRO 579 o L-bit: 0 indicates that the attribute specified MUST be excluded. 580 1 indicates that the attribute specified SHOULD be avoided. 582 o Type: To be defined. 584 o Length: It is always 4. 586 o Attribute: 0 reserved value. 1 indicates that the specified 587 multiplexing hierarchy SHOULD be excluded or avoided with respect 588 to the preceding numbered or unnumbered interface subobject. 590 o Multiplexing Hierarchy (MH): It explicitly indicates which MH has 591 to be excluded over a specified TE link, The value of multiplexing 592 hierarchy is the same as the one in ERBO. 594 4. Security Considerations 596 This document does not introduce any new security considerations from 597 the ones already detailed in [RFC5920] that describes the MPLS and 598 GMPLS security threats, the related defensive techniques, and the 599 mechanisms for detection and reporting. 601 5. IANA Considerations 603 TBD 605 6. References 607 6.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 613 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 614 Tunnels", RFC 3209, December 2001. 616 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 617 (GMPLS) Signaling Functional Description", RFC 3471, 618 January 2003. 620 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 621 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 622 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 624 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 625 of Generalized Multi-Protocol Label Switching (GMPLS)", 626 RFC 4203, October 2005. 628 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 629 Hierarchy with Generalized Multi-Protocol Label Switching 630 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 632 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 633 Element (PCE)-Based Architecture", RFC 4655, August 2006. 635 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 636 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 637 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 638 July 2008. 640 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 641 (PCE) Communication Protocol (PCEP)", RFC 5440, 642 March 2009. 644 6.2. Informative References 646 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 647 Link", draft-ietf-rtgwg-cl-requirement-04 . 649 [OTNv3-OSPF] 650 D. Ceccarelli, "Traffic Engineering Extensions to OSPF for 651 Generalized MPLS (GMPLS) Control of Evolving G.709 OTN 652 Networks", draft-ceccarelli-ccamp-gmpls-ospf-g709-06 . 654 Authors' Addresses 656 Xihua Fu 657 ZTE Corporation 659 Email: fu.xihua@zte.com.cn 660 Qilei Wang 661 ZTE Corporation 663 Email: wang.qilei@zte.com.cn 665 Yuanlin Bao 666 ZTE Corporation 668 Email: bao.yuanlin@zte.com.cn 670 Ruiquan Jing 671 China Telecom 673 Email: jingrq@ctbri.com.cn 675 Xiaoli Huo 676 China Telecom 678 Email: huoxl@ctbri.com.cn