idnits 2.17.1 draft-ceccadedios-ccamp-overlay-use-cases-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2014) is 3705 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 91, but not defined == Missing Reference: 'RFC4208' is mentioned on line 120, but not defined == Missing Reference: 'ISIS-TE-METRIC' is mentioned on line 519, but not defined == Missing Reference: 'OSPF-TE-METRIC' is mentioned on line 519, but not defined == Unused Reference: 'RFC2119' is defined on line 821, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 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: September 6, 2014 Telefonica I+D 6 F. Zhang 7 X. Zhang 8 Huawei Technologies 9 Z. Ali 10 Cisco Systems, Inc. 11 R. Rao 12 Infinera Corporation 13 S. Belotti 14 Alcatel-Lucent 15 March 5, 2014 17 Use cases for operating networks in the overlay model context 18 draft-ceccadedios-ccamp-overlay-use-cases-05 20 Abstract 22 This document defines a set of use cases for operating networks in 23 the overlay model context through the Generalized Multiprotocol Label 24 Switching (GMPLS) overlay interfaces. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 6, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Client domain to server domain connectivity . . . . . . . . . 6 63 3.1. Single homing . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Dual homing . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Services between different pairs of nodes . . . . . . . . 8 66 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. UC 1 - Provisioning . . . . . . . . . . . . . . . . . . . 9 68 4.2. UC 2 - Provisioning with optimization . . . . . . . . . . 9 69 4.3. UC 3 - Provisioning with constraints . . . . . . . . . . . 10 70 4.4. UC 4 - Diversity . . . . . . . . . . . . . . . . . . . . . 11 71 4.5. UC 4A - Service Affinity . . . . . . . . . . . . . . . . . 13 72 4.6. UC 5 - Concurrent provisioning . . . . . . . . . . . . . . 13 73 4.7. UC 6 - Reoptimization . . . . . . . . . . . . . . . . . . 14 74 4.8. UC 7 - Query . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.9. UC 8 - Availability check . . . . . . . . . . . . . . . . 15 76 4.10. UC 9 - P2MP services . . . . . . . . . . . . . . . . . . . 15 77 4.11. UC 10 - Privacy . . . . . . . . . . . . . . . . . . . . . 15 78 4.12. UC 12 - Stacking of overlay interfaces . . . . . . . . . . 15 79 4.13. UC 13 - Server layer resiliency parameters . . . . . . . . 16 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Appendix I - Colored overlay . . . . . . . . . . . . 18 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 The GMPLS overlay model [RFC 4208] specifies a control plane client- 92 server relationship between networks where client and server domains 93 are managed as separate domains because of trustiness, control plane 94 scalability and operational issues. By means of procedures from the 95 GMPLS protocol suite it is possible to build a topology in the client 96 (overlay) domain from Traffic Engineering paths in the server domain. 97 In this context, the UNI (User to Network Interface) is the service 98 demarcation point between domains. It is a boundary where policies, 99 administrative and confidentiality issues apply that limit the 100 exchange of information. 102 This GMPLS overlay model supports a wide variety of network 103 scenarios. The packet over optical scenario is probably the most 104 popular example where the overlay model applies. 106 The goal of this document is to define a set of solution independent 107 use cases applicable to the overlay model. In particular it focuses 108 on the network scenarios where the overlay model applies and analyzes 109 the most interesting aspects of provisioning, recovery and path 110 computation. 112 2. Terminology 114 The following terms are used within the document: 116 - Edge node [RFC4208]: node of the client domain belonging to the 117 overlay network, i.e. nodes with at least one interface connected 118 to the server domain. 120 - Core node [RFC4208]: node of the server domain. 122 - Access link: link between core node and edge node. It is the 123 link where the UNI is usually implemented. 125 - Remote node: node in the client domain which has no direct 126 access to the server domain but can reach it through an edge node 127 in its same administrative domain. 129 - Local trigger: LSP setup request issued to an edge node. It 130 triggers the setup of a client domain LSP through the server 131 domain via a UNI interface. 133 - Remote trigger: LSP setup request issued to a remote node. It 134 triggers the setup of a client domain LSP which, upon reaching an 135 edge node, will use connectivity in the server domain. 137 All the use cases listed in the sections below can be applied to any 138 combination of, unless otherwise specified: 140 * Local or remote trigger 142 * Administrative boundary or administrative plus technological 143 boundary 145 * Layer transition on edge node or on core node (applicable to 146 administrative plus technological boundary case) 148 With local trigger we mean the case in which a trigger for the 149 provisioning of a service over the overlay interface is issued to one 150 of the edge nodes belonging to the overlay network, i.e. directly 151 connected to the UNI. 153 1.Trigger 154 | 2. Setup 155 V --------------------> 156 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 157 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 158 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 159 \ / | \ / | \ | \ / 160 \ / | \ / | \ | \ / 161 \ / | \ / | \ | \ / 162 \ +--+ / | \ | \ | \ +--+/ 163 |R4| | / \ | \| |R8| 164 +--+ /-\ / \/-\ /-\ +--+ 165 3.Advertisement ( D )-----( E )---( F ) 3.Advertisement 166 \-/ \-/ \-/ 167 *** = overlay interfaces 169 Figure 1: Local trigger 171 As it is possible to see in the figure above, a trigger is issued on 172 R3 (edge node) for starting the setup request procedure over the 173 overlay interface (R3-A). Once the LSP in the server domain is setup 174 and an adjacency in the packet domain between R3 and R5 is created, 175 it can be advertised in the rest of the client domain and used by the 176 signaling protocol (e.g. LDP) for setting up end-to-end (e.g. from 177 R1 to R7) client domain LSPs. 179 On the other hand, the remote signaling consists on the utilization 180 of a connection oriented signaling protocol in the overlay domain 181 that allows issuing the end to end service setup trigger directly on 182 the end nodes of the client domain. The signaling message, upon 183 reaching the edge node (R3), will trigger the setup of the service in 184 the server domain via the overlay interface. 186 1.Trigger 187 | 2. Signaling 3. Trigger 188 V -------------> |------------>| 189 |------>----------------->------->| 190 |<-----<-----------------<--------| 191 <----------------|---------------------------------|-------------| 192 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 193 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 194 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 195 \ / | \ / | \ | \ / 196 \ / | \ / | \ | \ / 197 \ / | \ / | \ | \ / 198 \ +--+ / | \ | \ | \ +--+/ 199 |R4| | / \ | \| |R8| 200 +--+ /-\ / \/-\ /-\ +--+ 201 ( D )-----( E )---( F ) 202 \-/ \-/ \-/ 204 Figure 2: Remote Signaling 206 The utilization of the remote trigger allows for a strict control of 207 the resources that will be used for the setup of the end to end 208 service. In order to have a correct setup of the end to end service 209 the trigger issued to R1 must include the overlay nodes to be used 210 for the setup of the service in the server domain (R3 and R5). The 211 network operator is supposed to know that the edge nodes to be used 212 are R3 and R5. 214 The second bullet above speaks about administrative boundaries and 215 administrative plus technological boundaries. Since the overlay is 216 an administrative boundary between an overlay network and a core 217 network it may happen that overlay and core network can be configured 218 based on the same switching capabilities (e.g., IP over IP) or with 219 different switching capabilities (e.g. ODU over OCh). In the former 220 case the boundary is referred to as administrative domain, while in 221 the latter, it is referred to as both administrative and 222 technological boundary. 224 In the case of boundary which is both administrative and 225 technological a further distinction is needed and regards the node 226 where the technological transition occurs, i.e., on the edge or on 227 the core node. 229 One of the most common cases of administrative and technological 230 boundary is the IP over WDM, where we speak about grey and colored 231 overlay interfaces. In other words, in the case of grey interface 232 the transponder and the domain transition are on the core node, while 233 in the case of colored interface (i.e. OTN multi-vendor IsDI based 234 upon G.698.2) they are on the edge node. The physical impairments to 235 be considered are different in the two cases (for further details 236 please see Appendix A) but the behavior of the interface does not 237 change and all use cases depicted below can be applied both to the 238 grey and colored interfaces. 240 Editor note: Actually path computation is assumed to be performed 241 typically at the server domain. The client domain can request the 242 server domain for computing a path or select among a set of paths 243 computed by the server domain and exported to the client domain as 244 virtual/abstract topology. 246 3. Client domain to server domain connectivity 248 A further distinction criterion, which is applicable to most of the 249 use cases below, is the degree of connectivity between the client 250 domain and the server domain. Three scenarios are identified: 252 * Single homing 254 * Dual homing 256 * Services between different pairs of nodes 258 3.1. Single homing 260 In the case of single homing we consider an end to end tunnel with a 261 single LSP in the client domain and one or more LSPs in the server 262 domain but a single overlay interface connecting them. The scenario 263 is shown in figure below, where an end to end circuit between R1 and 264 R7 is built over a tunnel between R3 and R5 composed by a single LSP 265 restorable between A and C or more (possibly restorable) LSPs between 266 A and C. 268 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 269 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 270 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 271 \ / | \ / | \ | \ / 272 \ / | \ / | \ | \ / 273 \ / | \ / | \ | \ / 274 \ +--+ / | \ | \ | \ +--+/ 275 |R4| | / \ | \| |R8| 276 +--+ /-\ / \/-\ /-\ +--+ 277 ( D )-----( E )---( F ) 278 \-/ \-/ \-/ 279 *** = overlay interfaces 281 Figure 3: Single homing 283 Typical examples of single restorable LSP between A and C is the case 284 of IP over WDM with single transponder on A and single transponder of 285 C with restoration capability in the WDM domain. A common case of 286 multiple LSPs between A and C, on the other side, it the splitting of 287 the electrical signal between a couple of transponders on A creating 288 a 1+1 protection terminated on a couple of transponders of C. 290 3.2. Dual homing 292 The dual homing is used to indicate a case in which two (or more) 293 access links between the edge node and one or more core nodes exist. 294 In this case we have an end to end tunnel with one or more LSPs in 295 the server domain with two or more overlay interface connecting them. 296 The scenario is shown in figure below, where an end to end circuit 297 between R1 and R7 is built over a tunnel between R3 and R5 composed 298 by two LSPs between different pairs of ingress/egress nodes (A-C and 299 D-F). 301 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 302 |R1|---|R2|---|R3|*X**( A )--X--( B )-X-( C )**X**|R5|---|R6|---|R7| 303 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 304 * | \ / | \ | * 305 * | \ / | \ | * 306 Y | \ / | \ | Y 307 * | \ | \ | * 308 * | / \ | \| * *X*=LSP X 309 * /-\ / \/-\ /-\* *Y*=LSP Y 310 ( D )--Y--( E )-Y-( F ) 311 \-/ \-/ \-/ 313 Figure 4: Dual homing 315 This network setup typically allows for fast client domain protection 316 mechanisms, e.g., Fast ReRoute (FRR). 318 3.3. Services between different pairs of nodes 320 This scenario is based on an end to end tunnel with two (or more) 321 LSPs in the client domain each of which relies on one (or more) LSPs 322 in the server domain. It is based on multiple independent single 323 homing scenarios and is typically used to provide end to end 324 diversity between two or more services. In figure below it is 325 possible to see an end to end circuit between R1 and R8 composed by 326 two services (A and B) which are built over two independent tunnels 327 between R3 and R6 and between R5 and R9 respectively. 329 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 330 |R1|---|R2|---|R3|****( A )*****( B )***( C )*****|R6|---|R7|---|R8| 331 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 332 \ | \ / | \ | / 333 \ | \ / | \ | / 334 \ | \ / | \ | / 335 \ | \ | \ | / 336 \ | / \ | \| / 337 +--+ +--+ /-\ / \/-\ /-\ +--+ +---+ 338 |R4|---|R5|####( D )#####( E )###( F )#####|R9|---|R10| 339 +--+ +--+ \-/ \-/ \-/ +--+ +---+ 341 ***=Service A 342 ###=Service B 344 Figure 5: Services between different pairs of nodes 346 Typical usage of this network scenario consists on the combination of 347 fast client domain protection mechaninsms (e.g.,1+1 protection) and 348 server domain restoration mechanisms. 350 4. Use Cases 352 4.1. UC 1 - Provisioning 354 Requirement: It must be possible to setup an unprotected end to end 355 service between two client domain nodes with no constraint in the 356 server domain. 358 This use case simply consists on providing an operator with the 359 capability of setting up a service in the client domain either by 360 means or local trigger or remote signaling. The operator does not 361 put any constraint over the path computation in the server domain 362 (e.g. unprotected, no TE metric bounds). 364 4.2. UC 2 - Provisioning with optimization 366 Requirement: It must be possible to setup a client service expressing 367 server layer parameter(s) to be optimized when computing server 368 domain path. 370 This use case applies both to the local trigger and the remote 371 signaling scenarios. In both cases the path computation function in 372 the server domain (being it centralized or distributed) is demanded 373 to provide a path between R3 and R5 which minimizes a given parameter 374 (e.g. delay, jitter, TE metric). 376 1.Trigger(param min) 377 | 2. Setup(param min) 3.Path computation(param min) 378 V ------> 379 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 380 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 381 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 382 \ / | \ / | \ | \ / 383 \ / | \ / | \ | \ / 384 \ / | \ / | \ | \ / 385 \ +--+ / | \ | \ | \ +--+/ 386 |R4| | / \ | \| |R8| 387 +--+ /-\ / \/-\ /-\ +--+ 388 ( D )-----( E )---( F ) 389 \-/ \-/ \-/ 390 *** = overlay interfaces 392 Figure 6: Provisioning with optimization 394 In the figure above the case of local trigger with specified 395 parameter to be minimized is depicted, but same considerations apply 396 to the remoe signaling (trigger on R1). In that case the parameter 397 to be minimized needs to be conveyed from R1 to R3 so that the setup 398 request over the overlay interface can be issued taking into account 399 the OF. 401 4.3. UC 3 - Provisioning with constraints 403 Requirement: It must be possible to setup a service imposing TE- 404 metrics upper bounds for a set of parameters during the path 405 computation. 407 This use cases is extremely similar to the provisioning with 408 Optimization one. This time, instead of/in addition to giving the 409 possibility of specifying which parameter needs to be optimized 410 during the path computation, the network operator is also able to 411 indicate and upper bound for a set of parameters which is not being 412 minimized in the path computation. 414 1.Trigger(constraint) 415 | 2.Setup(const) 3.Path computation(const) 416 V ------> 417 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 418 |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7| 419 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 420 \ / | \ / | \ | \ / 421 \ / | \ / | \ | \ / 422 \ / | \ / | \ | \ / 423 \ +--+ / | \ | \ | \ +--+/ 424 |R4| | / \ | \| |R8| 425 +--+ /-\ / \/-\ /-\ +--+ 426 ( D )-----( E )---( F ) 427 \-/ \-/ \-/ 428 *** = overlay interfaces 430 Figure 7: Provisioning with constraints 432 It is possible for example to ask for a path between R3 and R5 which, 433 in addition to minimizing a given OF, does not introduce a delay 434 higher than 10ms or where the jitter is not more than 3ms. 436 As per the optimization use case, when remote signaling is used 437 (trigger on R1) a mean to convey the path computation constraints 438 till the edge node (R3) is needed. 440 4.4. UC 4 - Diversity 442 Requirement: It must be possible to setup a service in the server 443 domain in diversity with respect to server domain resources or not 444 sharing the same fate with other server domain services. The network 445 operator must also be able to decide whether such diversity degree 446 must be automatically kept by the network upon failures and 447 optimization procedures. 449 This scenario is extremely common in those cases where different 450 services in the server domain are used to provision protected 451 services in the client domain. The services in the server domain can 452 be computed/provisioned sequentially or in parallel but in both cases 453 the requirement is to have them totally disjoint, so that a single 454 failure in the server domain does not impact two or more services in 455 the client domain which are supposed to be in a protection 456 relationship between each other (e.g. 1+1 protection). 458 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 459 |R1|---|R2|---|R3|*X**( A )--X--( B )-X-( C )**X**|R5|---|R6|---|R7| 460 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 461 * | \ / | \ | * 462 * | \ / | \ | * 463 Y | \ / | \ | Y 464 * | \ | \ | * 465 * | / \ | \| * *X*=Service X 466 * /-\ / \/-\ /-\* *Y*=Service Y 467 ( D )--Y--( E )-Y-( F ) 468 \-/ \-/ \-/ 470 Figure 8: Diversity 472 In a scenario like the one depicted above, it is possible to use 473 Service X and Service Y for the setup of a protected service in the 474 client domain as a fault in the server domain would not impact both 475 of them. In the case of parallel request, R3 asks the path 476 computation in the server domain to provide two totally disjoint 477 paths. On the other side, when sequential requests are issued, an 478 identifier for Service X (or a set of identifiers indicating its 479 resources) is needed so that the request for the setup of Service Y 480 can be issued with the constraint of avoiding the resources related 481 to such identifier. Please note that while Figure 8 depicts that the 482 service X and the service Y have different ingress core nodes (node A 483 and node D) but both service X and the service Y may share same 484 ingress core node. 486 Another case of provisioning with diversity is the one where the 487 operator in the client domains wants the server domain to exclude 488 some resources from the path computation. In such a case, it must be 489 possible to indicate them as path computation constraint in the 490 service setup request. Requesting an LSP with SRLG exclusion is an 491 example of such service request. 493 In addition to the provisioning of services with given diversity (and 494 inclusion/exclusion) constraints, it must be possible to ask the 495 server domain to at least keep such constraints also upon restoration 496 or optimization procedures. It would be desirable to ask the server 497 domain to relax constraints to be kept. The relaxation can be needed 498 depending on resources availability, e.g., restoration of service X 499 with partial diversity with service Y when total diversity is not 500 possible). 502 4.5. UC 4A - Service Affinity 504 There are scenarios that require two or more Label Switched Paths 505 (LSPs) to follow same route in the network. E.g., many deployments 506 require member LSPs of a bundle/ aggregated link (or Forwarding 507 Adjacency (FA)) follow the same route. Possible reasons for two or 508 more LSPs to follow the same end-to-end or partial route include, but 509 are not limited to: 511 o Fate sharing: an application may require that two or more LSPs 512 fail together. In the example of bundle link this would mean that 513 if one component goes down, the entire bundle goes down. 515 o Homogeneous Attributes: it is often required that two or more 516 LSPs have the same TE metrics like latency, latency variation, 517 etc. In the example of a bundle/ aggregated link this would meet 518 the requirement that all component links (FAs) of a bundle should 519 have same latency and latency variation. As noted in [OSPF-TE- 520 METRIC] and [ISIS-TE-METRIC], in certain networks, such as 521 financial information networks, network performance (e.g. latency 522 and latency variation) is becoming critical and hence having 523 bundles with component links (FAs) with homogeneous latency and 524 latency variation is important. 526 4.6. UC 5 - Concurrent provisioning 528 Requirement: The client network must be able to setup plurality of 529 services which are diverse and not between same pair of egde nodes. 531 Here is another case particularly interesting from a protection point 532 of view. In the case above the same edge node was asking for 533 different services in the server domain, but in order to have end to 534 end diversity (i.e. from R1 to R8 in figure below), there is the need 535 to be able to provide disjoint services between different pairs of 536 edge nodes. 538 +--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+ 539 |R1|---|R2|---|R3|****( A )*****( B )***( C )*****|R6|---|R7|---|R8| 540 +--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+ 541 \ | \ / | \ | / 542 \ | \ / | \ | / 543 \ | \ / | \ | / 544 \ | \ | \ | / 545 \ | / \ | \| / 546 +--+ +--+ /-\ / \/-\ /-\ +--+ +---+ 547 |R4|---|R5|####( D )#####( E )###( F )#####|R9|---|R10| 548 +--+ +--+ \-/ \-/ \-/ +--+ +---+ 550 ***=Service A 551 ###=Service B 553 Figure 9: Concurrent provisioning 555 In this example Service A is provided between R3 and R6 and Service B 556 between R5 and R9. Some sort of coordination is needed between R3 557 and R5 (directly between them or via R1) so that the requests to the 558 server domain can be conveniently issued. 560 4.7. UC 6 - Reoptimization 562 Requirement: It must be possible to setup a plurality of services so 563 that the overall cost of the network is minimized and not the cost of 564 a single service. 566 TBD 568 4.8. UC 7 - Query 570 Requirement: It must be possible to request information from the 571 provider regarding the actual parameters characterizing an existing 572 service (if supported by the SLA). 574 The capability of retrieving from the server domain some parameters 575 qualifying a service can be estremely useful in different cases. One 576 of them is the case o sequential provisioning with diversity 577 requirements. In the case the operator wants to set-up a service in 578 diversity from an existing one, hence it must be possible for the 579 server domain to export some parameters univocally identifying the 580 resources (e.g. SRLGs). Another case where capability of retrieving 581 from the server domain some parameters of service is useful is for 582 flooding these parameters for the forwarding or routing adjacencies 583 in the client network. Examples of recording of such parameters are 584 SRLGs, latency, latency variation and cost. 586 4.9. UC 8 - Availability check 588 Requirement: It must be possible to check if in the server domain 589 there are enough resources to setup a service with given parameters 590 or to check attributes of a better path for an existing service to 591 enable client to make reoptimization decision. 593 Client node may like to check feasibility and attributes of a better 594 path for an existing service. SRLG, Latency, latency variation, 595 Cost, etc. values are examples of attributes that client node may 596 like to inquire about (e.g., before making a reoptimization 597 decision). 599 4.10. UC 9 - P2MP services 601 Requirement: If allowed by the technology, It must be possible to 602 setup a P2MP service with given parameters. 604 TBD 606 4.11. UC 10 - Privacy 608 Requirement: It must be possible to provision different groups of 609 users with independent addressing spaces. 611 This is a particularly useful functionality for those cases where the 612 resources of the service provider are leased and shared among several 613 other service providers or customers. 615 4.12. UC 12 - Stacking of overlay interfaces 617 Requirement: It must be possible to manage a network with an 618 arbitrarily high number of administrative boundaries (i.e.,>2). 620 Operators might want to split their overlay networks in a number of 621 administrative domains for several reasons, among which simplifying 622 network operations and improving scalability. In order to do so it 623 must be possible to create a stack of overlay interfaces between the 624 different domains as shown in figure below: 626 +--+ +--+ +--+ +--+ 627 |A1|--|A2|* *|A4|--|A5| 628 +--+ +--+ * /-\ /-\ /-\ /-\ * +--+ +--+ 629 \ +--+ / *( B1)--( B2) ( B3)---( B4)* \ +--+ / 630 \|A3|/ \-/ \-/ \-/ \-/ \|A6|/ 631 +--+ * * +--+ 632 * ==== ==== ==== * 633 *|C1|---|C2|---|C3|* 634 ==== ==== ==== 636 *** = overlay interfaces 638 Figure 10: Stacking of interfaces 640 Nodes "Ax" belong to a domain which is client to the domain composed 641 by nodes "Bx". The domain composed by nodes Bx is hence server 642 domain to the "Ax" nodes domain but client to the "Cx" nodes domain. 644 A pretty common deployment of this scenario consists of IP over OTN 645 over WDM layers, where the OTN digital layer is used for the grooming 646 of IP traffic over high bit rate lambdas. In figure 8, Node Bx can 647 be assumed to be digital layer, which is interfacing with packet 648 layer nodes (Ax) across overlay interface. Digital layer nodes Bx 649 are interfacing with DWDM layer nodes Cx. If OTN (Bx) and DWDM (Cx) 650 node belong to same IGP, then this becomes multi-layer path 651 computation and signaling case, and it is out of scope of this 652 document. 654 However, as already shown in the intro of this memo, the three 655 different domains of the example could have the same switching 656 capability (e.g., IP) and be kept separate just for administrative 657 reasons. 659 4.13. UC 13 - Server layer resiliency parameters 661 Requirement: It must be possible to request an LSP in the server 662 domain with resilience parameters. The minimum set of such 663 parameters includes 1+1 protection and restoration. Moreover, it 664 must be possible for the operator to change the resilience level 665 after the path is established in the network (e.g. dynamic SLA 666 negotiation). 668 This functionality is interesting in a scenario like the one in 669 Figure 9 with two concurrent paths. Let us assume service A and B 670 are requested without any resilience requirements. If there is a 671 failure in service A, the operator can request for protection in 672 service B once this situation is detected. 674 These parameters can be used both in the case of single homing (UC1) 675 and concurrent paths (UC6). The aim of this section is to highlight 676 two sub-cases for every resilience case: 678 (1) during the provisioning the client domain can request to the 679 server domain for resilience parameters. 681 (2) Once a failure occurs, the client domain has to be notified 682 via the overlay interface thus carrying information about the 683 situation in the server domain, so the client domain can take its 684 own decisions. 686 For the different sub-use cases, the provisioning use case already 687 highlights which is the workflow and the requirements for each 688 scenario. This section does not include an example for each of them. 690 5. Security Considerations 692 TBD 694 6. IANA Considerations 696 TBD 698 7. Contributors 700 Diego Caviglia, Ericsson 702 Via E.Melen, 77 - Genova - Italy 704 Email: diego.caviglia@ericsson.com 706 Jeff Tantsura, Ericsson 708 300 Holger Way, San Jose, CA 95134 - USA 710 Email: jeff.tantsura@ericsson.com 712 Khuzema Pithewan, Infinera Corporation 713 140 Caspian CT., Sunnyvale - CA - USA 715 Email: kpithewan@infinera.com 717 Cyril Margaria, Wandl 719 Email: cyril.margaria@googlemail.com 721 John Drake, Juniper 723 Email: jdrake@juniper.net 725 Sergio Belotti, Alcatel-Lucent 727 Email: sergio.belotti@alcatel-lucent.com 729 Victor Lopez, Telefonica I+D 731 Email: vlopez@tid.es 733 Appendix A. Appendix I - Colored overlay 735 This use case applies to networks where the server domain is a WDM 736 network. In those cases it is possible to either have a grey 737 interface between client and server domains (i.e. transponder on the 738 border core node) or a colored interface between them (i.e. 739 transponder on the edge node). 741 All the previous use cases assume the case of grey interface, but 742 there are particular network scenarios in which it is possible to 743 move the transponders from the core to the edge nodes and hence save 744 on hardware cost. 746 The issue with this solution is that the path computation in the 747 server domain, being either centralized or distributed, has only 748 visibility of what is inside the server domain and hence has not all 749 the info needed to perform the validation of a path. The edge node 750 must provide the pach computation functions in the server domain with 751 a set of info needed for a correct path computation and path 752 validation from transponder to transponder (i.e. between edge nodes) 753 all along the server domain. 755 The type of information needed for this scenario can be classified 756 into three categories and must be in the context of G.698.2: 758 - Feasibility: Parameters like the output power of the transponder 759 are needed in order to state e.g. the amount of km that can be 760 reached without regeneration. 762 - Compatibility: The egress transponder must be compatible with 763 the ingress one. Parameters that influence the level of 764 compatibility can be for example the type of FEC (Forward Error 765 Correction) used or the modulation format (which also impacts the 766 feasibility together with the bit rate). 768 - Availability: Transponders can be tunable within a range of 769 lambdas or even locked to a single lambda. This impacts the path 770 computation as not every path in the network might have such 771 lambda(s) supported or available at the time the path computation 772 is performed. 774 Feasibility and compatibility are all governed by the application 775 codes. In figure below it is possible to see that the PCE is aware 776 of all the info between A and C (i.e. within the server domain scope) 777 but what is missing is info related to the transponders on R1 and on 778 R2 and of the access links. (i.e. R1-A and C-R2). 780 -Feasibility 781 -Compatibility |=====| 782 -Availability | PCE | 783 /---------->|=====| 784 / 785 / 786 +--+ / /-\ /-\ /-\ +--+ 787 |R1|*******( A )-----( B )---( C )********|R2| 788 +--+ \-/ \-/\ \-/ +--+ 789 | \ / | \ | 790 | \ / | \ | 791 | \ / | \ | 792 | \ | \ | 793 | / \ | \| 794 /-\ / \/-\ /-\ 795 ( D )-----( E )---( F ) 796 \-/ \-/ \-/ 797 *** = colored overlay interfaces 799 Figure 11: PCE feeding for colored UNI 801 There is not yet a standard set of parameters that is needed for path 802 computation in WDM networks but an example of some of them is 803 provided in the following list: 805 o Modulation format 807 o FEC (type or gain) 809 o Minimum transponder output power 811 o Bitrate 813 o Dispersion tolerance 815 o OSNR (minimum required) 817 8. References 819 8.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 8.2. Informative References 826 Authors' Addresses 828 Daniele Ceccarelli 829 Ericsson 830 Via E. Melen 77 831 Genova - Erzelli 832 Italy 834 Email: daniele.ceccarelli@ericsson.com 836 Oscar Gonzalez de Dios 837 Telefonica I+D 838 Don Ramon de la Cruz 82-84 839 Madrid 28045 840 Spain 842 Email: ogondio@tid.es 844 Fatai Zhang 845 Huawei Technologies 846 F3-5-B R&D Center, Huawei Base 847 Shenzhen 518129 P.R.China Bantian, Longgang District 848 Phone: +86-755-28972912 850 Email: zhangfatai@huawei.com 852 Xian Zhang 853 Huawei Technologies 854 F3-5-B R&D Center, Huawei Base 855 Shenzhen 518129 P.R.China Bantian, Longgang District 856 Phone: +86-755-28972913 858 Email: zhang.xian@huawei.com 860 Zafar Ali 861 Cisco Systems, Inc. 863 Email: zali@cisco.com 864 Rajan Rao 865 Infinera Corporation 866 140, Caspian CT. 867 Sunnyvale, CA-94089 868 USA 870 Email: rrao@infinera.com 872 Sergio Belotti 873 Alcatel-Lucent 874 Via Trento, 30 875 Vimercate 876 Italy 878 Email: sergio.belotti@alcatel-lucent.com