idnits 2.17.1 draft-zhang-ccamp-gmpls-h-lsp-mln-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4206], [RFC6001], [RFC6107]), 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 == Line 319 has weird spacing: '... mapped into ...' == Line 472 has weird spacing: '... Length and i...' -- The document date (July 11, 2013) is 3941 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: 'RFC4874' is mentioned on line 482, but not defined == Missing Reference: 'RFC 4206' is mentioned on line 403, but not defined == Missing Reference: 'RFC3477' is mentioned on line 481, but not defined == Missing Reference: 'RFC4873' is mentioned on line 482, but not defined == Missing Reference: 'RFC5520' is mentioned on line 482, but not defined == Missing Reference: 'RFC5553' is mentioned on line 482, but not defined == Unused Reference: 'RFC3945' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'OTN-ctrl' is defined on line 602, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5212 ** Downref: Normative reference to an Informational RFC: RFC 5339 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-gmpls-signaling-g709v3-08 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-lsp-attribute-ro-01 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Xian Zhang 3 Category: Standards Track Huawei 4 O. Gonzalez de Dios 5 Telefonica Investigacion y Desarrollo 6 C. Margaria. C 7 Coriant 8 Expires: January 10, 2014 July 11, 2013 10 GMPLS-based Hierarchy LSP Creation 11 in Multi-Region and Multi-Layer Networks 13 draft-zhang-ccamp-gmpls-h-lsp-mln-05.txt 15 Abstract 17 This specification describes the hierarchical LSP creation models in 18 the Multi-Region and Multi-Layer Networks (MRN/MLN), and provides the 19 extensions to the existing protocol mechanisms described in [RFC4206], 20 [RFC6107] and [RFC6001] to create a hierarchical LSP in multiple 21 layer networks. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January 10, 2014. 46 Table of Contents 48 1. Introduction ................................................ 2 49 1.1. Conventions used in this document .......................3 50 2. Provisioning of FA-LSP in Server Layer Network ...............3 51 2.1. Selection of Switching Layers........................... 3 52 2.2. Selection of Switching Granularity Levels ...............4 53 2.3. Selection of Adaptation Capabilities ....................6 54 3. Signaling Requirements for Server Layer Selection ............7 55 3.1. Model 1: Pre-provisioning of FA-LSP .....................8 56 3.2. Model 2: Signaling triggered server layer path computation 57 and setup ................................................... 9 58 3.3. Model 3: Signaling triggered server layer path, with explicit 59 server path ................................................. 9 60 4. Signaling Extensions ERO Sub-Object .........................10 61 4.1. SERVER_LAYER_INFO ERO Subobject ........................10 62 4.2. Processing of SERVER_LAYER_INFO sub-object .............12 63 4.3. Alternative Encoding Solutions .........................12 64 5. Security Considerations..................................... 13 65 6. IANA Considerations ........................................ 13 66 7. Acknowledgments ............................................ 13 67 8. References ................................................. 13 68 8.1. Normative References................................... 13 69 8.2. Informative Reference.................................. 14 70 9. Authors' Addresses ......................................... 15 72 1. Introduction 74 Networks may comprise multiple layers which have different switching 75 technologies or different switching granularity levels. The GMPLS 76 technology is required to support control of such network. 78 [RFC5212] defines the concept of MRN/MLN and describes the framework 79 and requirements of GMPLS controlled MRN/MLN. The GMPLS extension for 80 MRN/MLN, including routing and signaling aspects, is described in 81 [RFC6001]. 83 [RFC4206] and [RFC6107] describe how to set up a hierarchical LSP 84 passing through multi-layer networks and how to advertise the 85 forwarding adjacency LSP (FA-LSP) created in the server layer network 86 as a TE link via GMPLS signaling and routing protocols. 88 Based on these existing standards, this document further describes 89 the provisioning of a FA-LSP when the region-edge nodes support 90 multiple interface switching capabilities and/or multiple switching 91 granularities and/or adaptation functions, and then provides the 92 extensions to the RSVP-TE protocol in order to set up a hierarchical 93 LSP according to the modes of hierarchical LSP provisioning. 95 1.1. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Provisioning of FA-LSP in Server Layer Network 103 2.1. Selection of Switching Layers 105 As described in [RFC5212], the edge node of a region always has 106 multiple Interface Switching Capabilities (ISCs), i.e., it contains 107 multiple matrices which may be connected to each other by internal 108 links. Nodes with multiple ISCs are further classified as "simplex" 109 or "hybrid" nodes by [RFC5212] and [RFC5339], where the simplex node 110 advertises several TE links each with a single ISC value carried in 111 its ISCD sub-TLV, while the hybrid node advertises a single TE link 112 containing more than one ISCD each with a different ISC value. An 113 example of a hybrid node with a link having multiple ISCs is shown in 114 Figure 1, copied from [RFC5339]. 116 Network element 117 ............................. 118 : -------- : 119 : | PSC | : 120 : | | : 121 : --|#a | : 122 : | | #b | : 123 : | -------- : 124 : | | : 125 : | ---------- : 126 : /| | | #c | : 127 : | |-- | | : 128 Link1 ========| | | TDM | : 129 : | |----|#d | : 130 : \| ---------- : 131 :............................ 133 Figure 1 - Hybrid node (Copied from [RFC5339]) 135 In the case where a edge node of a region is a hybrid node, selection 136 of which server layer to create the FA-LSP is necessary. 138 Figure 2 shows an multi-layer network, where node B and C are region 139 edge nodes having three switching matrices which support, for 140 instance, PSC, TDM and WDM switching, respectively. The three 141 switching matrices are connected to each other by the internal links. 142 Both the link between B and E and the link between E and C support 143 TDM and WDM switching capabilities. 145 +-------+ +------------+ +------------+ +-------+ 146 | +---+ | | +---+ | FA | +---+ | | +---+ | 147 | |PSC+-+--+---+PSC|....|...................|....|PSC+---+--+-+PSC| | 148 | +---+ | | +-+-+-+ | | +-+-+-+ | | +---+ | 149 +-------+ | | | | | | | | +-------+ 150 Node A | | | | +-------------+ | | | | Node D 151 | | +-+-+ | | +---+ | | +-+-+ | | 152 | | |TDM|+ | | +|TDM|+ | | +|TDM| | | 153 | | +-+-+| | | |+-+-+| | | |+-+-+ | | 154 | | | ||\ | | /|| | ||\ | | /|| | | | 155 | | | +| || || |+ | +| || || |+ | | | 156 | +-+-+-+ | |====| | +-+-+ | |====| | +-+-+-+ | 157 | |WDM|-| || || |-|WDM|-| || || |-|WDM| | 158 | +---+ |/ | | \| +---+ |/ | | \| +---+ | 159 +------------+ +-------------+ +------------+ 160 Node B Node E Node C 162 Figure 2 - MLN with multiple ISCs at edge node 164 As can be seen in Figure 2, there are two choices when providing FA 165 in the PSC layer network between node B and C: one is creating a FA- 166 LSP with TDM switching matrix through node B, E and C, the other is 167 creating a FA-LSP with WDM switching matrix through node B, E and C. 169 [RFC6001] introduces a new SC (Switching Capability) sub-object into 170 the XRO (ref. to [RFC4874]). This sub-object is used to indicate 171 which switching capability is not expected to be used. When one of 172 the switching capabilities is selected, the SC sub-object can be 173 included in the message to exclude all other SCs. 175 2.2. Selection of Switching Granularity Levels 177 Even in the case where the edge node only has one switching 178 capability in the server layer, there may be still multiple choices 179 for the server layer network to set up a FA-LSP to provide new FA in 180 the client layer network. This is because the server layer network 181 may have the capability of providing different switching granularity 182 levels for the FA-LSP. 184 +-------+ +---------+ +---------+ +-------+ 185 | +---+ | | +---+ | FA | +---+ | | +---+ | 186 | |PSC|-+---+--+PSC|..|.......................|..|PSC+--+---+-|PSC| | 187 | +---+ | | +-+-+ | | +-+-+ | | +---+ | 188 +-------+ | | | ODU1/ ODU1/ | | | +-------+ 189 Node A | | | ODU2/ +-------+ ODU2/ | | | Node D 190 | +-+-+ | ODU3 | +---+ | ODU3 | +-+-+ | 191 | |TDM+--+-------+-+TDM+-+-------+--+TDM| | 192 | +---+ | | +---+ | | +---+ | 193 +---------+ +-------+ +---------+ 194 Node B Node E Node C 196 Figure 3a - Multiple switching granularities in server layer 198 Figure 3a shows an example multi-region network, where the edge node 199 B and C have PSC and TDM switching matrices, and where the TDM 200 switching matrix supports ODU1, ODU2 and ODU3 switching levels. 201 Therefore, when an FA between node B and C in the PSC layer network 202 is needed, either of ODU1, ODU2 or ODU3 connection (FA-LSP) can be 203 created in the TDM layer network. 205 |<----------------------- ODU0 Connection ----------------------->| 206 | | 207 ++------+ +---------+ +---------+ +------++ 208 | +---+ | | +---+ | FA (ODU1/2/3) | +---+ | | +---+ | 209 | |TDM|-+---+--+ |..|.......................|..| +--+---+-|TDM| | 210 | +---+ | | | | | | | | | | +---+ | 211 +-------+ | |TDM| | +-------+ | |TDM| | +-------+ 212 Node A | | | | OTU3 | +---+ | OTU3 | | | | Node D 213 | | +--+-------+-+TDM+-+-------+--+ | | 214 | +---+ | | +---+ | | +---+ | 215 ++--------+ +-------+ +--------++ 216 |Node B Node E Node C | 217 | | 218 |<--------- FA LSP (ODU1/2/3)------------>| 220 Figure 3b - TDM nested LSP provisioning 222 Figure 3b is another example multi-layer network within the same 223 region. When there is a need to set up an FA between node B and C for 224 the client layer ODU0 connection, the server layer has multiple 225 choices, e.g., ODU1 or ODU2 or ODU3, for the FA-LSP if the multi- 226 stage multiplexing is supported at node B and C. 228 |<---------------- Client layer LSP (Bandwidth 1) --------------->| 229 | | 230 ++------+ +---------+ +---------+ +------++ 231 | +---+ | | +---+ | FA | +---+ | | +---+ | 232 | |PSC|-+---+--+ |..|.......................|..| +--+---+-|PSC| | 233 | +---+ | | | | | | | | | | +---+ | 234 +-------+ | |PSC| | +-------+ | |PSC| | +-------+ 235 Node A | | | | | +---+ | | | | | Node D 236 | | +--+-------+-+PSC+-+-------+--+ | | 237 | +---+ | | +---+ | | +---+ | 238 ++--------+ +-------+ +--------++ 239 |Node B Node E Node C | 240 | | 241 |<--- Service layer LSP (Bandwidth 2) --->| 243 Figure 3c - PSC nested LSP provisioning 245 Figure 3c is a third example showing an LSP nesting scenario in a PSC 246 signal-layer network (e.g., an MPLS-TP network). A PSC tunnel passing 247 through node B, E and C is requested to carry the client layer LSP. 248 There are multiple choices of the bandwidth of the tunnel, on the 249 premise that the bandwidth of the FA-LSP is equal to or larger than 250 the client layer LSP. 252 The selection of server layer switching matrix and switching 253 granularity is based on both policy and bandwidth resources. The 254 selection can be performed by a planning tool and/or NMS/PCE/VNTM 255 (Virtual Network Topology Manager, see [RFC5623]) and/or the network 256 node. 258 2.3. Selection of Adaptation Capabilities 260 Adaptation function also needs to be selected when creating the 261 server layer connection. This is because the edge nodes may support 262 multiple adaptation functions. 264 +-------+ +-----------+ +---------+ +-------+ 265 | +---+ | | +---+ | FA | +---+ | | +---+ | 266 | |PSC|-+---+---+PSC|...|.....................|..|PSC+--+---+-|PSC| | 267 | +---+ | | +---+ | | +-+-+ | | +---+ | 268 +-------+ |___|_ _|___| | __|__ | +-------+ 269 Node A |\_A_/ \_B_/| | \_A_/ | Node D 270 | | | | +-------+ | | | 271 | +---+ | | +---+ | | +-+-+ | 272 | |TDM+---+------+-+TDM+-+------+--+TDM| | 273 | +---+ | | +---+ | | +---+ | 274 +-----------+ +-------+ +---------+ 275 Node B Node E Node C 277 _____ _____ 278 \_A_/: Adaptation_Function_A; \_B_/: Adaptation_Function_B; 280 Figure 4 - Selection of adaptation function 282 For example, in Figure 4, edge node B supports two adaptation 283 functions, i.e., adaptation_function_A and adaptation_function_B, 284 while edge node C only supports adaptation_function_A. In this case, 285 only adaptation_function_A can be used for the server layer 286 connection. 288 The Call procedure ([RFC4974]) may be used between edge node B and C 289 to negotiate and determine the adaptation function for the server 290 layer if the Call function is supported. 292 3. Signaling Requirements for Server Layer Selection 294 [RFC5623], the framework of PCE-based MLN, provides the models of 295 cross-layer LSP path computation and creation, which are listed below: 297 - Inter-Layer Path Computation Models: 299 o Single PCE 301 o Multiple PCE with inter-PCE 303 o Multiple PCE without inter-PCE 305 - Inter-Layer Path Control Models: 307 o PCE-VNTM cooperation 308 o Higher-layer signaling trigger 310 o NMS-VNTM cooperation (integrated flavor) 312 o NMS-VNTM cooperation (separate flavor) 314 This section keeps alignment with [RFC5623] except that the 315 restriction of using a PCE for path computation is not necessary 316 (i.e., other element, such as a network node, may also have path 317 computation capability). 319 In this document, those models in [RFC4206] are mapped into 3 models 320 on the viewpoint of signaling: 322 - Model 1: Pre-provisioning of FA-LSP 324 - Model 2: Signaling triggered server layer path computation and 325 setup 327 - Model 3: Signaling triggered server layer path, with explicit 328 server path. 330 3.1. Model 1: Pre-provisioning of FA-LSP 332 In this model, the FA-LSP in the server layer is created before 333 initiating the signaling of the client layer LSP. Two typical 334 scenarios using this model are: 336 - Network planning and building at the stage of client network 337 initialization. 339 - NMS/VNTM triggering the creation of FA-LSP when computing the path 340 of client layer LSP. The path control models of PCE-VNTM 341 cooperation and NMS-VNTM cooperation (both integrated and separate 342 flavor) in [RFC5623] belong to this scenario. 344 In such case, the server layer selection and path computation is 345 performed by planning tool or NMS/PCE/VNTM or the edge node. The 346 signaling of client layer LSP and server layer FA-LSP are separated. 347 The normal LSP creation procedures ([RFC3471] and [RFC3473]) are 348 followed to set up these two LSPs and no new extension is required. 350 3.2. Model 2: Signaling triggered server layer path computation and 351 setup 353 In this model, the source node of client layer LSP only computes the 354 route within its own layer network. When the signaling of the client 355 layer LSP reaches at the region edge node, the edge node performs 356 server layer FA-LSP path computation and then creates the FA-LSP. 357 When a PCE is introduced to perform path computation in each layer of 358 the multi-layer network, this model is the same as the model of 359 "higher-layer signaling trigger with Multiple PCE without inter-PCE" 360 in [RFC5623]. 362 In such case, the edge node will receive the client layer PATH 363 message with a loose ERO indicating an FA is requested, and may 364 perform the server layer selection (e.g., through the server layer 365 PCE or the VNTM) and then compute and set up the FA-LSP. The 366 signaling procedure of client layer LSP and server layer FA-LSP is 367 described in detail in [RFC4206] and [RFC6107]. 369 It's possible that the source node of the client layer LSP selects 370 the server layer SC and/or granularity and/or adaptation function 371 when performing path computation in the client layer, and requests or 372 suggests the edge node to use an appointed server layer to create the 373 FA-LSP. 375 In this case, the XRO including SC sub-object ([RFC6001]) is adopted 376 for the server layer SC exclusion, which can be used indirectly to 377 select server layer SC. Such solution is not straightforward enough. 378 Furthermore it cannot be used for the selection of server layer 379 granularity and adaptation function. Therefore, new extensions for 380 the selection of server layer SC, switching granularity and 381 adaptation function are required. 383 3.3. Model 3: Signaling triggered server layer path, with explicit 384 server path 386 In this model, the source node of the client layer LSP performs a 387 full path computation including the client layer and the server layer 388 routes. The server layer FA-LSP creation is triggered at the edge 389 node by the client layer LSP signaling. When a PCE is introduced to 390 perform path computation in the multi-layer network, this model is 391 the same as the model of "Higher-layer signaling trigger with Single 392 PCE" or "Higher-layer signaling trigger with Multiple PCE with inter- 393 PCE" in [RFC5623]. 395 In such case, the server layer selection and server layer path 396 computation is performed at the source node of the client layer LSP 397 (e.g., through VNTM or PCE), but not at the edge node. 399 In [RFC4206], the ERO which contains the list of nodes and links 400 (including the client layer and server layer) along the path is used 401 in the client layer PATH message. The edge node can find out the tail 402 end of the FA-LSP based on the switching capability of the node using 403 the IGP database (see session 6.2 of [RFC 4206]). 405 Similar to the problem of model 2, the edge node is not aware of 406 which switching granularity and which adaptation function to be 407 selected for the FA-LSP because the ERO and/or XRO do not contain 408 such information. Therefore, the edge node may not be able to create 409 the FA-LSP, or may select another switching granularity by itself 410 which is different from the one selected previously at the source 411 node, which makes the creation of hierarchy LSP out of control. 413 Therefore, new extensions for the selection of server layer SC, 414 switching granularity and adaptation function are also required in 415 this model. 417 4. Signaling Extensions ERO Sub-Object 419 4.1. SERVER_LAYER_INFO ERO Subobject 421 In order to solve the problems described in the previous sections, a 422 new sub-object named SERVER_LAYER_INFO sub-object is introduced in 423 this document, which is carried in the ERO and is used to explicitly 424 indicate which server layer to create the FA-LSP. 426 The SERVER_LAYER_INFO sub-object is put immediately after the node or 427 link (interface) address sub-object, indicating the related node is a 428 region edge node on the LSP in the ERO. 430 The format of the SERVER_LAYER_INFO sub-object is shown below: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |L| Type | Length |M| Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | LSP Enc. Type |Switching Type | G-PID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Traffic Spec Length | TSpec Type | Reserved | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Traffic Parameters | 442 ~ ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 [Editor's note: the encoding is still under discussion.] 447 - L bit: MUST be zero and MUST be ignored when received. 449 - Type: The SERVER_LAYER_INFO sub-object has a type of xx (TBD). 451 - Length: The total length of the sub-object in bytes, including the 452 Type and Length fields. The value of this field is always a 453 multiple of 4. 455 - M (Mandatory) bit: When set, it means the edge node MUST set up 456 the FA-LSP in the appointed server layer; otherwise, the appointed 457 server layer is suggested and the edge node may select other 458 server layer by local policy. 460 - LSP Encoding Type, Switching Type and G-PID: These 3 fields are 461 used to point out which switching layer is requested to set up the 462 FA-LSP. The values of these 3 fields are inherited from the 463 Generalized Label Request Object in GMPLS signaling, referring to 464 [RFC3471], [RFC3473] and other related standards and drafts. Note 465 that G-PID can be used to indicate the payload type of the server 466 layer (i.e., the client signal) as well as the adaptation function 467 for adapting the client signal into the server layer FA-LSP. 469 - Traffic Spec Length, TSpec Type, Traffic Parameters: The traffic 470 parameters field is used to indicate the switching granularity of 471 the FA-LSP. The format of this field depends on the TSpec Type 472 Traffic Spec Length and is consistent with the existing standards 473 and drafts. For example, the traffic parameters of Ethernet, 474 SONET/SDH and OTN are defined in [RFC6003], [RFC4606] and [OTN- 475 ctrl] respectively. 477 4.2. Processing of SERVER_LAYER_INFO sub-object 479 As described in RFC3209 and RFC3473 the ERO is managed as a sub- 480 object list. The SERVER_LAYER_INFO sub-object MUST be appended after 481 the existing sub-object defined in [RFC3209], [RFC3473], [RFC3477], 482 [RFC4873], [RFC4874], [RFC5520] and [RFC5553] TBD:extensions. 484 When a node receives a PATH message containing ERO and finds that 485 there is a SERVER_LAYER_INFO sub-object immediately after the node or 486 link address sub-object related to itself, the node determines that 487 it's a region edge node. Then, the edge node finds out the server 488 layer selection information from the sub-object: 490 - Determine the switching layer by the LSP Encoding Type and 491 Switching Type fields; 493 - Determine the switching granularity of the FA-LSP by the Traffic 494 Parameters field; 496 - Determine the adaptation function for adapting the client signal 497 into the server layer FA-LSP by the G-PID field. 499 The edge node MUST then determine the other edge of the region, i.e., 500 the tail end of the FA-LSP, with respect to the subsequence of hops 501 of the ERO. The node that satisfies the following conditions will be 502 treated as the tail end of the FA-LSP: 504 - There is a SERVER_LAYER_INFO sub-object that immediately follows 505 the node or link address sub-object which is related to that node; 507 - The LSP Encoding Type, Switching Type, G-PID and the Traffic 508 Parameters fields of this SERVER_LAYER_INFO sub-object is the same 509 as the SERVER_LAYER_INFO sub-object corresponding to the head end; 511 - The node is the first one that satisfies the two conditions above 512 in the subsequence of hops of the ERO. 514 If a match of tail end is found, the head end now has the clear 515 server layer information of the FA-LSP and then initiates an RSVP-TE 516 session to create the FA-LSP in the appointed server layer between 517 the head end and the tail end. 519 4.3. Alternative Encoding Solutions 521 [Editor's note: the section is still under discussion.] 522 A first alternative solution is to use the mechanism defined in [LSP- 523 RO], i.e., create an ERO HOP attribute TLV. 525 The content and procedure are not changed from the previous section. 527 5. A second alternative solution aims to simplify the SERVER_LAYER_INFO 528 processing by using the SERO mechanisms. This can be a new 529 requirements to the SERO or to the ERO Hop attribute. This 530 alternative is not further described here but mentioned for 531 discussions. 533 6. Security Considerations 535 TBD. 537 7. IANA Considerations 539 TBD. 541 8. Acknowledgments 543 TBD. 545 9. References 547 9.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 553 (GMPLS) Architecture", RFC 3945, October 2004. 555 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 556 Tunnels", RFC3209, December 2001. 558 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 559 Switching (GMPLS) Signaling Functional Description", RFC 560 3471, January 2003. 562 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 563 Switching (GMPLS) Signaling Resource ReserVation 564 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 565 3473, January 2003. 567 [RFC5212] K. Shiomoto et al, "Requirements for GMPLS-Based Multi- 568 Region and Multi-Layer Networks (MRN/MLN)", RFC5212, July 569 2008. 571 [RFC5339] JL. Le Roux et al, "Evaluation of Existing GMPLS 572 Protocols against Multi-Layer and Multi-Region Networks 573 (MLN/MRN)", RFC5339, September 2008. 575 [RFC4206] K. Kompella et al, "Label Switched Paths (LSP) Hierarchy 576 with Generalized Multi-Protocol Label Switching (GMPLS) 577 Traffic Engineering (TE)", RFC4206, October 2005. 579 [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically 580 Signaled Hierarchical Label Switched Paths", RFC6107, 581 February 2011. 583 [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol 584 Label Switching (GMPLS) Protocol Extensions for Multi- 585 Layer and Multi-Region Networks (MLN/MRN)", RFC6001, 586 October, 2010. 588 9.2. Informative Reference 590 [RFC4974] D. Papadimitriou and A. Farrel, "Generalized MPLS (GMPLS) 591 RSVP-TE Signaling Extensions in Support of Calls", 592 RFC4974, August 2007. 594 [RFC5623] E. Oki et al, "Framework for PCE-Based Inter-Layer MPLS 595 and GMPLS Traffic Engineering", RFC 5623, September 2009. 597 [RFC4606] E. Mannie, D. Papadimitriou, "Generalized Multi-Protocol 598 Label Switching (GMPLS) Extensions for Synchronous 599 Optical Network (SONET) and Synchronous Digital Hierarchy 600 (SDH) Control", RFC 4606, August 2006. 602 [OTN-ctrl] Fatai Zhang et al, "Generalized Multi-Protocol Label 603 witching (GMPLS) Signaling Extensions for the evolving 604 G.709 Optical Transport Networks Control", draft-ietf- 605 ccamp-gmpls-signaling-g709v3-08.txt, April, 2013. 607 [RFC6003] D. Papadimitriou, "Ethernet Traffic Parameters", RFC6003, 608 October, 2010. 610 [LSP-RO] Margaria, C., Giovanni, G., et al, "draft-ietf-ccamp-lsp- 611 attribute-ro', draft-ietf-ccamp-lsp-attribute-ro-01.txt, 612 work I progress; 614 10. Authors' Addresses 616 Fatai Zhang 617 Huawei Technologies 618 F3-1B R&D Center, Huawei Base 619 Bantian, Longgang District 620 Shenzhen 518129 P.R.China 622 Phone: +86-755-28972603 623 Email: zhangfatai@huawei.com 625 Xian Zhang 626 Huawei Technologies 627 F3-1B R&D Center, Huawei Base 628 Bantian, Longgang District 629 Shenzhen 518129 P.R.China 631 Phone: +86-755-28972645 632 Email: huawei.danli@huawei.com 634 Yi Lin 635 Huawei Technologies Co., Ltd. 636 F3-1B R&D Center, Huawei Base 637 Bantian, Longgang District 638 Shenzhen 518129 P.R.China 640 Phone: +86-755-28972597 641 Email: yi.lin@huawei.com 643 Oscar Gonzalez de Dios 644 Telefonica Investigacion y Desarrollo 645 Emilio Vargas 6 646 Madrid, 28045 Spain 648 Phone: +34 913374013 649 Email: ogondio@tid.es 650 Cyril Margaria 651 Coriant GmbH 652 St Martin Strasse 76 653 Munich, 81541 654 Germany 656 Phone: +49 89 5159 16934 657 Email: cyril.margaria@coriant.com 659 Intellectual Property 661 The IETF Trust takes no position regarding the validity or scope of 662 any Intellectual Property Rights or other rights that might be 663 claimed to pertain to the implementation or use of the technology 664 described in any IETF Document or the extent to which any license 665 under such rights might or might not be available; nor does it 666 represent that it has made any independent effort to identify any 667 such rights. 669 Copies of Intellectual Property disclosures made to the IETF 670 Secretariat and any assurances of licenses to be made available, or 671 the result of an attempt made to obtain a general license or 672 permission for the use of such proprietary rights by implementers or 673 users of this specification can be obtained from the IETF on-line IPR 674 repository at http://www.ietf.org/ipr 676 The IETF invites any interested party to bring to its attention any 677 copyrights, patents or patent applications, or other proprietary 678 rights that may cover technology that may be required to implement 679 any standard or specification contained in an IETF Document. Please 680 address the information to the IETF at ietf-ipr@ietf.org. 682 The definitive version of an IETF Document is that published by, or 683 under the auspices of, the IETF. Versions of IETF Documents that are 684 published by third parties, including those that are translated into 685 other languages, should not be considered to be definitive versions 686 of IETF Documents. The definitive version of these Legal Provisions 687 is that published by, or under the auspices of, the IETF. Versions of 688 these Legal Provisions that are published by third parties, including 689 those that are translated into other languages, should not be 690 considered to be definitive versions of these Legal Provisions. 692 For the avoidance of doubt, each Contributor to the IETF Standards 693 Process licenses each Contribution that he or she makes as part of 694 the IETF Standards Process to the IETF Trust pursuant to the 695 provisions of RFC 5378. No language to the contrary, or terms, 696 conditions or rights that differ from or are inconsistent with the 697 rights and licenses granted under RFC 5378, shall have any effect and 698 shall be null and void, whether published or posted by such 699 Contributor, or included with or in such Contribution. 701 Disclaimer of Validity 703 All IETF Documents and the information contained therein are provided 704 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 705 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 706 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 707 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 708 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 709 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 710 FOR A PARTICULAR PURPOSE. 712 Copyright Notice 714 Copyright (c) 2013 IETF Trust and the persons identified as the 715 document authors. All rights reserved. 717 This document is subject to BCP 78 and the IETF Trust's Legal 718 Provisions Relating to IETF Documents 719 (http://trustee.ietf.org/license-info) in effect on the date of 720 publication of this document. Please review these documents 721 carefully, as they describe your rights and restrictions with respect 722 to this document. Code Components extracted from this document must 723 include Simplified BSD License text as described in Section 4.e of 724 the Trust Legal Provisions and are provided without warranty as 725 described in the Simplified BSD License.