idnits 2.17.1 draft-ceccadedios-ccamp-overlay-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 22 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 (July 11, 2013) is 3941 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4208' is mentioned on line 148, but not defined == Missing Reference: 'INTERCON-TE' is mentioned on line 998, but not defined == Missing Reference: 'RFC4208' is mentioned on line 536, but not defined == Missing Reference: 'LSP-DIV' is mentioned on line 989, but not defined == Missing Reference: 'TE-REC' is mentioned on line 990, but not defined == Missing Reference: 'UNI-PLUS' is mentioned on line 224, but not defined == Missing Reference: 'SRLG-COLL' is mentioned on line 992, but not defined == Missing Reference: 'UNI-APP' is mentioned on line 994, but not defined == Missing Reference: 'RFC4847' is mentioned on line 310, but not defined == Missing Reference: 'MELG' is mentioned on line 993, but not defined == Missing Reference: 'RFC5212' is mentioned on line 409, but not defined == Missing Reference: 'RFC4874' is mentioned on line 633, but not defined == Missing Reference: 'OF-TEMB' is mentioned on line 991, but not defined == Missing Reference: 'ISIS-TEMET' is mentioned on line 996, but not defined == Missing Reference: 'OSPF-TEMET' is mentioned on line 997, but not defined == Missing Reference: 'ENNI' is mentioned on line 995, but not defined == Missing Reference: 'UNI EXT' is mentioned on line 999, but not defined == Missing Reference: 'RFC4873' is mentioned on line 743, but not defined == Missing Reference: 'EDITOR NOTE' is mentioned on line 988, but not defined == Unused Reference: 'RFC2119' is defined on line 1005, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 21 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Ceccarelli 3 Internet-Draft Ericsson 4 Intended status: Informational O. Gonzalez de Dios 5 Expires: January 12, 2014 Telefonica I+D 6 F. Zhang 7 X. Zhang 8 Huawei Technologies 9 July 11, 2013 11 Use cases for operating networks in the overlay model context 12 draft-ceccadedios-ccamp-overlay-use-cases-01 14 Abstract 16 This document defines a set of use cases for operating networks in 17 the overlay model context through the Generalized Multiprotocol Label 18 Switching (GMPLS) overlay interfaces. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Variants of UNI interface . . . . . . . . . . . . . . . . . . 6 57 3.1. UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1.1. UNI example . . . . . . . . . . . . . . . . . . . . . 7 59 3.2. ONI . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.1. Routing info over the ONI . . . . . . . . . . . . . . 9 61 4. Hybrid Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Adding the PCEP to the UNI . . . . . . . . . . . . . . . . . . 11 63 5.1. Edge-node to core-node PCEP interface . . . . . . . . . . 11 64 5.2. PCEP and colored UNI . . . . . . . . . . . . . . . . . . . 13 65 5.3. Using PCEP to obtain TE reachability info . . . . . . . . 13 66 6. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 6.1. Use case P1 - Local Trigger . . . . . . . . . . . . . . . 14 68 6.2. Use case P2 - Remote Signaling . . . . . . . . . . . . . . 14 69 6.3. Use case P3 - Provisioning with requirements over the 70 UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6.4. Use case P4 - Provisioning with requirements and 72 collection request over the UNI . . . . . . . . . . . . . 17 73 6.5. Use case P5 - Advertisement of collected metrics in 74 the client layer . . . . . . . . . . . . . . . . . . . . . 17 75 6.6. Use case P6 - Provisioning with requirements over the 76 ONI . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 6.7. Use case P7 - Dual homing . . . . . . . . . . . . . . . . 18 78 7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7.1. Use case R1 - Segment Recovery - Single homing . . . . . . 19 80 7.2. Use case R2 - Local recovery - Dual Homing - Single 81 overlay node . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.3. Use case R3 -End to end Recovery - Dual homing - 83 Double overlay node . . . . . . . . . . . . . . . . . . . 20 84 7.4. Use case R4 - Combination of client protection and 85 server restoration . . . . . . . . . . . . . . . . . . . . 21 86 8. Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Use case O1 - . . . . . . . . . . . . . . . . . . . . . . 23 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 92 13. References to be added . . . . . . . . . . . . . . . . . . . . 24 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 95 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 101 The GMPLS overlay model [RFC 4208] specifies a client-server 102 relationship between networks where client and server layers are 103 managed as separate domains because of trustiness, scalability and 104 operational issue. By means of procedures from the GMPLS protocol 105 suite it is possible to build a topology in the client (overlay) 106 network from Traffic Engineering paths in the server network. In 107 this context, the UNI (User to Network Interface) is the demarcation 108 point between networks. It is a boundary where policies, 109 administrative and confidentiality issues apply that limit the 110 exchange of information. 112 This GMPLS overlay model supports a wide variety of network 113 scenarios. The packet over optical scenario is probably the most 114 popular example where the overlay model applies. 116 In order to exploit the full potential of client/server network 117 interworking in the overlay model, it may be desirable to know in 118 advance whether is it feasible or not to connect two client network 119 nodes [INTERCON-TE]. This requires to have a certain amount of TE 120 information of the server network in the client network. This need 121 not be the full set of TE information available within each network, 122 but does need to express the potential of providing TE connectivity. 123 This subset of TE information is called TE reachability information. 125 Reachability can be classified according to the available 126 information: 128 - Non-qualified reachability: The most basic form of TE 129 reachability is just the information of whether is it physically 130 feasible to connect two nodes. Thus, Non-qualified reachability 131 is the ability to be able to connect one end point to another. 133 - Qualified reachability: In addition to knowing of whether is it 134 physically feasible to connect two nodes, the qualified 135 reachability information indicates metrics of the potential 136 connection. This metric can be a cost, a service metric (delay), 137 bandwidth, etc. 139 - Reachability with associated Potential Virtual Link: In this 140 case, the client node, in addition to have the information of the 141 feasibility of reaching a given destination, it has the 142 information of a possible path, that can be established at any 143 time through UNI signalling. This possible path may have been 144 pre-computed in advance and may contain the explicit path (e.g. 145 ERO). Thus, client layer topology could be richened with this 146 potential virtual TE link information. 148 Current standard GMPLS UNI [RFC 4208] is focused on signaling and 149 extensions to the GMPLS UNI [RFC4208] are being proposed to gather a 150 tighter integration between the client packet layer and the server 151 optical one. Also, new elements, like the Path Computation element 152 (PCE), have become more popular and may also play a role in the 153 overlay context. In order to understand what are the requirements 154 that need to be fulfilled, it is necessary to understand current use 155 cases, that is, what are the network operators expecting the UNI to 156 do. 158 The first group of uses cases of the overlay model is related to the 159 automatic provisioning, by which the client (overlay) network is able 160 to set-up a connection through the server network. The second group 161 of use cases is related to the enhancement of the recovery mechanism 162 by a higher coordination of overlay and server networks. 164 Summing up, the goal of this document is to overview the network 165 scenarios where the overlay model applies and analyze the most 166 interesting aspects of the use cases that fall under the above 167 definitions, with particular focus on signaling, exchange of info, 168 operations, path computation and L1VPN aspects. 170 2. Terminology 172 The following terms are used within the document: 174 - Edge node [RFC4208]: node of the client domain belonging to the 175 overlay network, i.e. nodes with at least one interface connected 176 to the server domain. 178 - Core node [RFC4208]: node of the server domain. 180 - Access link: link between core node and edge node. It is the 181 link where the UNI is usually implemented. 183 - Remote node: node in the client domain which has no direct 184 access to the server domain but can reach it through an edge node 185 in its same administrative domain. 187 - Local trigger: LSP setup request issued to an edge node. It 188 triggers the setup of a client layer FA through the server domain 189 via a UNI interface. 191 - Remote trigger: LSP setup request issued to a remote node. It 192 triggers the setup of a client layer LSP which, upon reaching an 193 edge node, will use an FA through the server domain dynamically 194 provided via an UNI interface. 196 3. Variants of UNI interface 198 [RFC4208] defines the GMPLS UNI as an overlay interface allowing for 199 the exchange of both routing and signaling messages between a client 200 and a server domain. At that time only signaling extensions and 201 procedures for the UNI interface were defined but since them a lot of 202 RSVP-TE extensions have been defined (e.g. [LSP-DIV][TE-REC]). 204 In this section a tassonomy of different variants of UNI interfaces 205 is provided. 207 3.1. UNI 209 GMPLS UNI defined in [RFC4208] allows the exchange of RSVP-TE Path 210 messages between edge and core nodes including the Explicit Route 211 Object (ERO) or Record Route Object (RRO). This allows for the 212 explicit indication of the path (or part of it) to choose in the 213 server domain or the recording of the nodes and links chosen 214 respectively. 216 Subsequently new requirements have been added to the exchange of 217 messages between edge and core nodes. In the message flow from edge 218 to core nodes it is desirable to define a number of path computation 219 constraints that the server domain needs to consider when providing a 220 path that will be used as connection between two edge nodes. An 221 example of path computation constraints consists of: SRLG diversity, 222 max latency, max number of hops, etc. Encoding extensions for adding 223 constraints to the server domain path computation are defined in 224 [UNI-PLUS] and [LSP-DIV]. 226 Similarly it is desirable that the core nodes are able to provide the 227 edge nodes with the parameters qualifying the path provided. Such 228 set of parameters is the same identified above and encoding 229 extensions for its collection are defined in [TE-REC] and [SRLG- 230 COLL]. 232 RSVP-TE extensions are obviously inherited by the UNI interface, 233 which has significantly been augmented with respect to the RFC4208 234 version. 236 In the overlay model applied to the packet-opto environment the UNI 237 can be implemented over grey or colored interfaces. In the former 238 case the transponder is placed on the RROADM and the traffic from the 239 router to the RROADM has no G.709 framing, while in the latter the 240 transponder is moved on the router and the traffic injected into the 241 WDM domain is G.709 framed and managed as an alien lambda. From a 242 procedure point of view there is no difference between the grey and 243 the colored UNI, what is different is the type of information that 244 the WDM PCE need to be provided with in orded to compute a path in 245 the WDM domain but check its feasibility from router to router. 247 For applicability considerations regarding the GMPLS UNI please refer 248 to [UNI-APP] 250 3.1.1. UNI example 252 This section provides an example of how SRLGs, latency and other 253 types of parameters can be used in the edge node to core node 254 direction as path computation constraints and in the reverse 255 direction from core node to edge node as path qualifiers. The 256 example is applied to a packet-opto environment. 258 In the reference network below, suppose that router 1 wants RROADM A 259 to provide a path between A and G with max unidirectional latency 260 20ms and SRLG different from (37;52). Such parameters are passed to 261 A via the RSVP-TE Path message. 263 PATH (max latency 20, SRLG !(37;52)) 264 +---+ ----> /-\ /-\ /-\ +---+ 265 | 1 |******( A )-----( B )----------( C )*********| 3 | 266 +---+ \-/ \-/\ \-/ +---+ 267 | \ / | \ / \ 268 | \ / | \ / \ 269 | \ / | \ / \ 270 | \ | \ / \ 271 | / \ | \ / \ 272 +---+ /-\ / \/-\ /-\ /-\ +---+ 273 | 2 |******( D )-----( E )---( F )---------( G )*****| 4 | 274 +---+ \-/ \-/ \-/ \-/ +---+ 276 Figure 1: Path computation constraints 278 Node A performs a constrained path computation in the optical domain 279 (A-B-C-G) and provides 1 (via the RSVP-TE RESV message) with the 280 parameters qualifying the provided path e.g. max latency 12ms and 281 SRLG (11,55). 283 RESV (latency 12, SRLG (11;55) 284 +---+ <---- /-\ /-\ /-\ +---+ 285 | 1 |******( A )=====( B )==========( C )*********| 3 | 286 +---+ \-/ \-/\ \-/ +---+ 287 | \ / | \ / = 288 | \ / | \ / = 289 | \ / | \ / = 290 | \ | \ / = 291 | / \ | \ / = 292 +---+ /-\ / \/-\ /-\ /-\ +---+ 293 | 2 |******( D )-----( E )---( F )---------( G )*****| 4 | 294 +---+ \-/ \-/ \-/ \-/ +---+ 296 Figure 2: Real network topology 298 3.2. ONI 300 A different variant of GMPLS UNI interface can be implemented within 301 the overlay model context. It foresees adding some TE (Traffic 302 Engineering) topological information exchange between edge and core 303 nodes. We use the term ONI (Overlay Network Interface) to identify 304 this variant of UNI interface with such capabilities. 306 The ONI foresees the definition of a virtual topology in the server 307 layer (arbitrarily configured by the network operator) which is 308 exported by each core border node to its peering edge node by means 309 of a routing protocol (e.g. OSPF-TE, BGP-LS). Such virtual topology 310 comprises a mix of potential virtual TE-links [RFC4847] and virtual 311 nodes. 313 A virtual TE-link, as defined in RFC4847, is a provider network 314 Traffic Engineering (TE) link advertised to customers in routing 315 information for purposes that include path computation. We introduce 316 the term potential virtual TE-link to indicate those virtual TE-links 317 whose resources are not necessarily reserved or committed in the 318 server layer network. 320 A potential virtual TE link is advertised via the ONI as a real TE 321 link and hence contributes to augmenting the client layer topology. 322 Moreover it does not require the allocation of resources in the 323 server layer until it is really used thus allowing the mutually 324 exclusive sharing of server layer network resources with other 325 potential Virtual TE Links. 327 On the other side a virtual node is a collection of zero or more 328 provider network domain nodes that are collectively represented to 329 the clients as a single node that exists in the customer layer 330 network and is capable of terminating of access, inter-domain and 331 virtual links. (a virtual node can correspond 1:1 to a physical node, 332 to a part of it or to a set of nodes). 334 As per the UNI, we define two variations of ONI for the packet-opto 335 scenario, namely the ONI when we refer to grey interfaces (i.e. 336 transponder on the RROADM) and ONI++ when referring to colored 337 interfaces (i.e. transponder on the router). 339 3.2.1. Routing info over the ONI 341 The following reference network in an IPoWDM environment is used to 342 depict what kind of information needs to be advertised to the edge 343 nodes in order to augment the client layer topology. 345 +---+ /-\ /-\ /-\ +---+ 346 | 1 |******( A )-----( B )----------( C )*********| 3 | 347 +---+ \-/ \-/\ \-/ +---+ 348 | \ / | \ / \ 349 | \ / | \ / \ 350 | \ / | \ / \ 351 | \ | \ / \ 352 | / \ | \ / \ 353 +---+ /-\ / \/-\ /-\ /-\ +---+ 354 | 2 |******( D )-----( E )---( F )---------( G )*****| 4 | 355 +---+ \-/ \-/ \-/ \-/ +---+ 357 Figure 3: Real network topology 359 Where: 361 +---+ 362 | 1 | = Edge node ********* = Access Link (UNI link) 363 +---+ 365 /-\ 366 ( A ) = Core node --------- = Core domain real link 367 \-/ 369 Suppose that the network operator decides to let client network see 370 two potential virtual TE-links, one between A and C and the other 371 between D and G. Figure below show the potential virtual TE-links on 372 the left and corresponding real topology on the right. 374 +-+ /-\ /-\ +-+ | +-+ /-\ /-\ /-\ +-+ 375 |1|**( A )+++++++++++( C )**|3| | |1|**( A )+++( B )+++( C )**|3| 376 +-+ \-/ \-/ +-+ | +-+ \-/ \-/#####\-/ +-+ 377 | # # 378 | # # 379 | # # 380 | # # 381 | # # 382 +-+ /-\ /-\ +-+ | +-+ /-\ /-\ /-\ +-+ 383 |2|**( D )###########( F )**|4| | |2|**( D ) ( E ) ( F )**|4| 384 +-+ \-/ \-/ +-+ | +-+ \-/ \-/ \-/ +-+ 385 +++ = Pot. Virt. TE-link 1 | +++ = Real path of Pot.V.TE-link 1 386 ### = Pot. Virt. TE-link 2 | ### = Real path of Pot.V.TE-link 2 388 Figure 4: Virtual network topology 390 From the above figure it is possible to see that the edge nodes, in 391 order to be able to compute a path, need to know the following: 393 - Access links: availability and TE parameters 395 - Potential virtual TE-links: availability, TE parameters, 396 diversity, constraints (e.g. latency, packet loss) 398 - Virtual nodes: (in figure above a 1 to 1 relationship between 399 real and virtual nodes is assumed) availability, connectivity 400 matrix, TE parameters, diversity, constraints (in those cases 401 where a virtual node is composed of 2 or more real nodes) 403 More details on potential virtual TE links diversity can be found at 404 [MELG]. 406 4. Hybrid Nodes 408 The overlay model and interfaces can be applied also to hybrid nodes 409 [RFC5212], where it is possible to have different control plane 410 instances in the client and server domain and keep on exploiting the 411 advantages of managing the domains separately without loosing the 412 capability of making them tightly interwork. 414 5. Adding the PCEP to the UNI 416 In the GMPLS overlay model, the edge nodes do not participate in the 417 routing instance of the core network. This means that the overlay 418 network is not aware of the details (topology and TE information) of 419 the core network. Thus, it is generally assumed that, in the case of 420 a UNI request, the routing is performed in the core network. 422 The operator is able to include a set of constraints that have impact 423 on the routing that will be performed in the core network in two 424 different ways. One is to enrich RSVP-TE to include such constraints 425 (please see above), and the other one is use the well-defined PCEP 426 protocol. 428 The main advantage of using the PCEP interface is that the semantics 429 for the different queries are well defined. Moreover, in case 430 confidentiality and trustiness is an issue, the Path Key mechanism 431 can be used in the answers to hide the details of the path. 432 Different possible scenarios are shown bellow. 434 5.1. Edge-node to core-node PCEP interface 436 The first scenario foresees the provisioning of a PCEP interface from 437 the core nodes to the edge nodes. Such interface is reachable from 438 the same interfaces used for the exchange of UNI signaling messages. 439 The path computation in the server domain can be centralized or 440 distributed. In the former scenario the core node acts as a proxy 441 between the PCC on the edge node and the PCE as shown in figure 442 below. 444 +------+ 445 PCEP |Server| 446 +------------>|Domain| 447 | |PCE | 448 +---+ PCEP +-----+ +------+ 449 |PCC|----->|Proxy| 450 +---+ |-----| /-\ /-\ +---+ 451 |EN |******| CN |-----(CN )------(CN )****|EN | 452 +---+ \ - / \-/ \-/ +---+ 453 | | | 454 | | | 455 | | | 456 | | | 457 +---+ /-\ /-\ /-\ +---+ 458 |EN |******(CN )------(CN )------(CN )*****|EN | 459 +---+ \-/ \-/ \-/ +---+ 461 Figure 5: PCEP proxy on core node 463 On the other hand, when the path computation in the server domain is 464 performed in a distributed way, the PCEP interface can be exported by 465 the core nodes so to allow the edge node issue path computation 466 queries. See figure below. 468 +---+ PCEP +-----+ 469 |PCC|----->| PCE | 470 +---+ |-----| /-\ /-\ +---+ 471 |EN |******| CN |-----(CN )------(CN )****|EN | 472 +---+ \ - / \-/ \-/ +---+ 473 | | | 474 | | | 475 | | | 476 | | | 477 +---+ /-\ /-\ /-\ +---+ 478 |EN |******(CN )------(CN )------(CN )*****|EN | 479 +---+ \-/ \-/ \-/ +---+ 481 Figure 6: PCEP interface between EN and CN 483 In those cases where the addressing space is common between the 484 client and the server layer, and hence with the PCE, it is also 485 possible to have the PCC on the client layer directly speaking with 486 the server domain PCE as shown in figure below. 488 +------+ 489 PCEP |Server| 490 +------------------------->|Domain| 491 | |PCE | 492 +---+ +------+ 493 |PCC| 494 +---+ /-\ /-\ /-\ +---+ 495 |EN |******(CN)--------(CN )------(CN )****|EN | 496 +---+ \-/ \-/ \-/ +---+ 497 | | | 498 | | | 499 | | | 500 | | | 501 +---+ /-\ /-\ /-\ +---+ 502 |EN |******(CN )------(CN )------(CN )*****|EN | 503 +---+ \-/ \-/ \-/ +---+ 505 Figure 7: PCE and PCC direct connection 507 5.2. PCEP and colored UNI 509 TBD 511 5.3. Using PCEP to obtain TE reachability info 513 Although the overlay network does not participate in the routing 514 instance of the server network, RFC 4208 allows TE reachability to be 515 exchanged between both overlay and server networks. TE 516 reachability,as defined in [INTERCON-TE], is the ability to reach a 517 specific address along a TE path. In the overlay context, TE 518 reachibilty indicates if it is possible to reach from one node of the 519 overlay network to another one through the server network. Also, TE 520 reachability can indicate some TE metrics of the possible paths 521 metrics, hop count, available bandwidth, delay, shared risk. 523 The PCEP interface can be used at the UNI border to query from 524 overlay network to server network about the possible paths between 525 nodes. The answers do not need to include a full detailed ERO, but 526 just a collection of the desired metrics and, either a path key, or 527 an ERO with just the end-points. 529 6. Provisioning 531 Two different use cases can be identified for path provisioning 532 depending on where the setup trigger is issued. They will be called 533 Local and Remote Trigger in the following. Further details regarding 534 different provisioning models over the UNI can be found in [UNI-APP]. 535 What described below is in addition to the simple provisioning use 536 case without constraints defined in [RFC4208]. 538 6.1. Use case P1 - Local Trigger 540 Local Trigger is the use case defined in RFC4208, where a setup 541 trigger is issued to one of the edge nodes belonging to the overlay 542 network, i.e. directly connected to the UNI. 544 1.Trigger (with constraints) 545 | 2. Setup 546 V ------------> 547 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 548 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 549 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 550 \ / | \ / | \ | \ / 551 \ / | \ / | \ | \ / 552 \ / | \ / | \ | \ / 553 \ +--+ / | \ | \ | \ +--+/ 554 |R4| | / \ | \| |R8| 555 +--+ /-\ / \/-\ /-\ +--+ 556 3.Advertisement ( D )-----( E )---( F ) 3.Advertisement 557 \-/ \-/ \-/ 558 *** = overlay interfaces 560 Figure 8: Local trigger 562 As it is possible to see in the figure above, a trigger is issued on 563 R3 (edge node) for starting the setup request procedure over the UNI 564 interface (R3-A). Such trigger might include an arbitrary set of 565 constraints for the path computation in the optical domain. Once the 566 optical LSP is setup and an adjacency in the packet layer between R3 567 and R5 is created, it is advertised in the rest of the packet layer 568 and used by the signaling protocol (e.g. LDP) for setting up end-to- 569 end (e.g. from R1 to R7) packet LSPs. 571 6.2. Use case P2 - Remote Signaling 573 A second use case consists on the utilization of a connection 574 oriented (e.g. RSVP-TE) signaling protocol in the packet domain that 575 allows issuing the setup trigger directly on the end nodes of the 576 packet domain and using the RSVP-TE message for triggering the setup 577 of the LSP in the optical domain. 579 1.Trigger (with constraints) 580 | 2. Setup 581 V -------------> |------------>| 582 |------>----------------->------->| 583 |<-----<-----------------<--------| 584 <--------------------------------------------------|-------------| 585 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 586 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 587 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 588 \ / | \ / | \ | \ / 589 \ / | \ / | \ | \ / 590 \ / | \ / | \ | \ / 591 \ +--+ / | \ | \ | \ +--+/ 592 |R4| | / \ | \| |R8| 593 +--+ /-\ / \/-\ /-\ +--+ 594 ( D )-----( E )---( F ) 595 \-/ \-/ \-/ 597 Figure 9: Local trigger 599 The utilization of the remote trigger allows for a strict control of 600 the resources that will be used for the setup of the end to end path. 601 In particular, two further approaches are possible when using the 602 remote trigger: RSVP-TE or BGP approach. In the case of RSVP-TE it 603 is possible to exploit the capabilities of the protocol of signaling 604 LSPs across multiple domains and indicate in the ERO (explicit route 605 object) the resources that need to be included in the path. It is 606 possible to indicate a strict ERO (i.e. all the indicated resources 607 and only those ones must be used) or a loose ERO (i.e. at least the 608 indicated resources must be used but the PCEs of the different 609 domains decide autonomously how to fill the gaps in the ERO. 611 6.3. Use case P3 - Provisioning with requirements over the UNI 613 This use case applies to both the local and remote trigger scenarios 614 and describes how it is possible for the client layer to ask for a 615 connection in the server layer with some constraints. An example of 616 the constraints that can be applied to the path computation in the 617 server layer consists of the following criteria: 619 + Diversity: it is possible to indicate the resources must or 620 should be avoided during the path computation by means of the 621 Exclude Router Object (XRO) [RFC4874], the Explicit Exclusion 622 Route Subobject (EXRS) [RFC4874] and the LSP subobject [LSP-DIV]. 623 Such resources consists on: 625 -IPv4 prefix [RFC4874] 627 -IPv6 prefix [RFC4874] 629 -Unnumbered Interface ID [RFC4874] 631 -Autonomous system number [RFC4874] 633 -SRLG [RFC4874] 635 -IPv4 P2P subobject [LSP-DIV] 637 -IPv6 P2P subobject [LSP-DIV] 639 + Latency: max delay introduced by the server layer LSP [OF-TEMB] 641 + Latency variation: max latency variation allowed for the server 642 layer LSP [OF-TEMB] 644 + Cost: max cost allowed for the server layer LSP [OF-TEMB] 646 The overlay Edge Node can include into the RSVP-TE Path message an 647 arbitrary number of path computation constraints for the provisioning 648 of the LSP in the server domain. In figure below and example is 649 shown using as path computation constraints: (i) max latency should 650 be 20ms and (ii) SRLG must be different from (A;B). 652 PATH (max latency 20-SHOULD, SRLG !(A;B)-MUST) 653 +---+ ----> /-\ /-\ /-\ +---+ 654 | 1 |******( A )-----( B )----------( C )*********| 3 | 655 +---+ \-/ \-/\ \-/ +---+ 656 | \ / | \ / \ 657 | \ / | \ / \ 658 | \ / | \ / \ 659 | \ | \ / \ 660 | / \ | \ / \ 661 +---+ /-\ / \/-\ /-\ /-\ +---+ 662 | 2 |******( D )-----( E )---( F )---------( G )*****| 4 | 663 +---+ \-/ \-/ \-/ \-/ +---+ 665 Figure 10: Use Case P3 - provisioning with requirements 667 If the path computation in the server domain is able to provide an 668 LSP meeting the requirements (at least the must ones) such LSP is 669 established and a RESV message is returned to the Edge node, 670 otherwise an error message (PattErr) is returned. 672 6.4. Use case P4 - Provisioning with requirements and collection 673 request over the UNI 675 This use case is an extension of Use case P3. In addition to the 676 path request with path computation constraints, the client layer is 677 also allowed to request for the collection in the server domain of 678 the effective values of the parameters indicated as path computation 679 constraints. The collection of such parameters is indicated via 680 dedicated flags in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES in 681 the Path Message. Flags defined are: 683 - Cost collection flag [TE-REC] 685 - Latency collection flag [TE-REC] 687 - Latency Variation collection flag [TE-REC] 689 - SRLG collection flag [SRLG-COLL] 691 In the scenario depicted in figure Figure 10 a request with 692 constraints on max latency and SRLG diversity might be issued 693 together with the request of collecting e.g. the effective SRLGs of 694 the provided path. Collected parameters are returned to the overlay 695 edge node via the Record Route Object (RRO) in the RESV message. 697 6.5. Use case P5 - Advertisement of collected metrics in the client 698 layer 700 In the case of local trigger, that is when a forwarding adjacency 701 (FA) is created between two nodes in the client domain by means of an 702 LPS in the server domain, it is desirable to advertise the 703 characteristics of such FA in the client domain so that an informed 704 path computation in the client layer can be performed. 706 Interior Gateway Protocol (IGP) extensions for the advertisement of 707 the TE metrics characterizing such forwarding adjacencies have been 708 defined for IS-IS [ISIS-TEMET] and OSPF-TE [OSPF-TEMET]. 710 It is also possible to perform such advertisement by means of BGP-LS, 711 where the collected data are sent to the route reflector and then 712 forwarded to all the BGP speakers in the different client domains. 714 6.6. Use case P6 - Provisioning with requirements over the ONI 716 In the case of ONI/ONI++ each overlay edge node is provided with the 717 overlay topology of the server domain as indicated in section 718 Section 3.2. When a trigger is receiver by the edge node (local or 719 remote), it is able to choose among the different available paths 720 depending on which one meets the constraints included into the 721 trigger. When a path is selected, the signaling procedure occurs 722 accordingly with a standard RSVP-TE signaling procedure including a 723 strict (or loose) ERO. For more details please see [ENNI]. 725 6.7. Use case P7 - Dual homing 727 A quite common case is the need for provisioning two (or more) 728 optical paths with different ingress and egress nodes (i.e. different 729 CNs) with diversity constraints. This is needed to provide two 730 totally disjoint paths in the client layer without any kind of single 731 point of failure (e.g. a single UNI link or a single edge node) in 732 order to create protection schemes in the packet layer like e.g. 1+1 733 protection. 735 In this case some sort of info exchange in the client domain is 736 needed and can be provided in two ways: 738 - Coordination between 1 and 3 740 - Coordination between 2-1 and 2-3 [UNI EXT] 742 In both cases node 1 is supposed to ask the optical domain to provide 743 a path (e.g. restorable [RFC4873]) and collect its SRLGs, then pass 744 such SRLGs info to node 3 (directly or via 2). Hence node 3 will ask 745 the optical domain to provide a path (e.g. restorable) avoiding the 746 given SRLGs. 748 SRLG:27 749 +---+ /-\SRLG:21/-\ SRLG:36 /-\ +---+ 750 ++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++ 751 + +---+ \-/ \-/\ / \-/\ +---+ + 752 + | | \ / \ / \ + 753 +---+ |SRLG:(21,| \/-\/ \/-\/ \ +---+ 754 | 2 | |27,36) | ( D )------( E ) \ | 5 | 755 +---+ | | \-/ \-/ \ +---+ 756 # V | / \ \ \ # 757 # +---+ /-\ / \/-\ /-\ /-\ +---+ # 758 ###| 3 |######( F )#####( G )###( H )########( H )##| 6 |## 759 +---+ P \-/ P \-/ P \-/ P \-/ +---+ 761 +++ = working path ### = protection path 763 Figure 11: Use Case P7 - Dual homing 765 As per previous use cases it is possible to either provide the path 766 between 1 and 4, collect the SRLGs, provide the path between 3 and 6 767 with SRLG diversity constraints and than let the packet domain use 768 those two packet layer adjacencies or have 2 asking 1 and 3 to 769 respectively set up 1-4 and 3-6. 771 Whenever one of the paths is restored in the optical domain (e.g. 772 B-C fails and the path is restored using A-B-E-C), an SRLG collection 773 procedure (by 1) and exchange (to F) is needed so that a possible 774 restoration of the protection path would avoid the new SRLGs of 775 working path. Please see use case R4. 777 7. Recovery 779 7.1. Use case R1 - Segment Recovery - Single homing 781 This is one of the simplest recovery scenarios, where each overlay 782 node has a single UNI interface available on the overlay nodes and 783 hence only the server layer is in charge of restoring or protecting 784 the traffic within its domains boundaries. As it is possible to see 785 in figure below the client layer is able to recover from failures 786 within the server domain. 788 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 789 |R1|---|R2|---|R3|****( A )--X--( B )---( C )*****|R5|---|R6|---|R7| 790 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 791 | \ / | \ | 792 | \ / | \ | 793 | \ / | \ | 794 | \ | \ | 795 | / \ | \| 796 /-\ / \/-\ /-\ 797 ( D )-----( E )---( F ) 798 \-/ \-/ \-/ 800 Figure 12: Use case R1 - Segment Recovery - Single homing 802 This kind of scenario is extremely cheap in terms of resource 803 utilization but has some limitations due to a high number of single 804 points of failures which, in case of unavailability, prevent any type 805 of recovery attempt. The single points of failure are: the overlay 806 nodes (R3 and R5), the UNI links (R3-A and C-R5) and the server 807 domain border nodes (A and C). In the following sections higher 808 degrees of reliability are provided. 810 7.2. Use case R2 - Local recovery - Dual Homing - Single overlay node 812 In this use case it is possible to combine local recovery in the 813 overlay nodes (e.g. Fast Rerouting) with restoration or protection 814 in the optical domain so to be able to react to failures not only in 815 the client domain but also affecting the server layer border nodes (A 816 and C) and the UNI links (R3-A and R5-C). The number of single 817 points of failure is hence significantly reduced to just the overlay 818 nodes (R3 and R5). 820 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 821 |R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R5|---|R6|---|R7| 822 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 823 * | \ / | \ | * 824 * | \ / | \ | * 825 * | \ / | \ | * 826 * | \ | \ | * 827 * | / \ | \| * 828 * /-\ / \/-\ /-\* 829 ( D )-----( E )---( F ) 830 \-/ \-/ \-/ 832 Figure 13: Use case R2 - Local recovery - Dual Homing - Single 833 overlay node 835 7.3. Use case R3 -End to end Recovery - Dual homing - Double overlay 836 node 838 This use case focuses on recovery just in the client layer, no 839 recovery is requested to the server layer but just the provisioning 840 of LSPs with requirements (in this case diversity). 842 The provisioning of the working path occurs like the provisioning of 843 LSP over the UNI with remote trigger and with the collection of SRLGs 844 enabled. Once that the optical LSP supporting the working client LSP 845 is setup (A-B-C), the SRLGs in the optical domain are collected and 846 passed to the overlay node (R3) which forwards them to the ingress 847 node (R1) in the reverse path of the signaling process of the working 848 LSP (i.e. RSVP-TE Resv Message). 850 Once that R1 is provided with the SRLGs in the optical domains, it is 851 able to issue the signaling of the protection LSP indicating in a 852 loose ERO R5 and R7 as loose hops and the SRLG diversity in the ERO 853 expansions between them. This will lead in the provisioning of a 854 path in the photonic domain diverse from the previous one (S2-S4-S6) 855 and hence two total diverse end to end paths. In this case the 856 network will be able to recover to a single failure in any part of 857 the network without any single point of failure. 859 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 860 |R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R6|---|R7|---|R8| 861 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 862 \ | \ / | \ | / 863 \ | \ / | \ | / 864 \ | \ / | \ | / 865 \ | \ | \ | / 866 \ | / \ | \| / 867 +--+ +--+ /-\ / \/-\ /-\ +--+ +---+ 868 |R4|---|R5|****( D )-----( E )---( F )**X**|R9|---|R10| 869 +--+ +--+ \-/ \-/ \-/ +--+ +---+ 871 Figure 14: Use case R3 -End to end Recovery - Dual homing - Double 872 overlay node 874 7.4. Use case R4 - Combination of client protection and server 875 restoration 877 This is the most interesting use case when the overlay model is 878 applied to the packet/opto scenario. The packet protection and 879 optical restoration allows for a fast recovery of the traffic upon a 880 failure in the network, while the restoration in the optical domain 881 allows for always providing the packet layer with two available path 882 against an arbitrarily high number of failure in the optical network 883 (the number of failures depend on the meshing degree of the photonic 884 network). 886 Moreover the exchange of SRLGs over the UNI interface (please see 887 Provisioning use cases) makes sure that the optical path used for the 888 working branch of the packet protection and the optical path used for 889 the protection branch of the packet protection do not share any 890 resource and hence that a single failure in the optical domain does 891 not cause any traffic hit; i.e. traffic can be recovered with packet 892 protection time (tens of ms) instead of photonics restoration time 893 (tens of s). 895 The SRLG collecgion procedure is pretty simple during the 896 provisioning phase, but more complicated when one of the paths fail 897 and is restored. 899 In figure below an example is considered where a protection is 900 provided in the client layer where the working path is setup along 901 path (2-1-A-C-4-5) and its protection path along (2-3-F-H-G-6-5). 903 After the setup of the optical path between A and C (A-B-C), the 904 SRLGs of such path are collected and the overlay edge node 3 can ask 905 F for the setup of a path between F and H avoiding such SRLGs. This 906 ensures that a single failure in the optical domain will not affect 907 both the W and P. 909 +---+ /-\ /-\ /-\ +---+ 910 ++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++ 911 + +---+ \-/ \-/\ / \-/\ +---+ + 912 + | \ / \ / \ + 913 +---+ | \/-\/ \/-\/ \ +---+ 914 | 2 | | ( D )------( E ) \ | 5 | 915 +---+ | \-/ \-/ \ +---+ 916 # | / \ \ \ # 917 # +---+ /-\ / \/-\ /-\ /-\ +---+ # 918 ###| 3 |######( F )#####( G )###( H )########( H )##| 6 |## 919 +---+ \-/ \-/ \-/ \-/ +---+ 921 +++ = working path ### = protection path 923 Figure 15: Use Case R4 - Setup of paths in full diversity 925 In order to guarantee that different SRLGs will always be used for W 926 and P it is necessary to perform two different steps after the 927 provisioning of the two LSPs: 929 1. Each ingress node of the server domain paths (namely A and F) 930 must be informed that in case of restoration the path computation 931 must avoid the *actual* SRLG of the other path 933 2. Every time that either of the server domain paths is restored, 934 the collection of SRLGs must be performed and communicated to the 935 ingress node of the other LSP. 937 +---+ /-\ /-\ /-\ +---+ 938 ++| 1 |++++++( A )+++++( B )--- X --( C )+++++++++| 4 |++ 939 + +---+ \-/ \-/+ + \-/\ +---+ + 940 + | \ / + + \ + 941 +---+ | \/-\/ +/-\+ \ +---+ 942 | 2 | | ( D )------( E ) \ | 5 | 943 +---+ | \-/ \-/ \ +---+ 944 # | # # \ \ # 945 # +---+ /-\ # #/-\ /-\ /-\ +---+ # 946 ###| 3 |######( F )- X -( G )###( H )########( H )##| 6 |## 947 +---+ \-/ \-/ \-/ \-/ +---+ 949 +++ = working path ### = protection path 951 Figure 16: Use Case R4 - Restoration of paths keeping full diversity 953 In the example above a failure affecting W (link B-C) and a failure 954 affecting P (link F-G) occur, but the server network is able to 955 provide alternate paths for both of them and still provide the same 956 level of fault resiliency to the client network. 958 8. Optimization 960 8.1. Use case O1 - 962 TBD 964 9. Security Considerations 966 TBD 968 10. IANA Considerations 970 TBD 972 11. Contributors 974 Diego Caviglia 976 Email: diego.caviglia@ericsson.com 977 Francesco Fondelli 979 Email: francesco.fondelli@ericsson.com 981 12. Acknowledgements 983 The authors would like to thank Manuela Scarella and Enrico Dutti for 984 the comments and review. 986 13. References to be added 988 [EDITOR NOTE] : section to be fixed 989 [LSP-DIV] - http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-01 990 [TE-REC] - http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01 991 [OF-TEMB] - http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-02 992 [SRLG-COLL] - http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-02 993 [MELG] - http://tools.ietf.org/html/draft-beeram-ccamp-melg-00 994 [UNI-APP] - http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-03 995 [ENNI] - http://datatracker.ietf.org/doc/draft-beeram-ccamp-gmpls-enni/ 996 [ISIS-TEMET] - http://tools.ietf.org/html/draft-previdi-isis-te-metric-extensions-03 997 [OSPF-TEMET] - http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-04 998 [INTERCON-TE] - http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-00 999 [UNI EXT] - http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-01 1001 14. References 1003 14.1. Normative References 1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1006 Requirement Levels", BCP 14, RFC 2119, March 1997. 1008 14.2. Informative References 1010 Authors' Addresses 1012 Daniele Ceccarelli 1013 Ericsson 1014 Via E. Melen 77 1015 Genova - Erzelli 1016 Italy 1018 Email: daniele.ceccarelli@ericsson.com 1019 Oscar Gonzalez de Dios 1020 Telefonica I+D 1021 Don Ramon de la Cruz 82-84 1022 Madrid 28045 1023 Spain 1025 Email: ogondio@tid.es 1027 Fatai Zhang 1028 Huawei Technologies 1029 F3-5-B R&D Center, Huawei Base 1030 Shenzhen 518129 P.R.China Bantian, Longgang District 1031 Phone: +86-755-28972912 1033 Email: zhangfatai@huawei.com 1035 Xian Zhang 1036 Huawei Technologies 1037 F3-5-B R&D Center, Huawei Base 1038 Shenzhen 518129 P.R.China Bantian, Longgang District 1039 Phone: +86-755-28972913 1041 Email: zhang.xian@huawei.com