idnits 2.17.1 draft-fedyk-ccamp-uni-extensions-04.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 ([RFC4208], [RFC4847]), 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 736 has weird spacing: '...ence of a dom...' -- The document date (February 14, 2014) is 3724 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Fedyk 3 Internet Draft Hewlett-Packard 4 Intended status: Standards Track D. Beller 5 L. Levrau 6 Alcatel-Lucent 7 D. Ceccarelli 8 Ericsson 9 F. Zhang 10 Huawei Technologies 11 Y. Tochio 12 Fujitsu 13 X. Fu 14 ZTE 16 Expires: August 18, 2014 February 14, 2014 18 UNI Extensions for Diversity and Latency Support 19 draft-fedyk-ccamp-uni-extensions-04.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright Notice 44 Copyright (c) 2013 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 Abstract 59 This document builds on the GMPLS overlay model [RFC4208] and defines 60 extensions to the GMPLS User-Network Interface (UNI) to support route 61 diversity within the core network for sets of LSPs initiated by edge 62 nodes. A particular example where route diversity within the core 63 network is desired, are dual-homed edge nodes. The core network is 64 typically composed of multiple network domains and those multi-domain 65 diversity aspects that have an implication on the GMPLS UNI 66 extensions are discussed. 68 The document also defines GMPLS UNI extensions to deal with latency 69 requirements for edge node initiated LSPs. 71 This document uses a VPN model that is based on the same premise as 72 L1VPN framework [RFC4847] but may also be applied to other 73 technologies. The extensions are applicable both to VPN and non VPN 74 environments. These extensions move the UNI from basic connectivity 75 to enhanced mode connectivity by including additional constraints 76 while minimizing the exchange of CE to PE information. These 77 extensions are applicable to the overlay extension service model. 78 Route Diversity for customer LSPs are a common requirement applicable 79 to L1VPNs. The UNI mechanisms described in this document are L1VPN 80 compatible and can be applied to achieve diversity for sets of 81 customer LSPs. 83 The UNI extensions in support of latency constraints can also be 84 applied to the extended overlay service model in order for the 85 customer LSPs to meet certain latency requirements. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 90 2. Conventions used in this document . . . . . . . . . . . . . . . 4 91 3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 92 4. LSP Diversity in the Overlay Extension Service Model . . . . . 5 93 4.1. LSP diversity for dual-homed customer edge (CE) devices . . 6 94 4.1.1. Exchanging SRLG information between the PEs via the 95 CE device . . . . . . . . . . . . . . . . . . . . . . . 9 96 4.1.1.1. Operational Procedures . . . . . . . . . . . . . . 9 97 4.1.1.2. Error Handling Procedures . . . . . . . . . . . . . 10 98 4.1.2. Using Path Affinity Set Extension . . . . . . . . . . . 11 99 4.1.2.1. Operational Procedures . . . . . . . . . . . . . . 14 100 4.1.2.2. Error Handling Procedures . . . . . . . . . . . . . 14 101 4.1.2.3. Distribution of the Path Affinity Set Information . 15 102 4.2. Multi-domain LSP Diversity Aspects for Dual-homed CE 103 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 4.2.1 Subdividing Identifier Spaces into Ranges . . . . . . . 16 105 4.2.2 Scoping Identifier Spaces to Domains . . . . . . . . . . 16 106 4.2.3. Multi-domain Diversity Aspects in Case Domains 107 Utilize a PCE . . . . . . . . . . . . . . . . . . . . . 17 108 5. Latency Signaling Extensions . . . . . . . . . . . . . . . . . 18 109 5.1. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . 19 110 5.2. Operational Procedures . . . . . . . . . . . . . . . . . . 20 111 5.3. Error Handling Procedures . . . . . . . . . . . . . . . . . 20 112 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 116 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 119 1. Introduction 121 This document builds on the GMPLS overlay model [RFC4208] and defines 122 extensions to the GMPLS User-Network Interface (UNI) to support route 123 diversity within the core network for sets of LSPs initiated by edge 124 nodes. In the following, the term customer edge (CE) device is used 125 synonymously for the term edge node (EN) as in [RFC4208]. 127 Moreover, the VPN terminology (CE and PE) [RFC4026] is used below 128 when the core network is a VPN but is also applicable to UNI 129 interfaces [RFC4208]. 131 This document uses a VPN model that is based on the same premise as 132 L1VPN framework [RFC4847] but may also be applied to other 133 technologies. The extensions are applicable both to VPN and non VPN 134 environments. These extensions move the UNI from basic connectivity 135 to enhanced mode connectivity by including additional constraints 136 while minimizing the exchange of CE to PE information. These 137 extensions are applicable to the overlay extension service model. 139 The overlay model assumes a UNI interface between the edge nodes of 140 the respective transport domains. Route diversity for LSPs from 141 single homed CE and dual-home CEs is a common requirement in optical 142 transport networks. This document describes two signaling variations 143 that may be used for supporting LSP diversity within the overlay 144 extension service model considering dual-homing. Dual-homing is 145 typically used to avoid a single point of failure (UNI link, PE) or 146 if two disjoint connections are forming a protection group in the CE 147 device, e.g., 1+1 protection. While both methods are similar in that 148 they utilize common mechanisms in the PE network to achieve 149 diversity, they are distinguished according to whether the CE is 150 permitted to retrieve provider SRLG diversity information for an LSP 151 from a PE1 and pass it on to a PE2 (SRLG information is shared with 152 the CE), or whether a new attribute is used that allows the PE2 that 153 receives this attribute to derive the SRLG information for an LSP 154 based on the attribute value. Figure 1 below is depicting the 155 scenario. 157 The core network is typically composed of multiple network domains 158 (different providers, geographical separation, etc.) and some multi- 159 domain diversity aspects have implications on the GMPLS UNI 160 extensions defined in this document. It shall be noted that path 161 computation can be done in two different ways for each domain: GMPLS 162 supports distributed routing providing each node in the domain the 163 capability to do constraint-based path computation while the 164 utilization of the centralized path computation element (PCE) 165 approach is another option. The GMPLS UNI extensions defined in this 166 document are applicable to both path computation approaches and also 167 mixed scenarios are supported where some domains utilize the 168 distributed path computation approach while other domains are using a 169 PCE. 171 The extended overlay service model can support other extensions for 172 VPN signaling, for example, those related to latency. When requesting 173 diverse LSPs, latency may also be an additional requirement. 175 2. Conventions used in this document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC-2119 [RFC2119]. 181 In this document, these words will appear with that interpretation 182 only when in ALL CAPS. Lower case uses of these words are not to be 183 interpreted as carrying RFC-2119 significance. 185 3. Contributors 187 The Authors would like to thank Eve Varma and Sergio Belotti for 188 their review and contributions to this document. 190 4. LSP Diversity in the Overlay Extension Service Model 192 The L1VPN Framework [RFC4847] (Enhanced Mode) describes the overlay 193 extension service model, which builds upon the UNI Overlay [RFC4208] 194 serving as the interface between the CE edge node and the PE edge 195 node. In this service model, a CE receives a list of CE-PE TE link 196 addresses to which it can request a L1VPN connection (i.e., 197 membership information) and may include additional information 198 concerning these TE links. This document further builds on the 199 overlay extension service model by adding shared constraint 200 information for path diversity in the optical transport network. 201 While the L1VPN for optical transport is an example specific VPN 202 technology the term VPN is used generically since the extensions can 203 apply to GMPLS UNIs and VPNs for other technologies. 205 Two signaling variations are outlined here that may be used for 206 supporting LSP diversity within the overlay extension service model 207 considering dual-homing. While both methods utilize common 208 mechanisms in the PE network to achieve diversity, they are 209 distinguished according to whether the CE is permitted to retrieve 210 provider SRLG diversity information for an LSP from a PE1 and pass it 211 on to a PE2 (SRLG information is shared with the CE or whether a new 212 attribute is used that allows the PE2 that receives this attribute to 213 derive the SRLG information for an LSP based on this attribute value. 214 The selection between these methods is governed by both PE-network 215 specific policies and approaches taken (i.e., in terms of how the 216 provider chooses to perform routing internal to their network). 218 The first method (see 4.1.1) assumes that provider Shared Resource 219 Link Group (SRLG) Identifier information is both available and 220 shareable (policy decision) with the CE. Since SRLG IDs can then be 221 used (passed transparently between PEs via the dual-homed CE) as 222 signaled information on a UNI message, a mechanism supporting LSP 223 diversity for the overlay extension service model can be provided via 224 straightforward signaling extensions. 226 The second method (see 3.1.2) assumes that provider SRLG IDs are 227 either not available or not shareable (based on provider network 228 operator policy) with the CE. For this case, a mechanism is provided 229 where information signaled to the PE on UNI messages does not require 230 shared knowledge of provider SRLG IDs to support LSP diversity for 231 the overlay extension model. 233 While both methods could be implemented in the same PE network, it is 234 likely that a GMPLS VPN CE network would use only one mechanism at a 235 time. 237 4.1. LSP diversity for dual-homed customer edge (CE) devices 239 Single-homed CE devices are connected to a single PE device via a 240 single UNI link (could be a bundle of parallel links which are 241 typically using the same fiber cable). This single UNI link may 242 constitute a single point of failure. Such a single point of failure 243 can be avoided when the CE device is connected to two PE devices via 244 two UNI interfaces as depicted for CE1 in Figure 1 below. 246 For the dual-homing case, it is possible to establish two connections 247 from the source CE device to the same destination CE device where one 248 connection is using one UNI link to, for example, PE1 and the other 249 connection is using the UNI link to PE2. In order to avoid single 250 points of failure within the provider network, it is necessary to 251 also ensure path (LSP) diversity within the provider network in order 252 to achieve end-to-end diversity for the two LSPs between the two CE 253 devices. This document describes how it is possible to enable such 254 path diversity to be achieved within the provider network (which is 255 subject to additional routing constraints). [RFC4202] defines SRLG 256 information that can be used to allow GMPLS to provide path diversity 257 in a GMPLS controlled transport network. As the two connections are 258 entering the provider network at different PE devices, the PE device 259 that receives the connection request for the second connection needs 260 to be capable of determining the additional path computation 261 constraints such that the path of the second LSP is disjoint with 262 respect to the already established first connection entering the 263 network at a different PE device. The methods described in this 264 document allow a PE device to determine the SRLG information for a 265 connection in the provider network that is entering the network on a 266 different PE device. 268 PE SRLG information can be used directly by a CE if the CE 269 understands the context, and the CE view is limited to its VPN 270 context. In this case, there is a dependency on the provider 271 information and there is a need to be able to query the SRLG in the 272 provider network. 274 It may, on the other hand, be preferable to avoid this dependency and 275 to decouple the SRLG identifier space used in the provider network 276 from the SRLG space used in the client network. This is possible with 277 both methods detailed below. Even for the method where provider SRLG 278 information is passing through the CE device (note the CE device does 279 not need to process and decode this information) the two SRLG 280 identifier spaces can remain fully decoupled and the operator of the 281 client network is free to assign SRLG identifiers from the client 282 SRLG identifier space to the CE to CE connection that is passing 283 through the provider network. 285 Referring to Figure 1, the UNI signaling mechanism must support at 286 least one of the two mechanisms described in this document for CE 287 dual homing to achieve LSP diversity in the provider network. 289 The described mechanisms can also be applied to a scenario where two 290 CE devices are connected to two different PE devices. In this case, 291 the additional information that is exchanged across the UNI 292 interfaces also needs to be exchanged between the two CE devices in 293 order to achieve the desired diversity in the provider network. 295 This information may be configured or exchanged by some automated 296 mechanism not described in this document. 298 In the dual-homing example, CE1 can locally correlate the LSP 299 requests. For the slightly more complicated example involving CE2 and 300 CE3, both requiring a path that shall be diverse to a connection 301 initiated by the other CE device, CE2 and CE3 need to have a common 302 view of the SRLG information to be signaled. In this document, we 303 detail the required diversity information and the signaling of this 304 diversity information; however, the means for distributing this 305 information within the PE domain or the CE domain is out of scope. 307 +---+ +---+ 308 | P |....| P | 309 +---+ +---+ 310 / \ 311 +-----+ +-----+ +---+ 312 +---+ | PE1 | | |----| | 313 |CE1|----| | | | |CE2| 314 +---+\ +-----+ | |----| | 315 \ | | PE3 | +---+ 316 \ +-----+ | | 317 \| PE2 | | | +---+ 318 | | | |----|CE3| 319 +-----+ +-----+ +---+ 320 \ / 321 +---+ +---+ 322 | P |....| P | 323 +---+ +---+ 325 Figure 1 Overlay Reference Diagram 327 In an overlay model, the information exchanged between the CE and the 328 PE is kept to a minimum. 330 How diversity is achieved, in terms of configuration, distribution 331 and usage in each part of the transport networks should be kept 332 independent and separate from how diversity is signaled at the UNI 333 between the two transport networks. 335 Signaling parameters discussed in this document are: 337 o SRLG information (see [RFC4202]) 339 o Path Affinity Set 341 4.1.1. Exchanging SRLG information between the PEs via the CE device 343 SRLG information is defined in [RFC4202] and if the SRLG information 344 of an LSP is known, it can be used to calculate a path for another 345 LSP that is SRLG diverse with respect to an existing LSP. SRLG 346 information is an unordered list of SRLGs. SRLG information is 347 normally not shared between the transport network and the client 348 network; i.e., not shared with the CEs of a VPN in the VPN context. 349 However, this becomes more challenging when a CE is dual-homed. For 350 example, CE1 in Figure 1 may have requested an LSP1 from CE1 to CE2 351 via PE1 and PE3. CE1 could subsequently request an LSP2 to CE2 via 352 PE2 and PE3 with the requirement that it should be maximally SRLG 353 disjoint with respect to LSP1. Since PE2 does not have any 354 information about LSP1, PE2 would need to know the SRLG information 355 associated with LSP1. If CE1 could request the SRLG information of 356 LSP1 from PE1, it could then transparently pass this information to 357 PE2 as part of the LSP2 setup request, and PE2 would now be capable 358 of calculating a path for LSP2 that is SRLG disjoint with respect to 359 LSP1. 361 The exchange of SRLG information is achieved on a per VPN LSP basis 362 using the existing RSVP-TE signaling procedures. It can be exchanged 363 in the PATH (exclusion information) or RESV message in the original 364 request or it can be requested by the CE at any time the path is 365 active. 367 It shall be noted that SRLG information is an unordered list of SRLG 368 identifiers and the encoding of SRLG information for RSVP signaling 369 is already defined in [SRLG_info]. Even if SRLG information is known 370 for several LSPs it is not possible for the CEs to derive the 371 provider network topology from this information. 373 4.1.1.1. Operational Procedures 375 Retrieving SRLG information from a PE for an existing LSP: 377 When a dual-homed CE device intends to establish an LSP to the same 378 destination CE device via another PE node, it can request the SRLG 379 information for an already established LSP by setting the SRLG 380 information flag in the LSP attributes sub-object of the RSVP PATH 381 message (IANA to assign the new SRLG flag). As long as the SRLG 382 information flag is set in the PATH message, the PE node inserts the 383 SRLG sub-object as defined in [SRLG_info] into the RSVP RESV message 384 that contains the current SRLG information for the LSP. If the 385 provider network's policy has been configured so as not to share SRLG 386 information with the client network, the SRLG sub-object is not 387 inserted in the RESV message even if the SRLG information flag was 388 set in the received PATH message. Note that the SRLG information is 389 expected to be always up-to-date. 391 Establishment of a new LSP with SRLG diversity constraints: 393 When a dual-homed CE device sends an LSP setup requests to a PE 394 device for a new LSP that is required to be SRLG diverse with respect 395 to an existing LSP that is entering the network via another PE 396 device, the CE device sets the SRLG diversity flag (note: IANA to 397 assign the new SRLG diversity flag) in the LSP attributes sub-object 398 of the PATH message that initiates the setup of this new LSP. When 399 the PE device receives this request it calculates a path to the given 400 destination and uses the received SRLG information as path 401 computation constraints. 403 4.1.1.2. Error Handling Procedures 405 When the CE device receives a RSVP PATH message with the SRLG 406 information flag set and if the provider's network policy does not 407 permit sharing of SRLG information, the PE device shall notify the CE 408 device by sending a RSVP PathErr with a Notify error code (error code 409 to be defined) "Retrieval of SRLG information not permitted". As 410 described above, the PE device must not include the SRLG sub-object 411 with the SRLG information for the LSP in the RSVP RESV message. 413 If the PE device receives a RSVP PATH message for a new LSP with the 414 SRLG diversity flag set and SRLG information in the SRLG sub-object, 415 the PE device tries to calculate a route to the given destination 416 that is SRLG diverse with respect to the provided SRLG information. 417 If no route can be found, a RSVP PathErr message with an error code 418 (error code to be defined) "No SRLG diverse route available toward 419 destination". 421 If the PE device receives a RSVP PATH message for a new LSP with the 422 SRLG diversity flag set and SRLG information in the SRLG sub-object 423 and if the PE device does not support the SRLG sub-object, the PE 424 device shall send a PathErr message to the CE device, indicating an 425 "Unknown object class". 427 Further error handling cases will be added in the next revision of 428 this document. 430 4.1.2. Using Path Affinity Set Extension 432 The Path Affinity Set (PAS) is used to signal diversity in a pure CE 433 context by abstracting SRLG information. There are two types of 434 diversity information in the PAS. The first type of information is a 435 single PAS identifier. The Second part is the optional PATH 436 information, in the form of Source and Destination addresses of an 437 exclude path or set of paths that MAY be specified. The motive behind 438 the PAS information is to have as little exchange of diversity 439 information as possible between the VPN CE and PE elements. 441 Rather than a detailed CE or PE SRLG list, the Path Affinity Set 442 contains an abstract SRLG identifier that associates the given path 443 as diverse. Logically the identifier is in a VPN context and 444 therefore only unique with respect to a particular VPN. 446 How the CE determines the PAS identifier is a local matter for the CE 447 administrator. A CE may signal the PAS identifier as a diversity 448 object in the PATH message. This identifier is a suggested identifier 449 and may be overridden by a PE under some conditions. 451 For example, a PAS identifier can be used with no prior exchange of 452 PAS information between the CE and the PE. Upon reception of the PAS 453 identifier information the PE can infer the CEs requirements. The 454 actual PAS identifier used will be returned in the RESV message. 455 Optionally an empty PAS identifier allows the PE to pick the PAS 456 identifier. 458 Similar to the section 4.1.1 on SRLG information, a PE can return PAS 459 identifier as the response to a Query allowing flexibility. 461 A PE interprets the specific PAS identifier, for example, "123" as 462 meaning to exclude the PE SRLG information (or equivalent) that has 463 been allocated by LSPs associated with this Path Affinity Set 464 identifier "123", for any LSPs associated with the resources assigned 465 to the VPN. For example, if a Path exists for the LSP with the 466 identifier "123", the PE would use local knowledge of the PE SRLGs 467 associated with the "123" LSPs and exclude those SRLGs in the path 468 request. In other words, two LSPs that need to be diverse both 469 signal "123" and the PEs interpret this as meaning not to use shared 470 resources. Alternatively, a PE could use the PAS identifier to 471 select from already established LSPs. Once the path is established it 472 becomes the "123" identifier or optionally another PAS identifier for 473 that VPN that replaces "123". 475 The optional PAS Source and Destination Address tuple represents one 476 or more source addresses and destination addresses associated with 477 the CE Path Affinity Set identifier. These associated address tuples 478 represent paths that use resources that should be excluded for the 479 establishment of the current LSP. The address tuple information 480 gives both finer grain details on the path diversity request and 481 serves as an alternative identifier in the case when the PAS 482 identifier is not known by the PE. The address tuples used in 483 signaling is within a CE context and its interpretation is local to a 484 PE that receives a Path request from a CE. The PE can use the address 485 information to relate to PE Addresses and PE SRLG information. When 486 a PE satisfies a connection setup for a (SRLG) diverse signaled path, 487 the PE may optionally record the PE SRLG information for that 488 connection in terms of PE based parameters and associate that with 489 the CE addresses in the Path message. 491 Specifically for L1VPNs, Port Information table (PIT) [RFC5251] can 492 be leveraged to translate between CE based addresses and PE based 493 addresses. The Path Affinity Set and associated PE addresses with PE 494 SRLG information can be distributed via the IGP in the provider 495 transport network (or by other means such as configuration); they can 496 be utilized by other PEs when other CE Paths are setup that would 497 require path/connection diversity. This information is distributed on 498 a VPN basis and contains a PAS identifier, PE addresses and SRLG 499 information. 501 If diversity is not signaled, the assumption is that no diversity is 502 required and the Provider network is free to route the LSP to 503 optimize traffic. No Path affinity set information needs to be 504 recorded for these LSPs. If a diversity object is included in the 505 connection request, the PE in the Provider Network should be able to 506 look-up the existing Provider SRLG information from the provider 507 network and choose an LSP that is maximally diverse from other LSPs. 509 The mechanisms to achieve this are outside the scope of this 510 document. 512 A new VPN Diverse LSP LABEL object is specified: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Length | Type (TBA) |0| C-type (TBA)| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 1 2 3 521 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | ADDR Length |Number of PAS |D| reserved | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Path Affinity Set identifier | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Source Address (variable) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Destination Address (variable) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 2 Diverse LSP information 535 1. The Address Length field (8 bits) is the number of bytes for both 536 the source address and destination address. The address may be in 537 any format from 1 to 32 bytes but the key point is the customers 538 can maintain their existing addresses. A value of zero indicates 539 there are no addresses included. 541 2. The Number of Path Affinity (8 bits) sets is included in the 542 object. This is typically 1. Addition of other sets is for further 543 study. 545 3. The Path affinity Set identifier (4 bytes) is a single number that 546 represents a summarized SRLG for this path. Paths with that same 547 Path Affinity set should be set up with diverse paths and 548 associated with the path affinity set. A value of all zeros 549 allows the PE to pick a PAS identifier to return. A PAS 550 identifier of an established path may be different than the 551 requested path identifier. 553 4. The diversity Bit (D) (one Bit) indicates if the diversity must be 554 satisfied when set as a one. If a PE finds an established path 555 with a Path Affinity set matching the signaled Path Affinity Set 556 or the signaled Address tuple it should attempt find a diverse 557 path. 559 5. The Diverse Path Source address/destination address tuple is that 560 of an established LSP in the PE network that belongs to the same 561 Path Affinity Set identifier. If the path for these addresses is 562 not established or cannot be determined by the PE edge processing 563 the PATH request then the path is established only with the Path 564 Affinity identifier. If the path(s) for these address tuples are 565 known by the PE the PE uses the SRLG information associated with 566 these addresses. If in any case a diverse path cannot be setup 567 then the Diverse bit controls whether a path is established 568 anyway. The PE must use the PIT to translate CE Addresses into 569 provider addresses when correlating with provider SRLG 570 information. How SRLG information and network address tuples are 571 distributed is for future study. 573 4.1.2.1. Operational Procedures 575 When a CE constructs a PATH message it may optionally specify and 576 insert a Path Affinity Set in the PATH message. This Path Affinity 577 Set may optionally include the address of an LSP that that could 578 belong to the same Path Affinity Set. The Path Affinity Set 579 identifier is a value (0 through 2**32-255) that is independent of 580 the mechanism the CE or the PE use for diversity. The Path Affinity 581 Set is a single identifier that can be used to request diversity and 582 associate diversity. 584 When processing a CE PATH message in a VPN Overlay, the PE first 585 looks up the PE based addresses in the Provider Index Table (PIT). If 586 the Path Affinity Set is included in the PATH message, the PE must 587 look up the SRLG information (or equivalent) in the PE network that 588 has been allocated by LSPs associated with a Path Affinity Set and 589 exclude those resources from the path computation for this LSP if it 590 is a new path. The PE may alternatively choose from an existing path 591 with a disjoint set of resources. If a path that is disjoint cannot 592 be found, the value of the PAS diversity bit determines whether a 593 path should be setup anyway. If the PAS diversity bit is clear, one 594 can still attempt to setup the LSP. A PE should still attempt to 595 minimize shared resources but that is an implementation issue, and is 596 outside the scope of this document. 598 Optionally the CE may use a value of all zeros in the PAS identifier 599 allowing the PE to select an appropriate PAS identifier. Also the PE 600 may to override the PAS identifier allowing the PE to re-assign the 601 identifier if required. A CE should not assume that the PAS 602 identifier used for setup is the actual PAS identifier. 604 4.1.2.2. Error Handling Procedures 605 The PAS object must be understood by the PE device. Otherwise, the CE 606 should not use the PAS object. Path Message processing of the PAS 607 object SHOULD follow CTYPE 0. An Error code of IANA (TBD) indicates 608 that the PAS object is not understood. 610 When a PAS identifier is not recognized by a PE it must assume this 611 LSP defines that PAS identifier however the PE may override PAS 612 identifier under certain conditions. 614 If the identifier is recognized but the Source Address-Destination 615 address pair(s) are not recognized, this LSP must be set up using the 616 PAS identifier only. 618 If the identifier is recognized and the Source Address-Destination 619 address pair(s) are also recognized, then the PE SHOULD use the PE 620 SRLG information associated with the LSPs identified by the address 621 pairs to select a disjoint path. 623 The Following are the additional error codes: 625 1. Route Blocked by Exclude Route Value IANA (TBA). 627 4.1.2.3. Distribution of the Path Affinity Set Information 629 Information about SRLG is already available in the IGP TE database. A 630 PE network can be designed to have additional opaque records for 631 Provider paths that distribute PE paths and SRLG on a VPN basis. When 632 a PE path is setup, the following information allows a PE to lookup 633 the PE diversity information: 635 o L1 VPN Identifier 8 bytes 637 o Path Affinity Set Identifier 639 o Source PE Address 641 o Destination PE Address 643 o List of PE SRLG (variable) 645 The source PE address and destination PE address are the same 646 addresses in the VPN PIT and correspond to the respective CE address 647 identifiers. 649 Note that all of the information is local to the PE context and is 650 not shared with the CE. The VPN Identifier is associated with a CE. 651 The only value that is signaled from the CE is the Path Affinity Set 652 and optionally the addresses of an existing LSP. The PE stores source 653 and destination PE addresses of the LSP in their native format along 654 with the SRLG information. This information is internal to the PE 655 network and is always known. 657 PE paths may be setup on demand or they may be pre-established. When 658 paths are pre-established, the Path Affinity Set is set to unassigned 659 0x0000 and is ignored. When a CE uses a pre-established path the PE 660 may set the Path SRLG Path Affinity Set value if the CE signals one 661 otherwise the Path Affinity Set remains unassigned 0x0000. 663 4.2. Multi-domain LSP Diversity Aspects for Dual-homed CE Devices 665 The two mechanisms described above to achieve LSP diversity for 666 dual-homed CE devices can be applied to single-domain provider 667 networks as well as multi-domain provider networks. This section 668 addresses multi-domain aspects including both single provider multi- 669 domain networks and multi-provider networks where the subdivision 670 into multiple domains is obvious due to the organizational boundaries 671 between different providers. Specifically, when multiple providers 672 are involved, SRLG identifiers as well as PAS identifiers must be 673 administrable independently for each provider network. 675 For the single provider multi-domain case, there are two 676 possibilities how SRLG or PAS identifiers can be handled: 678 o Subdividing the identifier space into ranges assigned to domains 680 o Scoping the identifiers to domains 682 4.2.1 Subdividing Identifier Spaces into Ranges 684 Subdividing the identifier space into disjoint ranges and assigning 685 the different ranges to the different domain is one possibility to 686 apply the LSP diversity mechanisms defined in this document to a 687 multi-domain environment. This does not require additional protocol 688 extensions. Caution is, however, required when the identifiers are 689 assigned. They must be selected strictly from the identifier range 690 that has been assigned to the specific domain. From a network 691 operations perspective, this can be an option for a single provider 692 multi-domain network while it may be less applicable to multi- 693 provider networks where minimal dependency is desired. 695 4.2.2 Scoping Identifier Spaces to Domains 697 [DRAFT DOMAIN SUBOBJECTS] defines new RSVP-TE domain sub-objects for 698 the purpose of identifying domains. Domain sub-objects can be used to 699 scope SRLG or PAS identifiers to a specific domain. With this 700 extension, the full SRLG or PAS identifier space can be used within 701 each domain. When a new multi-domain LSP shall be established, the 702 diversity constraints can be signaled in the form of a sequence of a 703 scoping domain sub-object followed by the list of SRLGs (SRLG sub- 704 object) or the PAS sub-object, e.g.: [domain_sub-object(Dn), 705 SRLG_sub-object(Dn)] for domain Dn. 707 4.2.3. Multi-domain Diversity Aspects in Case Domains Utilize a PCE 709 Typically, the core network is composed of multiple network domains 710 (different providers, geographical separation, etc.) and some multi- 711 domain diversity aspects have implications on the GMPLS UNI 712 extensions defined in this document. 714 For GMPLS controlled networks, two options are defined how path 715 computation can be done: 717 o Distributed path computation, i.e., each node is capable to 718 perform constraint-based path computation 720 o Centralized path computation utilizing PCE as defined in [RFC4655] 722 The GMPLS UNI extensions defined in this document shall be applicable 723 to both path computation approaches and also mixed scenarios shall be 724 supported where some domains utilize the distributed path computation 725 approach while other domains are using a PCE. 727 In case a network domain uses a PCE, path information for all LSPs 728 crossing the domain can be stored in the PCE's database and [DRAFT 729 PATH KEY] defines a mechanism how a LSP diversity constraint can be 730 signaled in the RSVP-TE eXclude Route Object (XRO) using a unique 731 path key encoded in a path key sub-object. Further details can be 732 found in [DRAFT PATH KEY]. 734 If the scoping approach as defined in section 4.2.2 above is applied, 735 the diversity constraint for an LSP can be signaled in the form of a 736 sequence of a domain sub-object followed by a path key sub-object 737 and the path key sub-object itself contains the PK-owner-ID that 738 tells the ingress node of a domain receiving the diversity constraint 739 which PCE instance it has to consult. 741 For mixed scenarios, where some domains are using the distributed 742 path computation approach while the other domains are utilizing a 743 PCE, the LSP diversity constraint can be signaled in the form of a 744 sequence of a scoping domain sub-object followed by the list of SRLGs 745 (SRLG sub-object) or the PAS sub-object (distributed path 746 computation) or the path key sub-object for domains using a PCE. 747 Hence the diversity constraint for a domain Dn has the following 748 form: 750 [domain_sub-object(Dn), SRLG_sub-object(Dn) | PAS_subobject(Dn) | 751 PK_sub-object(Dn)] 753 5. Latency Signaling Extensions 755 Some network applications are sensitive to latency (sometimes also 756 called delay) while other applications are sensitive to latency 757 variation (sometimes also called delay variation). Specifically, real 758 time applications typically do have certain latency requirements. It 759 shall be noted that latency variation is typically not an issue for 760 TDM networks including the WDM layer. For these technologies the 761 latency is constant and there is no latency variation added. Latency 762 variation is typically caused in packet networks or when packet based 763 services are encapsulated into a constant bit rate server layer 764 signal, which requires buffering of the arriving packets that may 765 arrive in bursts. An example is an Ethernet VLAN service that is 766 mapped into a constant bit rate server layer such as an ODUk or 767 ODUflex OTN signal. 769 The GMPLS UNI as defined in [RFC4208] does not support latency as a 770 signaling parameter that would allow a CE device to signal to the PE 771 device that latency and/or latency variation constraints need to be 772 met when a path is calculated for the requested LSP. The path 773 computation function does typically calculate a route to the given 774 destination that has the least TE metric (least cost routing). 775 However, if a CE device requests an LSP via the UNI interface for an 776 application that is sensitive to latency/latency variation, it should 777 be possible to signal to the PE device that the objective function 778 should rather take latency into account instead of the TE metric. 780 In order to support latency/latency variation as path computation 781 constraint, the network has to support latency/latency variation as 782 TE metric extension as defined in [DRAFT OSPF TE METRIC EXT] - note 783 that [DRAFT OSPF TE METRIC EXT] is using the terms delay/delay 784 variation instead of latency/latency variation. 786 A latency requirement can be added to signaling in the form of a 787 constraint [DRAFT OBJECTIVE FUNCTION]. The constraint can take the 788 form of: 790 o Minimal latency 791 o Maximum acceptable latency (upper bound) 793 o Minimal latency variation 795 o Maximum acceptable latency variation (upper bound), if applicable 797 While some systems may be able to compute routes based on delay 798 metrics it is usual that minimizing the accumulated TE link metric 799 (link cost) or the number of hops subject to bandwidth reservation 800 are satisfied as the object function and delay is not considered. 801 When considering diversity latency falls after diversity constraints 802 have been satisfied. 804 Recording the latency of existing paths [DRAFT TE METRIC RECORD] to 805 ensure they meet a maximum acceptable latency can be utilized to 806 ensure latency constraint is met. 808 When a low latency path is required, the minimize latency subject to 809 other constraints criteria should be signaled. A CE device can use 810 the recorded latency to ensure that the maximum acceptable latency 811 has been met. 813 5.1. RSVP-TE Extensions 815 At the UNI, the RSVP-TE extensions as defined in [DRAFT OBJECTIVE 816 FUNCTION] SHALL be used for signaling the PE device whether a path 817 with minimal latency is requested or whether certain latency/latency 818 variation upper bound constraints shall be met for the end-to-end 819 connection, i.e., from the source CE device to the destination CE 820 device. The following objective function (OF) code point SHALL be 821 used in the OF sub-object of the ERO to indicate that latency/latency 822 variation constraints SHALL be taken into account when the path 823 computation function that is invoked by the PE node that expands the 824 route from the PE device to the destination CE device: 826 o OF code value 8 (to be assigned by IANA) is for the Minimum 827 Latency Path (MLP) OF 829 o OF code value 9 (to be assigned by IANA) is for Minimum Latency 830 Variation Path (MLVP) OF 832 Additionally, an optional OF metric-bound sub-object MAY be carried 833 within an ERO object of the RSVP-TE Path message. The two metric- 834 bound sub-objects defined in [DRAFT OBJECTIVE FUNCTION] that are 835 corresponding to the two OFs above are: 837 o metric bound sub-object of Type T=4: Cumulative Latency 838 o metric bound sub-object of Type T=5: Cumulative Latency Variation 840 The metric-bound indicates an upper bound for the path metric that 841 MUST NOT be exceeded for the ERO expending node to consider the 842 computed path as acceptable. It shall be noted that the metric bound 843 included in the RSVP-TE Path message at the UNI has end-to-end 844 significance, which means that the upper bound metric constraint MUST 845 be met for the path from the source CE device to the destination CE 846 device. 848 5.2. Operational Procedures 850 The processing rules as defined in [DRAFT OBJECTIVE FUNCTION] for the 851 OF sub-object and the optional OF metric-bound sub-object SHALL be 852 applied at the ingress PE device when the source CE device requests 853 an LSP (It shall be noted that [DRAFT OBJECTIVE FUNCTION] has a wider 854 scope and may also apply to inter-domain interfaces, i.e., when the 855 provider network is composed of multiple separate domains.). 857 5.3. Error Handling Procedures 859 The error handling rules as defined in [DRAFT OBJECTIVE FUNCTION] for 860 the OF sub-object and the optional OF metric-bound sub-object SHALL 861 be applied. 863 6. Security Considerations 865 Security for L1VPNs is covered in [RFC4847], [RFC5251] and [RFC5253]. 866 In this document, the model follows a generic GMPLS VPN based on the 867 L1VPN control plane model where CE addresses are completely distinct 868 from the PE addresses. 870 The use of a private network assumes that entities outside the 871 network cannot spoof or modify control plane communications between 872 CE and PE. Furthermore, all entities in the private network are 873 assumed to be trusted. Thus, no security mechanisms are required by 874 the protocol exchanges described in this document. 876 However, an operator that is concerned about the security of their 877 private control plane network may use the authentication and 878 integrity functions available in RSVP-TE [RFC3473] or utilize IPsec 879 ([RFC4301], [RFC4302], [RFC4835], [RFC5996], and [RFC6071]) for the 880 point-to-point signaling between PE and CE. See [RFC5920] for a full 881 discussion of the security options available for the GMPLS control 882 plane. 884 7. IANA Considerations 886 TBD 888 8. References 890 8.1. Normative References 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, March 1997. 895 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support 896 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 897 4202, October 2005. 899 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 900 "Generalized Multiprotocol Label Switching (GMPLS) User- 901 Network Interface (UNI): Resource ReserVation Protocol- 902 Traffic Engineering (RSVP-TE) Support for the Overlay 903 Model", RFC 4208, October 2005. 905 [RFC4655] Farrel, A., Vasseur, J.-P., Ash, J., "A Path Computation 906 Element (PCE)-Based Architecture", RFC4655, August 2006. 908 [RFC5251] Fedyk, D., Rekhter, Y., Editors "Layer 1 VPN Basic Mode", 909 RFC 5251, July 2008. 911 [SRLG_info] Zhang, F., Gonzalez de Dios, O., Li, D., Margaria, C., 912 Hartley, M., Ali, Z., "RSVP-TE Extensions for Collecting 913 SRLG Information", draft-ietf-ccamp-rsvp-te-srlg-collect- 914 04.txt, February 2014. 916 [DRAFT OBJECTIVE FUNCTION] Ali, Z., Swallow, G., Filsfils, C., Fang, 917 L., Kumaki, K., Kunze, R., Ceccarelli, D., Zhang, X., 918 "Resource ReserVation Protocol - Traffic Engineering 919 (RSVP-TE) extension for signaling Objective Function and 920 Metric Bound", draft-ali-ccamp-rc-objective-function- 921 metric-bound-04.txt, October 2013. 923 [DRAFT DOMAIN SUBOBJECTS] Dhody, D., Palle, U., Kondreddy, V., 924 Casellas, R., "Domain Subobjects for Resource ReserVation 925 Protocol - Traffic Engineering (RSVP-TE)", draft-ietf- 926 ccamp-rsvp-te-domain-subobjects-01.txt, January 2014. 928 [DRAFT PATH KEY] Zhang, X., Zhang, F., Gonzalez de Dios, O., Bryskin, 929 I., Dhody, D., "Extensions to Resource ReSerVation 930 Protocol-Traffic Engineering (RSVP-TE) to Support Route 931 Exclusion Using Path Key Subobject", draft-zhang-ccamp- 932 route-exclusion-pathkey-01.txt, February 2014 934 8.2. Informative References 936 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 937 Private Network (VPN) Terminology", RFC 4026, March 2005. 939 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 940 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 941 February 2011. 943 [RFC3473] Berger, L. (editor), "Generalized MPLS Signaling - RSVP-TE 944 Extensions", RFC 3473, January 2003. 946 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 947 Internet Protocol", RFC 4301, December 2005. 949 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 950 2005. 952 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 953 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 954 September 2010. 956 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 957 Requirements for Encapsulating Security Payload (ESP) and 958 Authentication Header (AH)", RFC 4835, April 2007. 960 [RFC4847] Takeda, T., Editor "Framework and Requirements for Layer 961 Virtual Private Networks", RFC 4847, April 2007. 963 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 964 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 965 2008. 967 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 968 Networks", RFC 5920, July 2010. 970 [DRAFT TE METRIC RECORD] Ali, Z., Swallow, G., Filsfils, C., Hartley, 971 M., Kumaki, K., Kunze, R., "Resource ReserVation Protocol- 972 Traffic Engineering (RSVP-TE) extension for recording TE 973 Metric of a Label Switched Path", draft-ietf-ccamp-te- 974 metric-recording-02.txt, July 2013. 976 [DRAFT OSPF TE METRIC EXT] Giacalone, S., Ward, D., Drake, J., Atlas, 977 A., Previdi, S., "OSPF Traffic Engineering (TE) Metric 978 Extensions", draft-ietf-ospf-te-metric-extensions-05.txt, 979 December 2013. 981 Copyright (c) 2013 IETF Trust and the persons identified as authors 982 of the code. All rights reserved. 984 Redistribution and use in source and binary forms, with or without 985 modification, is permitted pursuant to, and subject to the license 986 terms contained in, the Simplified BSD License set forth in Section 987 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 988 (http://trustee.ietf.org/license-info). 990 Authors' Addresses 992 Don Fedyk 993 Hewlett-Packard 994 153 Tayor Street 995 Littleton, MA, 01460 996 Email: don.fedyk@hp.com 998 Dieter Beller 999 Alcatel-Lucent 1000 Email: Dieter.Beller@alcatel-lucent.com 1002 Lieven Levrau 1003 Alcatel-Lucent 1004 Email: Lieven.Levrau@alcatel-lucent.com 1006 Daniele Ceccarelli 1007 Ericsson 1008 Email: Daniele.Ceccarelli@ericsson.com 1010 Fatai Zhang 1011 Huawei Technologies 1012 Email: zhangfatai@huawei.com 1014 Yuji Tochio 1015 Fujitsu 1016 Email: tochio@jp.fujitsu.com 1018 Xihua Fu 1019 ZTE 1020 Email: fu.xihua@zte.com.cn