idnits 2.17.1 draft-fuxh-ccamp-boundary-explicit-control-ext-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2010) is 4930 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 502, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-gmpls-mln-extensions' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-cl-requirement' is defined on line 544, 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 (~~), 10 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: April 28, 2011 ZTE Corporation 6 R. Jing 7 X. Huo 8 China Telecom 9 October 25, 2010 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-01 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 April 28, 2011. 42 Copyright Notice 44 Copyright (c) 2010 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. Requirement of Explicit Control of Hierarchy LSP Creation . . 3 62 2.1. Selection of Server Layer/Sub-Layer . . . . . . . . . . . 3 63 2.2. Selection/Creation of FA-LSP based on characteristics 64 of server layer . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Configuration of Multi Stages Multipelxing Hierarchy . . . 5 66 3. Explicit Route Boundary Object (ERBO) . . . . . . . . . . . . 6 67 3.1. Server Layer/Sub-Layer Attributes TLV . . . . . . . . . . 8 68 3.2. Multiplexing Hierarchy Attribute TLV . . . . . . . . . . . 9 69 3.3. Latency Attribute TLV . . . . . . . . . . . . . . . . . . 10 70 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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. Requirement of Explicit Control of Hierarchy LSP Creation 96 2.1. Selection of Server Layer/Sub-Layer 98 [RFC4206] describes a region boundary determination algorithm and a 99 hierarchical LSP creation method. This region boundary determination 100 algorithm and LSP creation method are well applied to Multi-Region 101 Network. However it isn't fully applied to Multi-Layer Network. In 102 the following figure, three LSPs belong to the same TDM region and 103 different latyers, but the sub-layer boundary node could not 104 determine which lower layer should be triggered according to the 105 region boundary determination algorithm defined in [RFC4206]. Thus 106 the higher layer (VC4 in figure 1) signaling can't trigger the lower 107 layer (STM-N in figure 1) LSP creation. It needs to explicitly 108 describe which sub-layer should be triggered in the signaling 109 message. 111 A B C D E F 112 +---+ STM-N +---+ STM-N +----+ OTUk +----+ STM-N +---+ STM-N +---+ 113 |VC4|-------|VC4|-------|ODUk|------|ODUk|-------|VC4|-------|VC4| 114 +---+ +---+ +----+ +----+ +---+ +---+ 116 |<-------------------------- VC4 LSP ------------------------->| 118 |<------------- STM-N LSP ------------>| 120 |<--ODUk LSP-->| 122 Figure 1: Example of Server Layer/Sub-Layer Selection 124 2.2. Selection/Creation of FA-LSP based on characteristics of server 125 layer 127 ITU-T G.800 defines Composite Link. Individual component links in a 128 composite link may be supported by different transport technologies 129 such as OTN, MPLS-TP or SDH/SONET. Even if the transport technology 130 implementing the component links is identical, the characteristics 131 (e.g., latency) of the component links may differ. Operator may 132 prefer its traffic to be transported over a specific transport 133 technology server layer. Further more, operator may prefer its 134 traffic to be transported over a specific transport technology 135 component link with some specific characteristics (e.g.,latency). So 136 it desires to explicitly control the component link selection based 137 on the attributes (e.g., switching capability and latency) attached 138 with the boundary nodes during the signaling. 140 Latency is a key requirement for service provider. Restoration 141 and/or protection can impact "provisioned" latency. The key driver 142 for this is stock/commodity trading applications that use data base 143 mirroring. A few delicacy can impact a transaction. Therefore 144 latency and latency SLA is one of the key parameters that these "high 145 value" customers use to select a private pipe line provider. So it 146 desires to explicitly convey latency SLA to the boundary nodes where 147 the hierarchy LSP will be triggered. 149 ___ ___ 150 MPLS-based LSP | | | | 151 o-----o-----o-----|-o | | o-|-----o-----o-----o 152 | | | | 153 | |OTN FA-LSP with latency 1| | 154 | o-|-------------------------|-o | 155 | | | | 156 | |OTN FA-LSP with latency 2| | 157 | o-|-------------------------|-o | 158 | . | . | . | 159 | . | . | . | 160 | . | . | . | 161 | |OTN FA-LSP with latency n| | 162 | o-|-------------------------|-o | 163 |___| |___| 165 Figure 2: Example of FA-LSP Selection/Creation based on Latency 167 In Figure 2, a LSP traffic is over a composite link whose component 168 links with different latency characteristic are supported by OTN. In 169 order to meet the latency SLA, it needs to explicitly limit the 170 latency between boundary nodes to create an OTN tunnel. 172 2.3. Configuration of Multi Stages Multipelxing Hierarchy 174 In Figure 3, node B and C in the OTN network are connected to 2.5G TS 175 network by two OTU3 link. They can support flexible multi stages 176 multiplexing hierarchies. There are two multi stages multiplexing 177 hierarchies for ODU0 being mapped into OTU3 link in B and C of Figure 178 1 (i.e., ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3). So path computation 179 entity has to determine which kind of multi stages multiplexing 180 hierarchies should be used for the end-to-end ODU0 service and the 181 type of tunnel (FA-LSP). In Figure 3, if path computation entity 182 select the ODU0-ODU2-ODU3 multi stages multiplexing hierarch in Node 183 B and C for one end-to-end ODU0 service from A to Z, there has to be 184 an ODU2 tunnel between B and C. The selection of multi stages 185 multiplexing hierarchies is based on the operator policy and the 186 equipment capability. How to select the multiplexing hierarchies is 187 the internal behavior of path computation entity. 189 ODU1-ODU3 190 ODU2-ODU3 191 ODU0-ODU2 ODU0-ODU1-ODU3 192 ODU1-ODU2 ODU0-ODU2-ODU3 193 ODUflex-ODU2 ODUflex-ODU2-ODU3 194 | _______ | 195 ___ _|_____ / \ _|_____ ___ 196 | A | | | B | | 40G | | | C | | Z | 197 | o-|-----------|-o o-|----| Network |----|-o o-|-----------|-o | 198 |___| OTU2 Link |_____|_| |(2.5G TS)| |_____|_| OTU2 Link |___| 199 (1.25G TS) | \_______/ | (1.25G TS) 200 | | 201 ODU0-ODU1-ODU3 ODU0-ODU2 202 ODU0-ODU2-ODU3 ODU1-ODU2 203 ODUflex-ODU2-ODU3 ODUflex-ODU2 204 ODU1-ODU2-ODU3 205 ODU1-ODU3 206 ODU2-ODU3 208 Figure 3 Example of Multi-Stages Multiplexing Hierarchy Selection 210 If path computation entity select the ODU0-ODU2-ODU3 for ODU0 being 211 mapped into OTU3 Link, the multi stages multiplexing hierarchy has to 212 be carried in signaling message to node B and C. After B receives the 213 signaling message, it will triggered a creation of and ODU2 FA-LSP 214 base on [RFC4206] and the selection of multi stages multiplexing 215 hierarchy. Node B and C must config this kind of multi stages 216 multiplexing hierarchy (i.e., ODU0-ODU2-ODU3) to its data plane. So 217 data plane can multplex and demultiplex the ODU0 signal from/to ODU3 218 for a special end-to-end ODU0 service in terms of the control plane's 219 configuration. 221 In Figure 4, the switching capability (e.g., TDM), switching 222 granuality (i.e., ODU3) and multi stages multiplexing hierarchy 223 (ODU0-ODU1-ODU3-ODU4) must be specified during signaling. Because 224 the switching capability (TDM) and switching granuality (ODU3) 225 information is not enough for data plane to know ODU0 is mapped into 226 ODU3 tunnel by ODU0-ODU1-ODU3 then ODU4. In order to explicit 227 specify multi stages multiplexing hierarchy, the switching 228 capability, switching granuality and multi stages multiplexing 229 hierarchy (ODU0-ODU1-ODU3) must be carried in the signaling message. 231 2|0 0|2 2|0 0|1|3|4 4|3 3|4 4|3|1|0 0|2 2|0 0|2 232 _______ _______ _______ _______ _______ 233 | A | | B | | C | | E | | F | 234 -|-o o-|------|-o o-|------|-o o-|------|-o o-|------|-o o-|- 235 |_______| |_______| |_______| |_______| |_______| 237 ODU3 Tunnel 238 ODU0 Service ----------------------- 239 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 240 ----------------------- 242 Figure 4 Example of Multi-Stages Multiplexing Hierarchy Selection 244 3. Explicit Route Boundary Object (ERBO) 246 In order to explicitly control hierarchy LSP creation, this document 247 introduce a new object (ERBO- Explicit Route Boundary Object) carried 248 in RSVP-TE message. The format of ERBO object is the same as ERO. 249 The ERBO including the region boundaries information and some 250 specific attributes (e.g., latency) can be carried in Path message. 251 One pairs or multiple pairs of nodes within the ERBO can belong to 252 the same layer or different layers. 254 This document introduce a new sub-object (BOUNDARY_ATTRIBUTES) carry 255 the attributes of the associated hop specified in the ERBO. It 256 allows the specification and reporting of attributes relevant to a 257 particular hop of the signaled LSP. It follows an IPv4 or IPv6 258 prefix or unnumbered Interface ID sub-object in ERBO. A list of 259 attribute TLV can be inserted into ERBO. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |0| Type | Length | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 ~ Attribute TLVs ~ 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 5 Format of BOUNDARY_ATTRIBUTES 273 - This field indicates different attribute TLV sub-objects. 275 - The total length of the sub-object in bytes, including the Type 276 and Length fields. The value of this field is always a multiple 277 of 4. 279 - Attribute TLVs: This field carries different TLV according to the 280 Type filed. 282 A list of attributes TLV can be inserted into ERBO. These attributes 283 may represent the following information. It can be further extended 284 to carry other specific requirement in the future. 286 - Server Layer (e.g., PSC, L2SC, TDM, LSC, FSC) or Sub-Layer (e.g., 287 VC4, VC11, VC4-4c, VC4-16c, VC4-64c, ODU0, ODU1, ODU2, ODU3, ODU4) 288 used for boundary node to trigger one specific corresponding 289 server layer or Sub-Layer FA-LSP creation. The region boundary 290 node may support multiple interface switching capabilities and 291 multiple switching granularities. It is very useful to indicate 292 which server layer and/or sub-layer to be used at the region 293 boundary node. 295 - Multiplexing hierarchy (e.g., ODU0-ODU1-ODU3-ODU4) used for 296 boundary node to configure it to the data plane and trigger one 297 specific corresponding tunnel creation. 299 - Server Layer and/or Sub-Layer's LSP Latency SLA (e.g., minimum 300 latency value, maximum latency value, average latency value and 301 latency variation value). Boundary node select a FA or create a 302 FA-LSP based on the latency limitation. 304 The format of the Attributes TLV is as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type(IANA) | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 // Attribute Specific Information // 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 The following types are supported. 318 Type | Information 319 ------+------------------------------- 320 TBD | server layer/sub-layer 321 TBD | server layer/sub-layer characteristics (e.g., latency) 322 TBD | multi stage multiplexing hierarchy 324 3.1. Server Layer/Sub-Layer Attributes TLV 326 Switching capabilities and switching granularities of the region 327 boundary can be carried in Attribute TLV. With these information 328 carried in the RSVP-TE path message, the region boundary node can 329 directly trigger one corresponding server layer or sub-layer FA-LSP 330 creation which is defined in the Attribute TLV. The format of the 331 Attribute TLV is shown below. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type(IANA) | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Server Layer | Sub-Layer | Reserve | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 o Type: indicates different values of Attribute TLV. 343 o Length: indicates the total length of this Attribute TLV value. 345 o Server Layer: Indicates which corresponding server layer should be 346 triggered by the boundary node. The value of server layer is the 347 same as the switching capability [RFC3471]. 349 o Sub-Layer: If there are several sub-layers within one server 350 layer, it can further indicates which sub-layer should be 351 triggered by the boundary node. 353 * SDH/SONET: VC4, VC11, VC12, VC4-4c, VC4-16c, VC4-64c. 355 * OTN: ODU0, ODU1, ODU2, ODU3, ODU2e, ODU4, and so on 357 3.2. Multiplexing Hierarchy Attribute TLV 359 Multiplexing Hierarchy Attribute TLV indicates the multiplexing 360 hierarchies (e.g., ODU0-ODU2-ODU3) used for boundary node to 361 configure it to the data plane and trigger one specific corresponding 362 tunnel creation. The type of this sub-TLV will be assigned by IANA, 363 and length is eight octets. The value field of this sub-TLV contains 364 multi stages multiplexing hierachies constraint information of the 365 link port. 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 (IANA) | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | F | Number | Reserve |MSMH 1 | ...MSMC 1... | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |MSMH 2 | ...MSMC 2... | ... | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |MSMH M | ...MSMC M... | padding | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 o F (2 bits): Indicates the multi stages multiplexing hierarchies 380 are included or excluded. 382 * 0 - Inclusive Multiplexing Hierarchies:Indicates that the 383 object/TLV contains one or more multi stages multiplexing 384 hierarchies which can be supported. 386 * 1 - Exclusive Multiplexing Hierarchies:Indicates that the 387 object/TLV contains one or more multi stages multiplexing 388 hierarchies which can't be supported. 390 o Number (8 bits): Indicates the total nunmber of multi stages 391 multiplexing hierarchies which are supported or prohibited by the 392 link port. 394 o Reserve (8 bits): for future use. 396 o (MSMH 1, MSMC 1), (MSMH 2, MSMC 2), ... ,(MSMH M, MSMC M): 397 Indicates each multi stages multiplexing capability detailed 398 information. 400 * MSMH 1, MSMH2, ... , MSMH M (4 bits): Indicates the numbers of 401 Multi Stages Multiplexing Hierarchies (MSMH). 403 + MSMH = 1: It indicates ODUi is mapped into ODUk (k > i) by 404 single stage multiplexing (e.g., ODU0-ODU3). 406 + MSMH > 1: It indicates ODUi is mapped into ODUk (k > i) by 407 multi stages multiplexing (e.g., ODU0-ODU1-ODU3). 409 * MSMC 1, MSMC 2, ... ,MSMC M: Indicates the detailed information 410 of multi stages multiplexing capability. The length of Multi 411 Stages Multiplexing Capability (MSMC) information depends on 412 the multi stages multiplexing hierarchies (MSMH). The length 413 of MSMC is (MSMH+1) * 4. Each ODUk (k=1, 2, 3, 4, 2e, flex) is 414 indicated by 4 bits. Following is the Signal Type for G.709 415 Amendment 3. 417 Value Type 418 ----- ---- 419 0000 ODU0 420 0001 ODU1 421 0010 ODU2 422 0011 ODU3 423 0100 ODU4 424 0101 ODU2e 425 0110 ODUflex 426 7-15 Reserved (for future use) 428 o The padding is used to make the Multi Stages Multiplexing 429 Capability Descriptor sub-TLV 32-bits aligned. 431 3.3. Latency Attribute TLV 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type(IANA) | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Minimum Latency Value | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Maximum Latency Value | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Average Latency Value | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Latency Variation Value | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 - Minimum Latency Value: a minimum value indicates the latency 448 performance parameters which server layer/sub-layer LSP must meet. 450 - Maximum Latency Value: a maximum value indicates the latency 451 performance parameters which server layer/sub-layer LSP must meet. 453 - Average Latency Value: a average value indicates the latency 454 performance parameters which server layer/sub-layer LSP must meet. 456 - Latency Variation Value: a variation value indicates the latency 457 performance parameters which server layer/sub-layer LSP must meet. 459 4. Signaling Procedure 461 In order to signal an end-to-end LSP across multi layer, the LSP 462 source node sends the RSVP-TE PATH message with ERO which indicates 463 LSP route and ERBO which indicates the LSP route boundary. When a 464 interim node receives a PATH message, it will check ERBO to see if it 465 is the layer boundary node. If a interim node isn't a layer 466 boundary, it will process the PATH message as the normal one of 467 single layer LSP. If a interim node finds its address is in ERBO, it 468 is a layer boundary node. So it will directly extract another 469 boundary egress node and other detail Attribute TLV infomration 470 (e.g., Latency) from ERBO. If it is necessary, it will also extract 471 the server layer/sub-layer routing information from ERO based on a 472 pair of boundary node. Then the layer boundary node holds the PATH 473 message and selects or creates a server layer/sub-layer LSP based on 474 the detailed information of Attribute TLV (e.g., Latency) carried in 475 ERBO. 477 On reception of a Path message containing BOUNDARY_ATTRIBUTES whose 478 type of Attributes TLV is Multi States Multiplexing Hierarchy Sub- 479 TLV, The interim node checks the local data plane capability to see 480 if this kind of multi stages multiplexing/demultiplexing hierarchy is 481 acceptable on specific interface. As there is an acceptable kind of 482 multi stages multiplexing/demultiplexing, it must determin an ODUk 483 tunnel must be created between a pair of boundary node. The kind of 484 multi stages multiplexing/demultiplexing hierarchy must be configed 485 into the data plane. 487 5. Security Considerations 489 TBD 491 6. IANA Considerations 493 TBD 495 7. References 497 7.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 503 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 504 Tunnels", RFC 3209, December 2001. 506 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 507 (GMPLS) Signaling Functional Description", RFC 3471, 508 January 2003. 510 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 511 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 512 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 514 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 515 of Generalized Multi-Protocol Label Switching (GMPLS)", 516 RFC 4203, October 2005. 518 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 519 Hierarchy with Generalized Multi-Protocol Label Switching 520 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 522 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 523 Element (PCE)-Based Architecture", RFC 4655, August 2006. 525 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 526 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 527 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 528 July 2008. 530 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 531 (PCE) Communication Protocol (PCEP)", RFC 5440, 532 March 2009. 534 7.2. Informative References 536 [I-D.ietf-ccamp-gmpls-mln-extensions] 537 Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 538 D., and J. Roux, "Generalized Multi-Protocol Label 539 Switching (GMPLS) Protocol Extensions for Multi-Layer and 540 Multi-Region Networks (MLN/MRN)", 541 draft-ietf-ccamp-gmpls-mln-extensions-12 (work in 542 progress), February 2010. 544 [I-D.ietf-rtgwg-cl-requirement] 545 Ning, S., Malis, A., McDysan, D., Yong, L., JOUNAY, F., 546 and Y. Kamite, "Requirements for MPLS Over a Composite 547 Link", draft-ietf-rtgwg-cl-requirement-00 (work in 548 progress), February 2010. 550 Authors' Addresses 552 Xihua Fu 553 ZTE Corporation 554 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 555 Xi An 710065 556 P.R.China 558 Phone: +8613798412242 559 Email: fu.xihua@zte.com.cn 560 URI: http://wwwen.zte.com.cn/ 562 Qilei Wang 563 ZTE Corporation 564 No.68 ZiJingHua Road,Yuhuatai District 565 Nanjing 210012 566 P.R.China 568 Phone: +8613585171890 569 Email: wang.qilei@zte.com.cn 570 URI: http://www.zte.com.cn/ 572 Yuanlin Bao 573 ZTE Corporation 574 5/F, R.D. Building 3, ZTE Industrial Park, Liuxian Road 575 Shenzhen 518055 576 P.R.China 578 Phone: +86 755 26773731 579 Email: bao.yuanlin@zte.com.cn 580 URI: http://www.zte.com.cn/ 581 Ruiquan Jing 582 China Telecom 584 Email: jingrq@ctbri.com.cn 586 Xiaoli Huo 587 China Telecom 589 Email: huoxl@ctbri.com.cn