idnits 2.17.1 draft-fuxh-ccamp-boundary-explicit-control-ext-02.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 (March 29, 2011) is 4776 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) == Unused Reference: 'RFC3209' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-gmpls-mln-extensions' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-cl-requirement' is defined on line 425, 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-00 Summary: 3 errors (**), 0 flaws (~~), 9 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: September 30, 2011 ZTE Corporation 6 R. Jing 7 X. Huo 8 China Telecom 9 March 29, 2011 11 RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in A 12 GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) 13 draft-fuxh-ccamp-boundary-explicit-control-ext-02 15 Abstract 17 [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN). 18 [RFC4206] introduces a region boundary determination algorithm and a 19 Hierarchy LSP (H-LSP) creation method. However, in some scenarios, 20 some attributes have to be attached with the boundary nodes in order 21 to explicit control the hierarchy LSP creation. This document 22 extends GMPLS signaling protocol for the requirement of explicit 23 control the hierarchy LSP creation. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 30, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 61 2. Explicit Route Boundary Object (ERBO) . . . . . . . . . . . . 3 62 2.1. Switching Capability subobject . . . . . . . . . . . . . . 3 63 2.2. Encoding Type subobject . . . . . . . . . . . . . . . . . 4 64 2.3. Signal Type subobject . . . . . . . . . . . . . . . . . . 4 65 2.4. Multiplexing Hierarchy subobject . . . . . . . . . . . . . 5 66 2.5. Signaling Procedure . . . . . . . . . . . . . . . . . . . 7 67 3. XRO Subobjects . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Encoding Type subobject . . . . . . . . . . . . . . . . . 7 69 3.2. Signal Type subobject . . . . . . . . . . . . . . . . . . 8 70 3.3. Multiplexing Hierarchy subobject . . . . . . . . . . . . . 8 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN). 81 [RFC4206] introduces a region boundary determination algorithm and a 82 Hierarchy LSP (H-LSP) creation method. However, in some scenarios, 83 some attributes have to be attached with the boundary nodes in order 84 to explicitly control the hierarchy LSP creation. This document 85 extends GMPLS signaling protocol for the requirement of explicit 86 control the hierarchy LSP creation. 88 1.1. Conventions Used In This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Explicit Route Boundary Object (ERBO) 96 In order to explicitly control hierarchy LSP creation, this document 97 introduce a new object (ERBO-Explicit Route Boundary Object) carried 98 in Path message. The format of ERBO object is the same as ERO. It 99 looks more like the SERO defined in rfc4873. 101 One or more ERBOs may be carried in Path message. Multiple ERBOs 102 could support cascading of FA easy. An ERBO must contain at least 103 two subobjects. The first and final one indicate the source and sink 104 node of a FA-LSP or Composite Link. Other subobjects may be inserted 105 into ERBO between source and sink node to indicates how to select the 106 FA/Component Link or create them. 108 2.1. Switching Capability subobject 110 A new subobject, called the switching capability subobject, is 111 defined for use in the ERBO. The format of the switching capability 112 subobject is defined as follows: 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 |L| Type | Length | Reserved | Switching Cap | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 4 Switching Capability subobject in ERBO 122 o L-bit: 0 indicates that the attribute specified MUST be included. 123 1 indicates that the attribute specified SHOULD be included. 125 o Type: To be defined. 127 o Length: It is always 4. 129 o Switching Capability (SC): Indicates which corresponding server 130 layer should be triggered by the boundary node. The value of 131 switching capability is the same as the one in [RFC3471]. 133 2.2. Encoding Type subobject 135 A new subobject, called the encoding type subobject, is defined for 136 use in the ERBO. The format of the encoding type subobject is 137 defined as follows: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |L| Type | Length | Reserved | Encoding Type | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 5 Encoding Type subobject in ERBO 147 o L-bit: 0 indicates that the attribute specified MUST be included. 148 1 indicates that the attribute specified SHOULD be included. 150 o Type: To be defined. 152 o Length: It is always 4. 154 o Encoding Type: It may need to further indicate which encoding type 155 (e.g., SDH/SONET or G.709 in TDM) should be triggered. It is the 156 same as the one in [RFC3471]. 158 2.3. Signal Type subobject 160 A new subobject, called the signal type subobject, is defined for use 161 in the ERBO. The format of the encoding type subobject is defined as 162 follows: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |L| Type | Length | Reserved | Signal Type | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 6 Signal Type subobject in ERBO 172 o L-bit: 0 indicates that the attribute specified MUST be included. 173 1 indicates that the attribute specified SHOULD be included. 175 o Type: To be defined. 177 o Length: It is always 4. 179 o Signal Type: If there are several sub-layers within one server 180 layer, it can further indicates which sub-layer should be 181 triggered by the boundary node. Following is the signal type in 182 OTN. 184 Value Type 185 ----- ---- 186 0 Not significant 187 1 ODU1 188 2 ODU2 189 3 ODU3 190 4 ODU4 191 5 ODU0 192 6 ODUflex 193 7 ODUflex(G.hao) 194 8 ODU2e 195 9-255 Reserved (for future use) 197 2.4. Multiplexing Hierarchy subobject 199 A new subobject, called the Multiplexing Hierarchy (MH) subobject, is 200 defined for use in the ERBO. The format of the multiplexing 201 hierarchy subobject is defined as follows: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |L| Type | Length | Reserved | MH | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 7 Multiplexing Hierarchy subobject in ERBO 211 o L-bit: 0 indicates that the attribute specified MUST be included. 212 1 indicates that the attribute specified SHOULD be included. 214 o Type: To be defined. 216 o Length: It is always 4. 218 o Multiplexing Hierarchy (MH): It explicitly indicates the 219 multiplexing hierarchy used for boundary node to configure it to 220 the data plane and trigger one specific corresponding tunnel 221 creation. Following is the multiplexing hierarchy in current OTN. 223 Value Type 224 ----- ------ 225 0 ODU1-ODU0 226 1 ODU2-ODU0 227 2 ODU2-ODU1 228 3 ODU2-ODU1-ODU0 229 4 ODU2-ODUflex 230 5 ODU3-ODU0 231 6 ODU3-ODU1 232 7 ODU3-ODU1-ODU0 233 8 ODU3-ODU2 234 9 ODU3-ODU2-ODU0 235 10 ODU3-ODU2-ODU1 236 11 ODU3-ODU2-ODU1-ODU0 237 12 ODU3-ODU2-ODUflex 238 13 ODU3-ODUflex 239 14 ODU3-ODU2e 240 15 ODU4-ODU0 241 16 ODU4-ODU1 242 17 ODU4-ODU1-ODU0 243 18 ODU4-ODU2 244 19 ODU4-ODU2-ODU0 245 20 ODU4-ODU2-ODU1 246 21 ODU4-ODU2-ODU1-ODU0 247 22 ODU4-ODU2-ODUflex 248 23 ODU4-ODU3 249 24 ODU4-ODU3-ODU0 250 25 ODU4-ODU3-ODU1 251 26 ODU4-ODU3-ODU1-ODU0 252 27 ODU4-ODU3-ODU2 253 28 ODU4-ODU3-ODU2-ODU0 254 29 ODU4-ODU3-ODU2-ODU1 255 30 ODU4-ODU3-ODU2-ODU1-ODU0 256 31 ODU4-ODU3-ODU2-ODUflex 257 32 ODU4-ODU3-ODUflex 258 33 ODU4-ODU3-ODU2e 259 34 ODU4-ODUflex 260 35 ODU4-ODU2e 262 2.5. Signaling Procedure 264 In order to signal an end-to-end LSP across multi layer, the LSP 265 source node sends the RSVP-TE PATH message with ERO which indicates 266 LSP route and ERBO which indicates the LSP route boundary. The first 267 and final address of node in ERBO SHOULD also be listed in the ERO. 268 This ensures that they are along the LSP path. When a interim node 269 receives a PATH message, it will check ERBO to see if it is the layer 270 boundary node. If a interim node isn't a layer boundary, it will 271 process the PATH message as the normal one of single layer LSP. If a 272 interim node finds its address is in ERBO, it is a layer boundary 273 node. So it will directly extract another boundary egress node and 274 other detail subobject infomration (e.g., Latency) from ERBO. If it 275 is necessary, it will also extract the server layer/sub-layer routing 276 information from ERO based on a pair of boundary node. Then the 277 layer boundary node holds the PATH message and selects or creates a 278 server layer/sub-layer LSP based on the detailed information of 279 subobject carried in ERBO. 281 3. XRO Subobjects 283 3.1. Encoding Type subobject 285 A new subobject, called the encoding type subobject, is defined for 286 use in the XRO. The format of the encoding type subobject is defined 287 as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |L| Type | Length | Attribute | Encoding Type | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 8 Encoding Type subobject in XRO 297 o L-bit: 0 indicates that the attribute specified MUST be excluded. 298 1 indicates that the attribute specified SHOULD be avoided. 300 o Type: To be defined. 302 o Length: It is always 4. 304 o Attribute: 0 reserved value. 1 indicates that the specified 305 encoding type SHOULD be excluded or avoided with respect to the 306 preceding numbered or unnumbered interface subobject. 308 o Encoding Type: It may need to further indicate which encoding type 309 have to excluded. It is the same as the one in [RFC3471]. 311 3.2. Signal Type subobject 313 A new subobject, called the signal type subobject, is defined for use 314 in the XRO. The format of the encoding type subobject is defined as 315 follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |L| Type | Length | Attribute | Signal Type | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 9 Signal Type subobject in XRO 325 o L-bit: 0 indicates that the attribute specified MUST be excluded. 326 1 indicates that the attribute specified SHOULD be avoided. 328 o Type: To be defined. 330 o Length: It is always 4. 332 o Attribute: 0 reserved value. 1 indicates that the specified signal 333 type SHOULD be excluded or avoided with respect to the preceding 334 numbered or unnumbered interface subobject. 336 o Signal Type: It indicates which sub-layers have to be excluded. 337 The value of ST is the same as the one in ERBO. 339 3.3. Multiplexing Hierarchy subobject 341 A new subobject, called the Multiplexing Hierarchy (MH) subobject, is 342 defined for use in the XRO. The format of the multiplexing hierarchy 343 subobject is defined as follows: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |L| Type | Length | Attribute | MH | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure Multiplexing Hierarchy subobject in XRO 353 o L-bit: 0 indicates that the attribute specified MUST be excluded. 354 1 indicates that the attribute specified SHOULD be avoided. 356 o Type: To be defined. 358 o Length: It is always 4. 360 o Attribute: 0 reserved value. 1 indicates that the specified 361 multiplexing hierarchy SHOULD be excluded or avoided with respect 362 to the preceding numbered or unnumbered interface subobject. 364 o Multiplexing Hierarchy (MH): It explicitly indicates which MHs 365 have to be excluded over a specified TE link, The value of 366 multiplexing hierarchy is the same as the one in ERBO. 368 4. Security Considerations 370 TBD 372 5. IANA Considerations 374 TBD 376 6. References 378 6.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 384 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 385 Tunnels", RFC 3209, December 2001. 387 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 388 (GMPLS) Signaling Functional Description", RFC 3471, 389 January 2003. 391 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 392 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 393 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 395 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 396 of Generalized Multi-Protocol Label Switching (GMPLS)", 397 RFC 4203, October 2005. 399 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 400 Hierarchy with Generalized Multi-Protocol Label Switching 401 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 403 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 404 Element (PCE)-Based Architecture", RFC 4655, August 2006. 406 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 407 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 408 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 409 July 2008. 411 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 412 (PCE) Communication Protocol (PCEP)", RFC 5440, 413 March 2009. 415 6.2. Informative References 417 [I-D.ietf-ccamp-gmpls-mln-extensions] 418 Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 419 D., and J. Roux, "Generalized Multi-Protocol Label 420 Switching (GMPLS) Protocol Extensions for Multi-Layer and 421 Multi-Region Networks (MLN/MRN)", 422 draft-ietf-ccamp-gmpls-mln-extensions-12 (work in 423 progress), February 2010. 425 [I-D.ietf-rtgwg-cl-requirement] 426 Ning, S., Malis, A., McDysan, D., Yong, L., JOUNAY, F., 427 and Y. Kamite, "Requirements for MPLS Over a Composite 428 Link", draft-ietf-rtgwg-cl-requirement-00 (work in 429 progress), February 2010. 431 Authors' Addresses 433 Xihua Fu 434 ZTE Corporation 435 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 436 Xi An 710065 437 P.R.China 439 Phone: +8613798412242 440 Email: fu.xihua@zte.com.cn 441 URI: http://wwwen.zte.com.cn/ 442 Qilei Wang 443 ZTE Corporation 444 No.68 ZiJingHua Road,Yuhuatai District 445 Nanjing 210012 446 P.R.China 448 Phone: +8613585171890 449 Email: wang.qilei@zte.com.cn 450 URI: http://www.zte.com.cn/ 452 Yuanlin Bao 453 ZTE Corporation 454 5/F, R.D. Building 3, ZTE Industrial Park, Liuxian Road 455 Shenzhen 518055 456 P.R.China 458 Phone: +86 755 26773731 459 Email: bao.yuanlin@zte.com.cn 460 URI: http://www.zte.com.cn/ 462 Ruiquan Jing 463 China Telecom 465 Email: jingrq@ctbri.com.cn 467 Xiaoli Huo 468 China Telecom 470 Email: huoxl@ctbri.com.cn