idnits 2.17.1 draft-zhang-ccamp-gmpls-uni-app-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 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UNI PLUS' is mentioned on line 468, but not defined == Missing Reference: 'SLRG-FA' is mentioned on line 684, but not defined == Unused Reference: 'RFC3209' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'RFC6107' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'RFC5339' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'RFC5441' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC5623' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'Call-ext' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'RFC6344' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'UNI-PLUS' is defined on line 1114, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-07 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-rsvp-te-srlg-collect-02 == Outdated reference: A later version (-04) exists of draft-fedyk-ccamp-uni-extensions-00 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-lsp-diversity-01 == Outdated reference: A later version (-05) exists of draft-ali-ccamp-rc-objective-function-metric-bound-02 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-te-metric-recording-01 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Fatai Zhang 2 Internet Draft Huawei 3 Category: Informational O. Gonzalez de Dios 4 Telefonica Investigacion y Desarrollo 5 A. Farrel 6 Old Dog Consulting 7 Xian Zhang 8 Huawei 9 D. Ceccarelli 10 Ericsson 11 Expires: August 13, 2014 February 14, 2014 13 Applicability of Generalized Multiprotocol Label Switching (GMPLS) 14 User-Network Interface (UNI) 16 draft-zhang-ccamp-gmpls-uni-app-05.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 13, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents carefully, 50 as they describe your rights and restrictions with respect to this 51 document. Code Components extracted from this document must include 52 Simplified BSD License text as described in Section 4.e of the Trust 53 Legal Provisions and are provided without warranty as described in 54 the Simplified BSD License. 56 Abstract 58 Generalized Multiprotocol Label Switching (GMPLS) defines a set of 59 protocols for the creation of Label Switched Paths (LSPs) in various 60 switching technologies. The GMPLS User-Network Interface (UNI) was 61 developed in RFC4208 in order to be applied to an overlay network 62 architectural model. 64 This document examines a number of GMPLS UNI application scenarios. 65 It shows how techniques developed after the GMPLS UNI can be applied 66 to automate or enable critical processes for these applications. This 67 document also suggests simple extensions that could be made to 68 existing technologies to further enable the UNI and points out some 69 unresolved issues. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. UNI Addressing .............................................. 5 75 3. UNI Auto Discovery .......................................... 7 76 4. UNI Path Computation......................................... 8 77 4.1. UNI Link Selection...................................... 8 78 5. Additional Parameters across UNI............................ 11 79 5.1. Constrained Path Computation........................... 11 80 5.2. Collection Requests over UNI........................... 11 81 6. UNI Path Provisioning Models................................ 12 82 6.1. Flat Model ............................................ 12 83 6.2. Stitching Model........................................ 13 84 6.3. Session Shuffling Model................................ 13 85 6.4. Hierarchal Model....................................... 14 86 7. UNI Recovery ............................................... 15 87 7.1. End-to-end Recovery.................................... 15 88 7.1.1. Serial Provisioning of Working and Protection Paths15 89 7.1.2. Concurrent Computation of Working and Protection Path16 90 7.2. Segment Recovery....................................... 17 91 8. UNI Call ................................................... 18 92 8.1. Exchange of UNI Link Information ....................... 18 93 8.2. Control of Call Route.................................. 18 94 9. UNI Multicast .............................................. 19 95 9.1. UNI Multicast Connection Model ........................ 19 96 9.2. UNI Multicast Connection Provisioning ................. 21 97 10. Security Considerations.................................... 22 98 11. IANA Considerations........................................ 22 99 12. Acknowledgments ........................................... 22 100 13. References ................................................ 22 101 13.1. Normative References.................................. 22 102 13.2. Informative References................................ 24 103 14. Contributors' Address...................................... 26 104 15. Authors' Addresses ........................................ 27 106 1. Introduction 108 Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a 109 set of protocols, including Open Shortest Path Fist - Traffic 110 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 111 Traffic Engineering (RSVP-TE) [RFC3473], which can be used to create 112 Label Switched Paths (LSPs) in a number of deployment scenarios with 113 various transport technologies. 115 The User-Network Interface (UNI) reference point is defined in the 116 Automatically Switched Optical Network (ASON) [G.8080]. According to 117 [G.8080], the UNI may be implemented as a peering between a client- 118 side entity (UNI-C) and a network-side entity (UNI-N). End-to-end 119 connectivity between UNI-C nodes is achieved across the core network 120 by three components: a UNI request from source UNI-C to source UNI-N; 121 a core network connection from source UNI-N to destination UNI-N; and 122 a UNI request from destination UNI-N to destination UNI-C. 124 The GMPLS overlay model, as per [RFC4208], can be applied at the UNI, 125 as shown in Figure 1. 127 Overlay Overlay 128 Network +----------------------------------+ Network 129 +---------+ | | +---------+ 130 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 131 | | | | UNI | | | | | | | | UNI | | | | 132 | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 133 | | | | +--+--+ | | | | | | | | | | 134 | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | 135 +---------+ | | | | | | +---------+ 136 | | | | | | 137 +---------+ | | +--+--+ | +--+--+ | +---------+ 138 | +----+ | | | | | +-------+ | | | +----+ | 139 | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | 140 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 141 | | | | UNI | +-----+ +-----+ | UNI | | | | 142 | +----+ | | | | +----+ | 143 +---------+ +----------------------------------+ +---------+ 144 Overlay Core Network Overlay 145 Network Network 147 Legend: EN - Edge Node 148 CN - Core Node 150 Figure 1 - Applying GMPLS overlay model at UNI 152 In Figure 1, assume that there is an end-to-end UNI connection 153 passing through EN1-CN1-CN2-CN3-EN3. For convenience, some terms used 154 in this document are defined below: 156 - ''source EN'' refers to the edge-node which initiates the 157 connection (i.e., EN1); 159 ''destination EN'' refers to the edge-node where the connection is 160 terminated (i.e., EN3); 162 - ''ingress CN'' refers to the core-node to which the source EN is 163 attached (i.e., CN1); 165 - ''egress CN'' refers to the core-node to which the destination EN 166 is attached (i.e., CN3). 168 [RFC4208] provides mechanisms for UNI signaling, which are compatible 169 with GMPLS RSVP-TE signaling ([RFC3471] and [RFC3473]). A single end- 170 to-end RSVP session between source EN and destination EN is used for 171 the user connection, just as it would be for connection creation 172 between two core nodes. However, when considering the isolation of 173 topology information between the core network and the overlay network, 174 additional processing of the RSVP-TE Explicit Route Object (ERO) and 175 Record Route Object (RRO) is required. For example, the ingress CN 176 should verify the ERO it receives against its topology database and 177 may enhance it with additional path information before forwarding the 178 PATH message. And the ingress/egress CN may edit or remove the RRO in 179 order to hide the path segment used inside the core network from the 180 EN. 182 The GMPLS UNI can be used in many application scenarios. For example, 183 in a multi-layer network [RFC6001] the interface between client layer 184 node and server layer node can be seen as a UNI. Or, when deploying 185 VPN services such as Layer One Virtual Private Networks (L1VPNs) 186 [RFC4847], [RFC5253], users can connect to a service provider network 187 via a UNI. 189 This document examines a number of current and future GMPLS 190 application scenarios. It shows how techniques developed after the 191 GMPLS UNI can be used to automate or enable critical aspects of these 192 application scenarios. It points out some potential technology 193 extensions that could improve UNI operation, and highlights some 194 unresolved issues. 196 2. UNI Addressing 198 In [RFC4208], the GMPLS overlay model is applied at the UNI reference 199 point, and ''it is required that the edge-node and its attached core- 200 node of the overlay network share the same address space that is used 201 by GMPLS to signal between the edge-nodes across the core network''. 202 Under this condition, the user connection can be created using a 203 single end-to-end RSVP session, which is consistent with the RSVP 204 model. Therefore, RSVP-TE defined in [RFC3473] can be used for 205 support GMPLS UNI without any extensions. The requirement should be 206 interpreted as the edge node and its attached core node of the 207 overlay network, on the access link, must share the same address 208 space. 210 However, in some deployments of the GMPLS UNI, it may not be 211 practical to ensure address space sharing without the help of address 212 mapping since the two domains the EN and its attached CN belongs to 213 may not share the same address space. This can arise if the core and 214 overlay networks were designed and deployed separately or belong to 215 different carriers. For example, the core network may use IPv6 216 addresses, while the overlay network uses IPv4 addresses. Or, since 217 the core network is a closed system, the assignment of the IP 218 addresses of the CNs may be independent of other IP addresses outside 219 the core network. This implies that the nodes in the core network may 220 use addresses which could collide with the edge nodes in the overlay 221 network. 223 [RFC4208] does not state how to ensure that an edge-node and its 224 attached core-node share the same address space on the access link. 225 This document analyzes the addressing deployment scenarios as follows: 227 1. No address mapping: overlay network and core network share a 228 common addressing policy. This might be quite feasible in a multi- 229 layer network operated by a single carrier. 231 In this scenario, end-to-end UNI connectivity may use a single 232 RSVP session, and the core routing information (assuming it is 233 shared and not stripped for confidentiality reasons) will be 234 meaningful to the ENs. Note, however, that the overlay model 235 examined by this document assumes that there is some separation 236 between the overlay and core networks, and this means that the 237 overlay network is not able to see the topology or routing 238 information of the core network even when they share a common 239 address space. 241 In this deployment, a single end-to-end RSVP-TE session can still 242 be utilized from the source EN to the destination EN. 244 2. Address mapping is needed: overlay networks and core network do 245 not share a common addressing policy. There are two cases and 246 explained below: 248 Case 1: ENs are responsible for addressing mapping. ENs have 249 limited visibility into the core network, but overlay and core 250 networks have different address spaces. In this deployment the ENs 251 can have two addresses: one in the overlay network address space 252 and one in the core network address space. The source EN is aware 253 of the addresses for itself, the ingress CN, the egress CN, and 254 possibly the destination ENs in the address space of the core 255 network. In this scenario, the ENs are responsible for performing 256 address mapping between the overlay network's addresses for the 257 ENs, and the core network's addresses for the same nodes and/or 258 its TE links. To be more specific, when receiving a RSVP-TE 259 message, it should map the address to the one that can be 260 recognized by the downstream nodes. 262 Case 2: CNs are responsible for addressing mapping. This is the 263 more common model envisaged by [RFC4208] and for basic mode L1VPN 264 deployments [RFC5251]. 266 In this scenario, the ingress CN is responsible for mapping 267 addresses to the core address space and filling in any additional 268 routing information. A typical deployment is to assign addresses 269 in the overlay address space for the ingress CN and/or its TE 270 links at the CN side, so that the EN can use overlay addresses to 271 reach the ingress CN and to identify the destination EN. 273 In these two deployment cases, the end-to-end connectivity must be 274 created either using ''session stitching'' (see Section 6.2) or 275 ''session shuffling'' (see Section 6.3), except for the case where 276 ENs are acting as the source and destination nodes of a LSP and 277 this can use a single RSVP session. 279 3. UNI Auto Discovery 281 When the end-to-end connection is set up across the core network, it 282 must be targeted at the destination CN so that it can be extended to 283 the destination EN. This means that either the source EN must know 284 the identity of the destination CN to which the destination EN is 285 attached, or the source CN must know this information. This requires 286 some form of ''discovery'' (possibly including configuration), and 287 depending on the addressing scheme in use (see Section 2), address 288 mapping needs to be performed by the source EN or the source CN. 290 The discovery problem may be exacerbated when a variety of services 291 are requested since the source EN will need to know the capabilities 292 and available resources on the link between the destination CN and 293 the destination EN. It could discover this by attempting to set up a 294 connection and by drawing conclusions from connection setup failures, 295 but this is not efficient. Furthermore, in the case of a dual-homed 296 destination EN (such as EN2 in Figure 1), a choice of destination CN 297 must be made, and that choice may be influenced by the capabilities 298 and available resources on the CN-EN links leading to the destination 299 EN. 301 If the UNI is applied in an L1VPN scenario, two mechanisms for auto 302 discovery have been defined. Auto discovery of UNI using OSPFv2 is 303 provided in [RFC5252] using an L1VPN LSA to advertise the L1VPN 304 information via the L1VPN info TLV and the TE information of the CE- 305 PE link (in the language of UNI, it's the EN-CN link) via the TE link 306 TLV. Auto discovery of UNI using BGP is provided in [RFC5195] by 307 having each edge CN advertise to other edge CN the following 308 information, at a minimum: its own IP address and the list of 309 tuples local to that PE. Once 310 that information is received, the remote PEs will identify the list 311 of VPN members they have in common with the advertising PE, and use 312 the information carried within the discovery mechanism to perform 313 address resolution during the signaling phase of Layer-1 VPN 314 connections. 316 4. UNI Path Computation 318 End-to-end UNI path computation includes three parts: the selection 319 of the source UNI link, the path computation inside the core network 320 and the selection of the destination UNI link. 322 The selection of UNI links may not be necessary in all scenarios. One 323 example is in the case of single-homing with only one UNI link 324 between EN and CN. Another example is manual selection of the UNI 325 link when the service is requested (i.e., as a function of the 326 service request such as the port mapping used in a L1VPN). In such 327 cases, the CN to which the source EN is attached, or the path 328 Computation Element (PCE) ([RFC4655]) which is responsible for the 329 core network, can perform the path computation across the core 330 network when the UNI signaling request is sent from the source EN to 331 the source CN. 333 4.1. UNI Link Selection 335 This document is specific to the overlay architectural model, and 336 that means that the source EN does not have the topology and TE 337 information of the core network. Therefore, in the case of multi- 338 homing (i.e., the source EN is connected to more than one CN), the 339 source EN does not have enough information to make a correct choice 340 among all the UNI links between itself and the core network for an 341 optimal end-to-end connection. 343 In this case, a PCE whose computation domain covers both the core 344 network and the ENs attached to it can be used. Note that the GMPLS 345 UNI predates PCE and hence a PCE was not available in early GMPLS UNI 346 deployments. A PCE that has the topology and TE information of the 347 core network can use the UNI discovery mechanism described in Section 348 3 to learn the EN-CN relationship and the TE information of the UNI 349 links, and therefore has the ability to select the optimal UNI link 350 for the connection. 352 Figure 2 shows the procedures for UNI path computation using a single 353 PCE with visibility into the core network and information about all 354 of the CN-EN links. When the UNI path computation request is received, 355 the PCE can help the source EN to compute the end-to-end route of the 356 UNI connection based on routing information it has accesses to, so 357 that the source EN can create the UNI connection using the optimal 358 UNI link. As shown in Figure 2, the following steps are carried out: 360 Step 1: EN1 requests a path from EN1 to EN2 by sending a PCReg 361 message to the PCE; 363 Step 2: The PCE computes a path based on its view of the core network 364 and knowledge of all the EN-CN links. In this case, it returns the 365 path En1-CN4-CN5-Cn6-EN2 to the EN1 node; 367 Step 3: EN1 starts the signaling process to set up the LSP by using s 368 standard RSVP signaling process, using the path information as 369 computed. 371 If confidentiality of the topology within the core network needs to 372 be preserved, the Path Key Subobject (PKS) can be used for either 373 approach outlined here (see [RFC5520] and [RFC5553]). In the PCRep 374 message returned to EN1, the Confidential Path Segment (CPS) (i.e., 375 CN4-CN5-CN6) is encoded as a PKS by the PCE. Therefore, EN1 only 376 learns the selected UNI link from the PCE. When CN4 receives the UNI 377 signaling message from EN1 carrying the PKS, CN4 asks the PCE to 378 decode the PKS and then continues to signal the LSP. 380 1) PCReq: EN1-EN2 +-----+ 381 +------------------------>| | 382 | | PCE | 383 | +----------------------| | 384 | | +-----+ 385 | | 2) PCRep: EN1-CN4-CN5-CN6-EN2 386 | | 387 | | +----------------------------------+ 388 | | | Core Network | 389 | | | +----+ +----+ +----+ | 390 | V +----+--+ CN1+------+ CN2+------+ CN3+--+----+ 391 +----+ | | +--+-+ +--+-+ +--+-+ | | +----+ 392 | +--+ | | | | | +--+ | 393 | EN1| UNI | | | | | UNI | EN2| 394 | +--+ | | | | | +--+ | 395 +----+ | | +--+-+ +--+-+ +--+-+ | | +----+ 396 +----+--+ CN4+------+ CN5+------+ CN6+--+----+ 397 ---------> | +----+ +----+ +----+ | 398 3) Signaling +----------------------------------+ 400 Figure 2 - Procedure using a PCE for UNI path computation 402 For the case described in this section, the PCE needs to be visible 403 to the ENs, and there also needs to be a control channel between the 404 PCE and the ENs for the exchange of PCE Protocol (PCEP) messages. An 405 alternative implementation could be that a PCE is located inside each 406 CN to which the source EN is attached, so that the source EN can use 407 the UNI control channel to send and receive the PCEP messages. 409 Another example of using a PCE for UNI path computation is the multi- 410 PCE with inter-communication model, where there is a PCE lies in 411 overlay network and a PCE lies in the core network. Thus, for example, 412 the EN1 can issue a path computation request to its PCE, then in turn, 413 the overlay PCE communicates with the core network PCE, which may 414 reply the path segment encoded with Path Key. Finally, the overlay 415 PCE sends back the path to the source EN1 to finish the whole process. 417 The node requesting for a LSP, crossing UNI, may not be an EN node, 418 as depicted in Figure 3. The procedure described above still applies. 419 In this case, if an explicit route is desired there is an additional 420 requirement that the PCE needs to have visibility into the overlay 421 networks. Otherwise, the PCE can only provide the route between two 422 EN nodes as illustrated in Figure 3. 424 |---Overlay-----||-------Core Network----------||---Overlay-----| 426 +-----+ 427 | PCE | 428 +-----+ 430 +-+--+ +--+-+ +--+-+ 431 +--+ CN1+---| CN2+----+ CN3+-----+ 432 +---+ +---+ | +-+--+ +--+-+ +--+-+ | +----+ +---+ 433 | C1|---|EN2|---+- | | | UNI +--+ EN1+--+ C2| 434 |---| |---|-+ UNI | | | +--+----+ +---+ 435 | | | | | 436 | +-+--+ +--+-+ +--+-+ | 437 +----+ CN4+---+ CN5+----+ CN6+-----+ 438 +----+ +----+ +----+----+ 440 |---------------------------LSP------------------------------| 441 |----> 442 RSVP-TE Signaling 444 Figure 3 - Procedure of non-EN Node in the Overlay Path Computation 446 5. Additional Parameters across UNI 448 With new extensions currently proposed for the RSVP-TE protocol, new 449 parameters/functions can also be applicable to UNI. 451 5.1. Constrained Path Computation 453 Constraints that can be applied to the path computation in the core 454 network are: 456 + Diversity: it is possible to indicate the resources must or 457 should be avoided during the path computation by means of the 458 Exclude Router Object (XRO) [RFC4874], the Explicit Exclusion 459 Route Subobject (EXRS) [RFC4874] and the LSP subobject [LSP-DIV]. 460 Such resources can consist of: 462 -IPv4 prefix, IPv6 prefix, Unnumbered Interface ID, AS 463 Number and SRLG [RFC4874] 465 -IPv4 P2P subobject and IPv6 P2P subobject [LSP-DIV] 467 + Latency, Latency Variation and Cost: max delay/delay variation 468 and cost allowed by the server layer LSP [UNI PLUS] 470 The overlay Edge Node can include into the RSVP-TE Path message an 471 arbitrary number of path computation constraints for the provisioning 472 of the LSP in the server domain. For example, in Figure 2, EN1 can 473 request a path with a constraint: max latency should be 200ms. 475 If the path computation in the core network is able to provide an 476 LSP meeting the requirements (at least those requirements which must 477 be met) such LSP is established and a RESV message is returned to the 478 Edge node; otherwise an error message (PathErr) is returned. 480 Use cases described in Section 7 can be viewed as a special use case 481 of diversity. 483 5.2. Collection Requests over UNI 485 In addition to the path request with path computation constraints, 486 the overlay nodes can also request for the collection in the core 487 network of the effective values of the parameters indicated as path 488 computation constraints. The collection of such parameters is 489 indicated via dedicated flags in the LSP_ATTRIBUTES and 490 LSP_REQUIRED_ATTRIBUTES in Path Message. Flags defined are: 492 - Cost collection flag [TE-REC] 493 - Latency collection flag [TE-REC] 495 - Latency Variation collection flag [TE-REC] 497 - SRLG collection flag [SRLG-FA] 499 In the scenario depicted in Figure 2 a request with constraints on 500 max latency might be issued together with the request of collecting 501 e.g. the effective SRLGs of the provided path, in order to set up a 502 SRLG-disjoint recovery path, as explained in Section 7. Collected 503 parameters are returned to the overlay edge node via the Record Route 504 Object (RRO) in the RESV message. 506 6. UNI Path Provisioning Models 508 The basic GMPLS UNI application is to provide end-to-end connections 509 between edge-nodes through a core network via the overlay model. This 510 section briefly describes four ways in which the end-to-end LSP can 511 be created and operated across the core network. 513 6.1. Flat Model 515 In this model, the edge-nodes have the same switching capability as 516 the nodes in the core network. In this case, one single end-to-end 517 RSVP session through the edge-nodes and a series of core-nodes can be 518 used to create the connection, which forms a flat LSP model, as shown 519 in Figure 4. 521 +----------------------------------+ 522 | Core Network | 523 +----+ UNI | +----+ +----+ +----+ | UNI +----+ 524 | EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN | 525 +----+ | +----+ +----+ +----+ | +----+ 526 | | | | 527 | +----------------------------------+ | 528 | | 529 |<------------- End-to-end RSVP Session -------------->| 530 | | 531 Figure 4 - The Flat Model 533 If the edge-nodes and their attached core-nodes share the same 534 address space, or the ENs can perform address mapping into the core 535 network address space, the GMPLS signaling described in [RFC3471], 536 [RFC3473] and other related specifications, with special ERO and RRO 537 processing as described in [RFC4208], can be used to create a 538 connection. Note the procedures mentioned still apply in the 539 scenarios where the source node of a connection is not an edge-node 540 but rather nodes within the same domain as EN. 542 6.2. Stitching Model 544 The stitching mechanism described in [RFC5150] can be used to create 545 an LSP segment (S-LSP) between the ingress and the egress CN, and to 546 stitch the end-to-end UNI connection to the created S-LSP, as shown 547 in Figure 5. 549 +----------------------------------+ 550 | Core Network | 551 +----+ UNI | +----+ +----+ +----+ | UNI +----+ 552 | EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN | 553 +----+ | +----+ +----+ +----+ | +----+ 554 | | | | | | 555 | +----+------------------------+----+ | 556 | | | | 557 | |<-LSP Segment (S-LSP)-->| | 558 | | 559 |<------------- End-to-end RSVP Session -------------->| 561 Figure 5 - The Stitching Model 563 This model allows the core network a degree of independence so that 564 the S-LSP can be set up and modified without the knowledge of the 565 overlay network. Remember that stitching is a data plane function, so 566 that the EN-CN LSP segments are cross-connected to the S-LSP at the 567 edge CNs. This means that, just as in Section 6.1, the overlay and 568 core networks must have the same switching capabilities. However, the 569 control plane for the stitching model operates just as the 570 hierarchical model described in Section 6.4, so the S-LSP appears as 571 a single hop in the overlay network. 573 6.3. Session Shuffling Model 575 The session shuffling approach ([RFC5251]) is a modification of the 576 flat model described in Section 6.1. In this approach a single end- 577 to-end session is established, but as the signaling messages pass 578 through the ingress and egress CNs, address mapping is performed on 579 all addresses carried by the messages to replace the addresses with 580 values from the correct address space. The ERO and RRO are stripped 581 from the messages as previously discussed, so there is no need for 582 the CNs to examine those objects to map addresses. However, all other 583 addresses must be mapped including the important session identifiers 584 (the source and destination addresses). Viewed from the outside 585 (perhaps through an NMS) this gives the impression of session 586 stitching because the session has different identifiers as it crosses 587 the core network. An NMS might, therefore, present the shuffling 588 model as the stitching model, or it might operate the same address 589 shuffling/mapping as is used by CNs. 591 6.4. Hierarchal Model 593 If the ENs and CNs have the same switching capability, a tunnel 594 between the ingress and egress core-nodes can be provisioned to carry 595 the end-to-end connection. The tunnel may have a larger capacity than 596 the end-to-end UNI connection, depending on the policies configured 597 at the ingress CN of the core network. The end-to-end connection can 598 be nested into a tunnel, which forms the LSP hierarchy [RFC4206] as 599 shown in Figure 6. If the tunnel has a larger capacity, other LSPs 600 can also be nested within the same tunnel. 602 Alternatively, if the ENs and CNs have different switching 603 capabilities the LSP hierarchical model can also be used exactly as 604 described in [RFC4206]. 606 In the hierarchal model, the end-to-end connection can be divided 607 into three hops: one for each UNI link and one hop across the core 608 network. The core network tunnel can be pre-provisioned via network 609 planning, or triggered by the UNI signalling. For the latter case, 610 [RFC5212], [RFC6001] and other multi-layer network related 611 specifications can be used to create the hierarchical LSP. 613 +----------------------------------+ 614 | Core Network | 615 +----+ UNI | +----+ +----+ +----+ | UNI +----+ 616 | EN +-------+--+ CN +======+ CN +======+ CN +--+-------+ EN | 617 +----+ | +----+ +----+ +----+ | +----+ 618 | | | | | | 619 | +----+------------------------+----+ | 620 | | | | 621 | |<-Core Network Tunnel-->| | 622 | | 623 |<------------- End-to-end RSVP Session -------------->| 624 | | 626 Figure 6 - The Hierarchal Model 628 7. UNI Recovery 630 One of the significant uses of GMPLS is to provide recovery 631 mechanisms for connections. Recovery and protection mechanisms are 632 also needed in many UNI scenarios, and the relationship between the 633 overlay and core network provide obvious places at which to operate 634 the recovery techniques. 636 7.1. End-to-end Recovery 638 In the case of multi-homing, UNI end-to-end recovery is possible. As 639 shown in Figure 7, the working path (W) and the protection path (P) 640 are disjoint from each other not only inside the core network, but 641 also at both the source and destination sides of the UNI. Mechanisms 642 need to be provided to ensure the selection of disjoint working and 643 backup paths as discussed in the following subsections. 645 It should be noted that end-to-end recovery can be operated even when 646 the ENs are single-homed. However, obviously, in this case there is 647 no protection against the failure of an EN-CN link, or of the edge CN 648 itself. 650 +----------------------------------+ 651 | Core Network | 652 W | +----+ +----+ +----+ | 653 +----+--+ CN +------+ CN +------+ CN +--+----+ 654 +----+ | | +----+ +----+ +----+ | | +----+ 655 | +--+ | | +--+ | 656 | EN | UNI | | UNI | EN | 657 | +--+ | | +--+ | 658 +----+ | | +----+ +----+ +----+ | | +----+ 659 +----+--+ CN +------+ CN +------+ CN +--+----+ 660 P | +----+ +----+ +----+ | 661 +----------------------------------+ 663 Figure 7 - UNI End-to-End Recovery 665 7.1.1. Serial Provisioning of Working and Protection Paths 667 In serial provisioning, one path is computed before another and the 668 associated LSP may even be set up before the second path is computed. 669 In the case where the working path is computed and created before the 670 protection path, path computation for the protection path needs to 671 select a (maximally) disjoint path given this existing working path. 673 If the EN is allowed to see details of the core network, the EN can 674 use the RRO to collect the route of the working path. It can then use 675 the Exclude Route Object (XRO) to exclude the working path when 676 signaling the protection path, as described in [RFC4874]. 678 But in most cases, in order to preserve the confidentiality of 679 topology within the core network, the route of the working path as it 680 traverses the core network will be hidden from the EN. In such cases, 681 the RRO and XRO mechanism cannot be used. Alternative includes: 683 -Only collect the Shared Risk Group (SRG) information, but not the 684 full path information [SLRG-FA]. This is because the SRG 685 information is normally less confidential than the information of 686 node ID and link ID. 688 -Another possible solution is encrypted the SRG information and 689 provide it to the EN nodes, so that the EN nodes can using this 690 information to convey the diversity constraint, as the method 691 specified in [UNIExt]. 693 -In an application scenario where a PCE is involved inside the core 694 network, then the Path Key mechanism can be used. The confidential 695 path segment, i.e., the route of the working path as it traverses 696 the core network, is encoded as a PKS by the PCE when computing the 697 working path [RFC5520]. This PKS can be used by the EN when it 698 requests the PCE to compute a protection path, to exclude the nodes 699 and links used by the working path. As previously described, the 700 PKS is also used in signaling [RFC5553] so that the EN can indicate 701 to the CN what path to use across the core network. 703 In order to specify the diversity requirement, it is required that 704 the PKS should be carried in the XRO in both PCEP message and RSVP-TE 705 signaling. 707 7.1.2. Concurrent Computation of Working and Protection Path 709 The working and protection path can be computed at the same time 710 (e.g., by PCE or by one of the CNs to which the source EN is 711 attached). 713 [PCE-GMPLS] adds support for an end node to request a protected 714 service using the protection types defined in [RFC4872].Therefore, 715 it's possible that the source EN requests the edge CN or PCE to 716 compute both the working and the protection path at the same time. At 717 this time, the disjunction requirement can be resolved inside the 718 path computation server. 720 Same as described in the previous section, the path segment 721 traversing the core network can be encoded as a PKS if 722 confidentiality is requested. 724 7.2. Segment Recovery 726 The UNI connection may request protection only inside the core 727 network, especially in case of single-homing. A UNI segment 728 protection example is shown in Figure 8. In this case, the core 729 network provides a "recovery domain". 731 +--------------------------------------+ 732 | Core Network | 733 | W +----+ +----+ | 734 | +--+ CN +--+ CN +--+ | 735 +----+ | +----+ | +----+ +----+ | +----+ | +----+ 736 | | | | +--+ +--+ | | | | 737 | EN +-----+-+ CN | | CN +-+-----+ EN | 738 | | UNI | | +--+ +--+ | | UNI | | 739 +----+ | +----+ | +----+ +----+ | +----+ | +----+ 740 | +--+ CN +--+ CN +--+ | 741 | P +----+ +----+ | 742 +--------------------------------------+ 744 Figure 8 - UNI Segment Recovery 746 [RFC4873] provides a mechanism for segment recovery, in which the 747 PROTECTION Object is extended to indicate segment recovery, and the 748 Secondary ERO (SERO) is introduced for the explicit control of the 749 protection LSP between the branch node and the merge node. 751 However, in the overlay model, the mechanisms of segment recovery 752 described in [RFC4873] may not be appropriate. In particular, the 753 source EN might not know the CN to which the destination EN is 754 attached. That means that the source EN knows the branch for the 755 protection segment, but does not know the merge node. 757 But the model shown in Figure 8 is particularly important because it 758 places the responsibility for service delivery with the edge CNs. 759 This will be a common operational model in overlay networks. 760 Fortunately the stitching model (Section 6.2) and the hierarchical 761 model (Section 6.4) are good at providing the necessary protection 762 within the core network without the ENs having to be aware of the 763 paths in the core network. 765 8. UNI Call 767 The Call is a fundamental component of the ASON model [G.8080]. It is 768 used to maintain the association between one or more user 769 applications and the network, and to control the set-up, release, 770 modification, and maintenance of sets of Connections (LSPs). In 771 simple cases, the Call and Connection can be established at the same 772 time and in a strict one-to-one ratio. In this case, Call signaling 773 requires only minor extensions to connection signaling. However, if 774 Calls are handled separately from Connections, or if more than one 775 Connection can be associated with a single Call, additional Call 776 signaling is required. 778 The GMPLS Call, defined in [RFC4974], provides a mechanism to 779 negotiate agreement between endpoints possibly in cooperation with 780 the nodes that provide access to the network. Typically the GMPLS 781 Call can be applied in the UNI scenario for access link capability 782 exchange, policy, authorization, security, and so on. 784 8.1. Exchange of UNI Link Information 786 It is possible that the TE attributes of the access link (i.e., the 787 UNI link) are not shared across the core network. So the source EN 788 may not have the TE information of the destination access link as 789 well as the capability of the destination EN. For example, in case of 790 TDM network, the Virtual Concatenation (VCAT) and Link Capacity 791 Adjustment Scheme (LCAS) capability of the destination EN may not be 792 known. 794 In this case, the source EN can raise a Call carrying the 795 LINK_CAPABILITY object to have a capability exchange with the 796 destination EN, as described in [RFC4974]. 798 8.2. Control of Call Route 800 When applying the Call, it's possible that there are multiple core 801 network domains between the source EN (Call initiator) and the 802 destination EN (Call terminator), or there is more than one Call 803 manager in the core network (e.g., in the multi-homing scenario where 804 the CNs to which the ENs are attached act as the Call managers). 806 In the both cases, when establishing the Call, there may be multiple 807 alternative routes for the Call message to reach the destination EN. 808 One can simply use the hop-by-hop manner (i.e., each Call manager 809 determines the next Call manager to which the Call message will be 810 sent by itself) to control the path of the Call. 812 However, in the practical deployment of UNI Call, commercial and 813 policy motivations normally play an important role in selecting the 814 Call route, especially in the multi-domain scenario. In this case, 815 the hop-by-hop manner is not practical because the route of the Call 816 needs to be pre-determined in consideration of commercial and policy 817 factors before establishing the Call. 819 Therefore, it is desirable to allow full control of the Call by the 820 source EN. That is, the source EN can identify the full Call route 821 and signal it explicitly, so that the Call message can be forwarded 822 along the desired route. Moreover, the management plane needs to be 823 able to identify the Call route explicitly as an instruction to the 824 source EN. 826 9. UNI Multicast 828 Data plane multicasting is supported in existing Traffic-Engineering 829 networks. GMPLS provides extensions to RSVP-TE to support 830 provisioning of point-to-multipoint (P2MP) TE LSPs via the control 831 plane, as described in [RFC4461] and [RFC4875]. 833 In the scenarios where P2MP is supported using the overlay 834 architectural model, it is a requirement to transport signals from 835 one source EN to multiple destination ENs. One could create a point- 836 to-point (P2P) connection between the source EN and each destination 837 EN, but it will likely be a waste of bandwidth resource both of the 838 UNI link and in the core network. 840 Therefore, there are some scenarios required to support point-to- 841 multipoint (P2MP) TE LSPs from one source EN to multiple leaf ENs. 843 9.1. UNI Multicast Connection Model 845 There are two cases for the UNI multicast. For the first case, only 846 the ingress and egress CNs in the core network support P2MP. The core 847 network has to provide multiple P2P connections between ingress CN 848 and each egress CN for the end-to-end UNI multicast, as shown in 849 Figure 9. This relieves the pressure on the source UNI link, but does 850 not help the over use of the core links such as CN1-CN2. 852 +----------------------------------------+ 853 | Core Network | 854 | +-----+ +-----+ +-----+ |UNI +---+ 855 +---+ UNI| | +--------+-----+-------+ +--+----+EN2| 856 |EN1+----+--+ CN1 +--------+-\CN2| | CN3 | | +---+ 857 +---+ | | +--------+\ \ | | | | Leaf A 858 Source | +-----+ +-+-+-+ +-----+ | 859 | | | | 860 | +-+-+-+ +-----+ |UNI +---+ 861 | | | \+-------+ +--+----+EN3| 862 | | |CN4| | CN5 | | +---+ 863 | +-+---+ +-----+ | Leaf B 864 | | | 865 | +-+---+ +-----+ |UNI +---+ 866 | | \---+-------+ +--+----+EN4| 867 | | CN6 | | CN7 | | +---+ 868 | +-----+ +-----+ | Leaf C 869 +----------------------------------------+ 871 Figure 9 - Only ingress/egress CNs support multicast 873 For example, in multi-layer scenario of a packet overlay network with 874 a TDM core, the ingress/egress CNs may have packet multicast 875 capabilities and therefore can adapt the packets from EN into 876 multiple TDM connections to transit the core network, but the CNs 877 inside the core network only support point-to-point (P2P) TDM 878 connections. 880 In another case, all the CNs in the core network can support 881 multicast, so that the core network can create a P2MP LSP to provide 882 the end-to-end UNI multicast, as shown in Figure 10. 884 +----------------------------------------+ 885 | Core Network | 886 | +-----+ +-----+ +-----+ |UNI +---+ 887 +---+ UNI| | +--------+-+-->+-------+ +--+----+EN2| 888 |EN1+----+--+ CN1 | | |CN2| | CN3 | | +---+ 889 +---+ | +-----+ +-V---+ +-----+ | Leaf A 890 Source | | | 891 | +-+---+ +-----+ |UNI +---+ 892 | | +-->+-------+ +--+----+EN3| 893 | | |CN4| | CN5 | | +---+ 894 | +-V---+ +-----+ | Leaf B 895 | | | 896 | +-+---+ +-----+ |UNI +---+ 897 | | \-->+-------+ +--+----+EN4| 898 | | CN6 | | CN7 | | +---+ 899 | +-----+ +-----+ | Leaf C 900 +----------------------------------------+ 902 Figure 10 - All CNs support multicast 904 For example, in the Ethernet over OTN scenario, if the core network 905 can support ODU0 multicast, then an ODU0 P2MP LSP can be created 906 inside the core network to carry the client Gigabit Ethernet (GE) 907 signal for the ENs. 909 Note that the branching of the P2MP connection could also happen at 910 the source EN if the EN is multi-homed. In this case, each branch 911 from the source EN uses a separate UNI link connecting the source EN 912 to the core network. For each UNI branch, the connection model inside 913 the core network is the same as described in this section. 915 9.2. UNI Multicast Connection Provisioning 917 The four UNI connection provisioning models, as described in Section 918 5, should also be applied in the UNI multicast scenario. 920 For the flat model, one end-to-end P2MP session as described in 921 [RFC4875] can be used to create the P2MP LSP from source EN to leaf 922 ENs. 924 For the stitching model, multiple P2P LSP segments or one P2MP LSP 925 segment between the ingress CN and each egress CNs needs to be 926 created and then stitched to the UNI P2MP LSP. GMPLS UNI signaling 927 should have the capability to convey the multicast information by 928 using stitching model. 930 For the session shuffling model, one end-to-end P2MP session can be 931 used to create the P2MP LSP, with an address mapping performed at 932 both ingress and egress CNs. 934 For the hierarchical model, multiple P2P LSP tunnels or one P2MP LSP 935 tunnel between the ingress CN and each egress CNs needs be triggered 936 by the UNI signaling for creating the P2MP LSP. GMPLS UNI signaling 937 should have the capability to convey the multicast information by 938 using the hierarchical model. 940 10. Security Considerations 942 [RFC5920] provides an overview of security vulnerabilities and 943 protection mechanisms for the GMPLS control plane, which is 944 applicable to this document. 946 The details of the specific security measures of the overlay network 947 architectural model are provided in [RFC4208], which permits the core 948 network to filter out specific RSVP objects to hide its topology from 949 the EN. 951 Furthermore, if PCE is used, the security issues described in 952 [RFC4655] should also be considered. 954 Additionally, when the PKS mechanism is applied, the security issues 955 can be dealt with using [RFC5520] and [RFC5553]. 957 11. IANA Considerations 959 This informational document does not make any requests for IANA 960 action. 962 12. Acknowledgments 964 The authors would like to thank Zafar Ali, Deborah Brungard and Lou 965 berger for their comments. 967 13. References 969 13.1. Normative References 971 [RFC3209] D. Awduche et al, ''RSVP-TE: Extensions to RSVP for LSP 972 Tunnels'', RFC3209, December 2001. 974 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 975 Switching (GMPLS) Signaling Functional Description", RFC 976 3471, January 2003. 978 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 979 Switching (GMPLS) Signaling Resource ReserVation 980 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 981 3473, January 2003. 983 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 984 (GMPLS) Architecture", RFC 3945, October 2004. 986 [RFC4203] Kompella, K., and Rekhter, Y., ''OSPF Extensions in 987 Support of Generalized Multi-Protocol Label Switching 988 (GMPLS)'', RFC 4203, October 2005. 990 [RFC4206] K. Kompella et al, ''Label Switched Paths (LSP) Hierarchy 991 with Generalized Multi-Protocol Label Switching (GMPLS) 992 Traffic Engineering (TE)'', RFC4206, October 2005. 994 [RFC4208] G. Swallow et al, ''Generalized Multiprotocol Label 995 Switching (GMPLS) User-Network Interface (UNI): Resource 996 ReserVation Protocol-Traffic Engineering (RSVP-TE) 997 Support for the Overlay Model'', RFC4208, October 2005. 999 [RFC4655] A. Farrel et al, ''A Path Computation Element (PCE)-Based 1000 Architecture'', RFC4655, August 2006. 1002 [RFC4847] T. Takeda, Ed., ''Framework and Requirements for Layer 1 1003 Virtual Private Networks'', RFC4847, April 2007. 1005 [RFC4872] J.P. Lang et al, ''RSVP-TE Extensions in Support of End- 1006 to-End Generalized Multi-Protocol Label Switching (GMPLS) 1007 Recovery'', RFC4872, May 2007. 1009 [RFC4873] L. Berger et al, ''GMPLS Segment Recovery'', RFC4873, May 1010 2007. 1012 [RFC4874] CY. Lee et al, ''Exclude Routes - Extension to Resource 1013 ReserVation Protocol-Traffic Engineering (RSVP-TE)'', 1014 RFC4874, April 2007. 1016 [RFC4875] R. Aggarwal et al, ''Extensions to Resource Reservation 1017 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1018 Multipoint TE Label Switched Paths (LSPs)'', RFC4875, May 1019 2007. 1021 [RFC4974] D. Papadimitriou and A. Farrel, Ed., ''Generalized MPLS 1022 (GMPLS) RSVP-TE Signaling Extensions in Support of Calls'', 1023 RFC4974, August 2007. 1025 [RFC5150] A. Ayyangar et al, ''Label Switched Path Stitching with 1026 Generalized Multiprotocol Label Switching Traffic 1027 Engineering (GMPLS TE)'', RFC5150, February 2008. 1029 [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 1030 Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008. 1032 [RFC5251] D. Fedyk and Y. Rekhter, Ed., ''Layer 1 VPN Basic Mode'', 1033 RFC5251, July 2008. 1035 [RFC5252] I. Bryskin and L. Berger Ed., ''OSPF-Based Layer 1 VPN 1036 Auto-Discovery'', RFC5252, July 2008. 1038 [RFC5520] R. Bradford, Ed., ''Preserving Topology Confidentiality in 1039 Inter-Domain Path Computation Using a Path-Key-Based 1040 Mechanism'', RFC5520, April 2009. 1042 [RFC5553] A. Farrel, Ed., ''Resource Reservation Protocol (RSVP) 1043 Extensions for Path Key Support'', RFC5553, May 2009. 1045 [RFC6001] Dimitri Papadimitriou et al, ''Generalized Multi-Protocol 1046 Label Switching (GMPLS) Protocol Extensions for Multi- 1047 Layer and Multi-Region Networks (MLN/MRN)'', RFC6001, 1048 October, 2010. 1050 [RFC6107] K. Shiomoto, A. Farrel, ''Procedures for Dynamically 1051 Signaled Hierarchical Label Switched Paths'', RFC6107, 1052 February 2011. 1054 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 1055 Automatically Switched Optical Network (ASON)," June 2006 1056 (and Amend.2, September 2010). 1058 13.2. Informative References 1060 [RFC4461] S. Yasukawa, Ed., ''Signaling Requirements for Point-to- 1061 Multipoint Traffic-Engineered MPLS Label Switched Paths 1062 (LSPs)'', RFC4461, April 2006. 1064 [RFC5212] K. Shiomoto et al, ''Requirements for GMPLS-Based Multi- 1065 Region and Multi-Layer Networks (MRN/MLN)'', RFC5212, July 1066 2008. 1068 [RFC5253] T. Takeda, Ed., ''Applicability Statement for Layer 1 1069 Virtual Private Network (L1VPN) Basic Mode'', RFC 5253, 1070 July 2008. 1072 [RFC5339] JL. Le Roux et al, ''Evaluation of Existing GMPLS 1073 Protocols against Multi-Layer and Multi-Region Networks 1074 (MLN/MRN)'', RFC5339, September 2008. 1076 [RFC5441] JP. Vasseur et al, ''A Backward-Recursive PCE-Based 1077 Computation (BRPC) Procedure to Compute Shortest 1078 Constrained Inter-Domain Traffic Engineering Label 1079 Switched Paths'', RFC5441, April 2009. 1081 [RFC5623] Oki, E., Takeda, T., Le Roux, J.L., and Farrel, A., 1082 ''Framework for PCE-Based Inter-Layer MPLS and GMPLS 1083 Traffic Engineering'', RFC 5623, September 2009. 1085 [RFC5920] L. Fang, Ed., ''Security Framework for MPLS and GMPLS 1086 Networks'', RFC5920, July 2010. 1088 [Call-ext] Fatai Zhang et al, ''RSVP-TE extensions to GMPLS Calls'', 1089 draft-zhang-ccamp-gmpls-call-extensions-01.txt, July 08, 1090 2009. 1092 [PCE-GMPLS] C. Margaria et al, ''PCEP extensions for GMPLS'', draft- 1093 ietf-pce-gmpls-pcep-extensions-07.txt, October 21, 2012. 1095 [SRLG-FA] Fatai Zhang et al, ''RSVP-TE Extensions for Configuration 1096 SRLG of an FA'', draft-ietf-ccamp-rsvp-te-srlg-collect- 1097 02.txt, work in progress. 1099 [RFC6344] G. Bernstein et al, ''Operating Virtual Concatenation 1100 (VCAT) and the Link Capacity Adjustment Scheme (LCAS) 1101 with Generalized Multi-Protocol Label Switching (GMPLS)'', 1102 RFC6344, August 2011. 1104 [UNIExt] D. Fedyk, D. Beller, Lieven Levrau, D. Ceccarelli, F. 1105 Zhang, et al, ''UNI Extensions for Diversity and Latency 1106 Support'', draft-fedyk-ccamp-uni-extensions-00.txt, Feb. 1107 2014; 1109 [LSP-DIV] A., Zafar, G., Swallow et al, ''Resource ReserVation 1110 Protocol-Traffic Engineering (RSVP-TE) Path Diversity 1111 using Exclude Routes'', draft-ietf-ccamp-lsp-diversity- 1112 01.txt, work in progress; 1114 [UNI-PLUS] A., Zafar, G., Swallow et al, ''Resource ReserVation 1115 Protocol-Traffic Engineering (RSVP-TE) extension for 1116 signaling Objective Function and Metric Bound'', draft- 1117 ali-ccamp-rc-objective-function-metric-bound-02.txt, work 1118 in progress; 1120 [TE-REC] A., Zafar, G., Swallow et al, ''Resource ReserVation 1121 Protocol-Traffic Engineering (RSVP-TE)extension for 1122 recording TE Metric of a Label Switched Path'', draft- 1123 ietf-ccamp-te-metric-recording-01.txt, work in progress; 1125 14. Contributors' Address 1127 Yi Lin 1128 Huawei Technologies 1129 F3-5-B R&D Center, Huawei Base 1130 Bantian, Longgang District 1131 Shenzhen 518129 P.R.China 1133 Phone: +86-755-28972914 1134 Email: yi.lin@huawei.com 1136 Young Lee 1137 Huawei Technologies 1138 1700 Alma Drive, Suite 100 1139 Plano, TX 75075 1140 USA 1142 Phone: (972) 509-5599 (x2240) 1143 Email: leeyoung@huawei.com 1145 Dan Li 1146 Huawei Technologies 1147 F3-5-B R&D Center, Huawei Base 1148 Bantian, Longgang District 1149 Shenzhen 518129 P.R.China 1151 Phone: +86-755-28973237 1152 Email: huawei.danli@huawei.com 1154 Don Fedyk 1155 Hewlett-Packard 1156 Don.fedyk@hp.com 1157 Sergio Belotti 1158 Alcatel-Lucent 1159 Sergio.belotti@alcatel-lucent.com 1161 Dieter Beller 1162 Alcatel-Lucent 1163 Dieter.beller@alcatel-lucent.com 1165 15. Authors' Addresses 1167 Fatai Zhang 1168 Huawei Technologies 1169 F3-5-B R&D Center, Huawei Base 1170 Bantian, Longgang District 1171 Shenzhen 518129 P.R.China 1173 Phone: +86-755-28972912 1174 Email: zhangfatai@huawei.com 1176 Oscar Gonzalez de Dios 1177 Telefonica Investigacion y Desarrollo 1178 Emilio Vargas 6 1179 Madrid, 28045 1180 Spain 1182 Phone: +34 913374013 1183 Email: ogondio@tid.es 1185 Adrian Farrel 1186 Old Dog Consulting 1188 EMail: adrian@olddog.co.uk 1190 Xian Zhang 1191 Huawei Technologies 1192 F3-5-B R&D Center, Huawei Base 1193 Bantian, Longgang District 1194 Shenzhen 518129 P.R.China 1196 Phone: +86-755-28972913 1197 Email: zhang.xian@huawei.com 1198 Daniele Ceccarelli 1199 Ericsson 1200 Via A. Negrone 1/A 1201 Genova - Sestri Ponente 1202 Italy 1204 Email: daniele.ceccarelli@ericsson.com