idnits 2.17.1 draft-beeram-ccamp-gmpls-enni-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4208]), 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 -- The document date (September 12, 2013) is 3879 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G-H' is mentioned on line 641, but not defined == Missing Reference: 'H-I' is mentioned on line 641, but not defined == Missing Reference: 'F' is mentioned on line 785, but not defined == Missing Reference: 'G' is mentioned on line 785, but not defined == Missing Reference: 'H' is mentioned on line 785, but not defined == Missing Reference: 'I' is mentioned on line 785, but not defined == Missing Reference: 'RFC5440' is mentioned on line 825, but not defined == Missing Reference: 'RFC5521' is mentioned on line 815, but not defined == Missing Reference: 'RFC5541' is mentioned on line 815, but not defined == Missing Reference: 'RFC5623' is mentioned on line 947, but not defined == Outdated reference: A later version (-03) exists of draft-beeram-ccamp-melg-01 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Igor Bryskin (Ed) 3 Internet Draft Wes Doonan 4 Intended status: Standards Track ADVA Optical Networking 5 Vishnu Pavan Beeram (Ed) 6 John Drake (Ed) 7 Gert Grammel 8 Juniper Networks 9 Manuel Paul 10 Ruediger Kunze 11 Deutsche Telekom 12 Friedrich Armbruster 13 Cyril Margaria 14 Coriant GmbH 15 Oscar Gonzalez de Dios 16 Telefonica 17 Daniele Ceccarelli 18 Ericcsson 20 Expires: March 12, 2014 September 12, 2013 22 Generalized Multiprotocol Label Switching (GMPLS) External Network 23 Network Interface (E-NNI): Virtual Link Enhancements for the 24 Overlay Model 25 draft-beeram-ccamp-gmpls-enni-03.txt 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on March 12, 2014. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Abstract 66 This memo is a companion document to [RFC4208]. It describes how the 67 client domain networking in the overlay model can be enhanced via 68 presenting to the client the network domain as an overlay topology 69 made of Virtual TE Links. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [RFC2119]. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Hybrid Topology................................................3 81 3. Traffic Engineering............................................7 82 3.1. Augmenting the Client layer Topology.....................11 83 3.1.1. Virtual TE Links....................................13 84 3.2. Macro SRLGs..............................................15 85 3.3. MELGs....................................................17 86 3.4. Switching Constraints....................................18 87 4. GMPLS ENNI and Multiple Server Network Domains................19 88 5. Path computation aspects......................................21 89 6. Access and Virtual TE link addressing.........................22 90 7. Use cases.....................................................22 91 7.1. Service Optimization and Restoration in Multi-layer networks 92 ..............................................................22 93 7.2. IP/MPLS Offloading with ENNI automation..................23 94 7.3. Use of PCE and VNTM in Multi-layer Network Operation.....24 95 8. Security Considerations.......................................25 96 9. IANA Considerations...........................................25 97 10. References...................................................25 98 10.1. Normative References....................................25 99 10.2. Informative References..................................25 100 11. Acknowledgments..............................................26 102 1. Introduction 104 [RFC4208] discusses how GMPLS can be applied to the overlay model, 105 which it defines to be a client network that uses a server network 106 to dynamically instantiate LSPs between the client network's nodes. 107 In the client network such an LSP is a link between two adjacent 108 client nodes, while in the server network the LSP may transit 109 multiple links and nodes; the client network is unaware of the 110 server network topology. 112 While the client network is unaware of the server network topology, 113 [RFC4208] does suggest that there may be an exchange of routing 114 information between the server network and the client network. 115 Building on this premise, this memo describes how introducing a 116 representation of server network domain resources into a client 117 network domain topology enhances client networking in the overlay 118 model 120 This document is designed to be a companion document to [RFC4208], 121 but because routing is generally not considered to be part of the 122 definition of a UNI, this document uses the term 'External Network 123 Network Interface (E-NNI)'. 'E-NNI' is generally used to indicate a 124 control plane (routing and signaling) reference point for exchange 125 of information between two control plane instances. In this 126 document, the term 'ENNI'is specifically used to describe the 127 interface between two network domains that allows the exchange of 128 routing and signaling information. 130 2. Hybrid Topology 132 Two adjacent domains in the overlay model represent, generally 133 speaking, regions of dissimilar transport technology. When an end- 134 to-end service crosses a boundary between the domains, it is 135 necessary to execute distinct forms of service activation within 136 each domain. 138 | +---+ 139 | | | - router node 140 +---+ | +---+ 141 | B | | 142 +---+ | /-\ 143 / | ( ) - WDM node 144 / | \-/ 145 / |________________________________ 146 / 147 / 148 /-\ /-\ /-\ +---+ 149 ( E )--------( G )---------( J )---------| C | 150 \-/ \-/ \-/ +---+ 151 / \ / \ 152 / \ / \ 153 / \ / \ 154 / \ / \ 155 / \ / \ 156 +---+ /-\ /-\ /-\ +---+ 157 | A |---------( F )---------( H )---------( I )---------| D | 158 +---+ \-/ \-/ \-/ +---+ 160 Figure 1: Sample hybrid topology 162 For example, in the hybrid network illustrated in Fig 1, 163 provisioning a transport service between two GMPLS-enabled IP 164 routers (clients) on either side of the optical WDM transport 165 topology (server network domain) requires operations in two distinct 166 layer networks; the client layer network interconnecting the routers 167 themselves, and the server layer network interconnecting the optical 168 transport elements in between the routers. 170 The activation of the end-to-end service begins with a path 171 determination process, followed by the initiation of a signaling 172 process from the ingress client network element along the determined 173 path, per the example illustrated in Fig 2a-c. 175 +---+ 176 | B | | 177 +---+ | ##### - client-layer service 178 / | ***** - server-layer WDM service 179 / |_____________________________________ 180 / 181 / 182 / 183 /-\ /-\ /-\ +---+ 184 ( E )--------( G )---------( J )---------| C | 185 \-/ \-/ \-/ +---+ 186 / \ / \ 187 / \ / \ 188 / \ / \ 189 / \ / \ 190 / \ / \ 191 +---+ ######## /-\ /-\ /-\ +---+ 192 | A |---------( F )---------( H )---------( I )---------| D | 193 +---+ \-/ \-/ \-/ +---+ 195 Figure 2a: Hierarchical service activation - 196 Client-layer service setup is initiated. 198 +---+ 199 | B | | 200 +---+ | ##### - client-layer service 201 / | ***** - server-layer WDM service 202 / |_____________________________________ 203 / 204 / 205 / 206 /-\ /-\ /-\ +---+ 207 ( E )--------( G )---------( J )---------| C | 208 \-/ *\-/* *\-/ +---+ 209 */ \* */ \ 210 */ \* */ \ 211 */ \* */ \ 212 */ \* */ \ 213 */ \*/ \ 214 +---+ ######## /-\ /-\ /-\ +---+ 215 | A |---------( F )---------( H )---------( I )---------| D | 216 +---+ \-/ \-/ \-/ +---+ 218 Figure 2b: Hierarchical service activation - 219 Server-layer WDM service that caters to the 220 client-layer service is established within the 221 core. 223 +---+ 224 | B | | 225 +---+ | ##### - client-layer service 226 / | ***** - server-layer WDM service 227 / |____________________________________ 228 / 229 / 230 / 231 /-\ /-\ /-\ ######## +---+ 232 ( E )--------( G )---------( J )---------| C | 233 \-/ #*\-/*# #*\-/ +---+ 234 #*/ \*# #*/ \ 235 #*/ \*# #*/ \ 236 #*/ \*# #*/ \ 237 #*/ \*#*/ \ 238 #*/ \*/ \ 239 +---+ ######## /-\ /-\ /-\ +---+ 240 | A |---------( F )---------( H )---------( I )---------| D | 241 +---+ \-/ \-/ \-/ +---+ 243 Figure 2c: Hierarchical service activation - 244 Client-layer service setup is resumed and 245 the end-to-end connection is established. 247 3. Traffic Engineering 249 The previous section outlines the basic method for activating end- 250 to-end services across a multi-domain/multi-layer network. As a 251 necessary part of that process an initial path selection process is 252 to be performed, whereby an appropriate path between the desired 253 endpoints is to be determined through some means. Further, per 254 expectations set through current practices with regard to service 255 provisioning in homogeneous networks, operators expect that the 256 underlying control plane system provides automated mechanisms for 257 computing the desired path(s) between network endpoints. 259 In particular, operators do not expect under normal circumstances to 260 be required to explicitly specify the end-to-end path; rather, they 261 expect to be able to specify just the endpoints of the path and rely 262 on an automated computational process to identify and qualify all 263 the elements and links on the path between them. Hence when 264 operating a hybrid multi-layer network such as that described in Fig 265 1, it is necessary to extend existing traffic engineering and path 266 computation mechanisms to operate in a similar manner. 268 Path computation and qualification operations occur at the path 269 computation element (PCE - RFC4655) selected by ingress network 270 element of an end-to-end service. In order to be able to compute and 271 qualify paths, the PCE should be provided with information regarding 272 the traffic engineering capabilities of the layer network to which 273 it is associated with, in particular, the topology of the layer 274 network and what layer-specific transport capabilities exist at the 275 various nodes and links in that topology. 277 It is important to note that topology information is layer-specific; 278 e.g. path computation and qualification operations occur within a 279 given layer, and hence information about topology and resource 280 availability are required for the specific layer to which the 281 connection belongs. The topology and resource availability 282 information required by a path computation element in the client 283 layer is quite distinct from that required by a path computation 284 element in the server layer network. Hence, the actual server layer 285 traffic engineering links are of no importance for the client layer 286 network. In fact, it can be desirable to block their advertisements 287 into the client TE domain by the border nodes. 289 For example, in the sample hybrid network (Fig 1) there are multiple 290 transport elements supporting client the connection (in this memo 291 terms "connection" and "LSP" are used interchangeably) between the 292 GMPLS-enabled clients A and C, the server layer topology between 293 them includes several nodes and links. However, in this example the 294 optical network elements are not capable of switching traffic with 295 the client layer granularity (i.e. IP/MPLS packets), as the optical 296 network elements are lambda switches, not IP/MPLS switches. Hence, 297 while the intervening server layer network elements may physically 298 exist along the path, they are not a part of the topology required 299 by the client layer nodes for the purposes of traffic engineering in 300 the client layer network. 302 An example of what the client layer Traffic Engineering topology 303 would look like for the sample hybrid network is shown in the top 304 half of Fig 3. 306 | +++++ - client-layer TE link 307 | ~~~~~ - server-layer TE link 308 | ===== 309 | | N | - client-layer TE node (only) 310 Client TE ===== | ===== 311 Database | B | | {N} - server-layer TE node (only) 312 ===== | ===== 313 + | |{N}| - server and client-layer 314 + | ===== TE node 315 + |_____________________________________ 316 + 317 ===== ===== ===== 318 |{E}|~~~~~~~~~{G}~~~~~~|{J}|+++++++++| C | 319 ===== ~ ~ ===== ===== 320 ~ ~ ~ ~ 321 ~ ~ ~ ~ 322 ~ ~ ~ ~ 323 ===== ===== ~ ===== ===== 324 | A |++++++++ |{F}|~~~~~~~~{H} ~~~~~|{I}|+++++++++| D | 325 ===== ===== ===== ===== 327 Physical +---+ | 328 Topology | B | | ##### - client-layer service 329 +---+ | ***** - server-layer WDM service 330 / |__________________________________ 331 / 332 / 333 /-\ /-\ /-\ ######## +---+ 334 ( E )--------( G )-----( J )---------| C | 335 \-/ #*\-/*# #*\-/ +---+ 336 #*/ \*# #*/ \ 337 #*/ \*#*/ \ 338 #*/ \*/ \ 339 +---+ ########## /-\ /-\ /-\ +---+ 340 | A |-----------( F )-----( H )-----( I )---------| D | 341 +---+ \-/ \-/ \-/ +---+ 343 Figure 3: Traffic engineering - ERO with "loose hop" 344 [Path = {A,F,J,C} (with J loose)]. 346 In this example, the TE topology associated with the client layer 347 network is indicated by the links marked with '+' and nodes marked 348 without brackets, whereas the TE topology associated with the server 349 layer network is indicated by the links marked with '~' and nodes 350 marked in '{}'. The nodes at the edge of the server layer network 351 are visible in both the topologies. The client topology is capable 352 of switching traffic within the client layer, whereas the server 353 topology is capable of switching traffic within the server layer. 355 In this example, if the "B" router attempts to determine a path to 356 the "D" router it will be unable to do so, as the client topology to 357 which the B and D routers is connected does not include a full path 358 made of just client layer links between them. The only way to setup 359 an end-to-end path in this case is to use an ERO with a "loose hop" 360 across the server layer domain as illustrated in Fig 3. This would 361 cause the server layer to create the necessary link in the client 362 layer topology on the fly. However, this approach has a few 363 drawbacks - [a] the necessity for the operator to specify the ERO 364 with the "loose" hop; [b] potential sub-optimal usage of server 365 layer network resources; [c] unpredictability with regard to the 366 fate-sharing of the new link (that is created on the fly) with other 367 links of the client layer topology. 369 In order to be able to compute an end-to-end path between the two 370 client layer endpoints, the client topology must be sufficiently 371 augmented to indicate where there are paths through the server 372 topology, which can provide connectivity between nodes in the client 373 topology. In other words, in order for a client to compute path(s) 374 across the server layer network to other clients, the feasible paths 375 across the server layer network should be made available (in terms 376 of TE links and nodes that exist in the client layer network) to all 377 the clients. This is discussed in detail in the next section. 379 As it is mentioned already, in the overlay model the client and 380 network domains, generally speaking, exist in separate layer- 381 networks. One important use case, however, is when the client and 382 network topologies belong to the same layer network. For example, IP 383 routers, connected via GMPLS ENNI to a WDM network, could be capable 384 of terminating optical trails being lambda switched by the network. 385 The method described in the following sections allows also 386 partitioning a single layer network into domains. Those domains do 387 not need to leak the full routing information to their neighboring 388 domains but rather provide sufficient information for a path 389 computation engine to route connections across a multi-domain 390 network. 392 3.1. Augmenting the Client layer Topology 394 In the example hybrid network, shown below in Fig 4, consider a 395 scenario, where each GMPLS-enabled IP router is connected to the 396 optical WDM transport network via a transponder. Further, consider 397 the situation, where the transponder on node F can be connected to 398 the transponder on node J via the optical path F-G-H-J. Suppose, a 399 lambda LSP is provisioned in the server layer along this path and 400 advertised (as a TE link) into the client layer network. With the 401 availability of this TE link, the path computation function at node 403 Client TE ===== | +++++ - client-layer TE link 404 Database | B | | 405 ===== | ===== client-layer 406 + | | N | - TE node 407 + | ===== 408 + |_________________________________ 409 + 410 + 411 ===== ===== ===== 412 |{E}| {G} |{J}|+++++++++| C | 413 ===== ===== ===== 414 +++ 415 ++ 416 ++ 417 ++ 418 +++ 419 ===== ===== ===== ===== 420 | A |++++++++ |{F}| {H} |{I}|+++++++++| D | 421 ===== ===== ===== ===== 423 Physical +---+ 424 Topology | B | 425 +---+ | 426 / | ***** - server-layer WDM service 427 / |____________________________________ 428 / 429 / 430 / 431 /-\ /-\ /-\ +---+ 432 ( E )--------( G )---------( J )---------| C | 433 \-/ *\-/* *\-/ +---+ 434 */ \* */ \ 435 */ \* */ \ 436 */ \* */ \ 437 */ \* */ \ 438 */ \*/ \ 439 +---+ /-\ /-\ /-\ +---+ 440 | A |---------( F )---------( H )---------( I )---------| D | 441 +---+ \-/ \-/ \-/ +---+ 443 Figure 4: Traffic engineering - end-to-end path 444 computation.[The client layer "TE link" between F 445 and J is produced by creating the underlying 446 server-layer connection; Node A has visibility 447 to end-to-end (A to C) client-layer links and 448 can do CSPF] 450 A is able to compute an end-to-end path from A to C. In this 451 example, in order for the TE link to be made available in the client 452 layer network topology, the network resources supporting the 453 underlying server layer LSP are fully committed beforehand. 455 As another scenario, consider a network configuration, where the 456 transponders on nodes E, F, J and I are connected to each other via 457 directionless ROADM technology. In this case it is physically 458 possible to connect any transponder to any other transponder in the 459 server layer network. As there are transport capabilities available 460 in the server layer network between every pair of elements with an 461 adaptation function to the client layer network, the operator in 462 this case would not wish to commit any network resources in the 463 server layer network until a client LSP is signaled. The next 464 section proposes a method to address this common operational 465 requirement. 467 3.1.1. Virtual TE Links 469 A "Virtual TE Link" as defined in section 7.3.3 of [RFC4847] is a TE 470 link that is advertised into the client layer network. The 471 advertisement includes information about available but not 472 necessarily reserved/committed resources in the server layer network 473 necessary to support that TE link. In other words, Virtual TE Links 474 represent specific transport capabilities available in the server 475 layer network, which can support the establishment of LSPs in the 476 client layer network. 478 The two fundamental properties of a Virtual TE Link are: [a] it is 479 advertised just like a real TE link and thus contributes to the 480 buildup of the client layer network topology; and [b] it does not 481 require allocation of resources at the server layer until used, thus 482 allowing the mutually exclusive sharing of server layer network 483 resources with other Virtual TE Links. 485 Client TE ===== | +++++ - client-layer TE link 486 Database | B | | 487 ===== | ===== client-layer 488 + | | N | - TE node 489 + | ===== 490 + |____________________________________ 491 + 492 + 493 ===== ===== ===== 494 |{E}| {G} |{J}|+++++++++| C | 495 ===== ===== ===== 496 +++ 497 +++ 498 +++ 499 ++ 500 +++ 501 ===== ===== ===== ===== 502 | A |+++++++++|{F}| {H} |{I}|+++++++++| D | 503 ===== ===== ===== ===== 505 Physical +---+ 506 Topology | B | | 507 +---+ | *-*-* - potential server-layer 508 / | WDM service 509 / |______________________________________ 510 / 511 / 512 / 513 /-\ /-\ /-\ +---+ 514 ( E )--------( G )---------( J )---------| C | 515 \-/ -\-/- -\-/ +---+ 516 */ \* */ \ 517 -/ \- -/ \ 518 */ \* */ \ 519 -/ \- -/ \ 520 */ \*/ \ 521 +---+ /-\ /-\ /-\ +---+ 522 | A |---------( F )---------( H )---------( I )---------| D | 523 +---+ \-/ \-/ \-/ +---+ 525 Figure 5: Traffic engineering - end-to-end path 526 computation with "Virtual TE Links". [The 527 "Virtual TE link" between F and J is created 528 in the client layer without actually 529 instantiating the underlying server-layer 530 connection; Node A has visibility to end- 531 to-end client-layer links and can do CSPF] 533 In the example shown in Fig 5, the availability of a lambda channel 534 along the path F-G-H-J results in the advertisement by nodes F and J 535 of a Virtual TE Link between F and J into the client layer network 536 topology (+++ line). With the advertisement of this Virtual TE 537 Link, the path computation function at node A is able to compute an 538 end-to-end path from A to C. 540 Whenever a Virtual TE Link gets selected and signaled in the ERO of 541 a client layer LSP, it ceases temporarily to be "virtual" and 542 transforms into a regular TE link. When this transformation takes 543 place, the clients will notice the change in the advertised 544 available bandwidth of this TE link. Also, all other Virtual TE 545 Links that share in a mutual exclusive way some of server layer 546 resources with the TE link in question SHOULD start advertising 547 "zero" available bandwidth. Likewise, the TE network image reverts 548 back to the original form as soon as the last client layer LSP, 549 going through the TE link in question, is released, i.e. Virtual TE 550 Link becomes "virtual" again. 552 The overlay topology, advertised into the client domain as a set of 553 Virtual TE Links, along with access TE links (the TE links 554 interconnecting client network elements with the network domain) 555 makes up the topology that in the overlay model allows for the 556 client domain path computation function to compute end-to-end paths 557 interconnecting client network elements across the network domain. 559 3.2. Macro SRLGs 561 The Virtual TE Links, which are advertised into the client layer 562 network topology, cannot be assumed to be independent. It is quite 563 possible for a given Virtual TE Link to share fate with one or more 564 other Virtual TE Link(s). This is because the underlying server 565 layer LSPs (established or potential) can traverse the same server 566 layer network link and/or node, and failure of any such shared 567 link/node would make all such LSPs inoperable (along with the 568 Virtual TE Links supported by the LSPs). If diverse end-to-end paths 569 for client layer LSPs are to be computed, the fate sharing 570 information of the Virtual TE Links needs to be taken into account. 571 The standard way of addressing this problem is via the concept of 572 Shared Risk Link Group (SRLG). Specifically, a network resource 573 shared by two or more TE links is identified via a network scope 574 unique number (SRLG ID) and advertised within each such TE link 575 advertisement. 577 A "traditional" SRLG (per [RFC4202]) represents a shared physical 578 network resource, upon which normal function of a link depends. Such 579 SRLGs can also be referred to as physical SRLGs. Zero, one or more 580 physical SRLGs could be identified and advertised for every TE link 581 in a given layer network. There is a scalability issue with physical 582 SRLGs in multi-layer environments. For example, if a server layer 583 LSP serves a client layer link, every server layer link and node 584 traversed by the LSP must be considered as a separate SRLG. The 585 number of server layer SRLGs to be advertised to client layer per 586 TE link is directly proportional to the number of hops traversed by 587 the underlying server layer LSP. 589 This document introduces a notion of Macro SRLGs, which addresses 590 this scaling problem. Macro SRLGs have the same protocol format as 591 their physical counterparts and can be assigned automatically for 592 each TE link that is advertised into the client layer network 593 supported by an underlying server layer LSP (instantiated or 594 otherwise). A Macro SRLG represents a shared path segment that is 595 traversed by two or more of the underlying server layer LSPs. Each 596 shared path segment can be viewed as a set of shared server layer 597 resources. The actual procedure for deriving the Macro SRLGs is 598 beyond the scope of this document. 600 Client TE ===== | +25+ - client-layer TE link 601 Database | B | | with SRLG ID "25" 602 ===== |__________________________________ 603 + 604 + 605 + 606 + 607 + 608 ===== ===== ===== 609 |{E}| {G} |{J}|+++++++++| C | 610 ===== ===== ===== 611 ++25++ +++ 612 +++++ +++ 613 ++++ 614 ++ +++++ 615 +25+ +++++++ 616 ===== ===== ===== ===== 617 | A |+++++++++|{F}| {H} |{I}|+++++++++| D | 618 ===== ===== ===== ===== 619 +---+ 620 | B | 621 +---+ ***** - F-J WDM service 622 / @@@@@ - E-I WDM service 623 / 624 / 625 / 626 / 627 /-\ @@@@@@@@ /-\ /-\ +---+ 628 ( E )--------( G )---------( J )---------| C | 629 \-/ *\-/*@ @*\-/@ +---+ 630 */ \*@ @*/ \@ 631 */ \*@ @*/ \@ 632 */ \*@ @*/ \@ 633 */ \*@*/ \@ 634 */ \*/ \@ 635 +---+ /-\ /-\ /-\ +---+ 636 | A |---------( F )---------( H )---------( I )---------| D | 637 +---+ \-/ \-/ \-/ +---+ 639 Figure 6: Macro SRLGs - ["TE links" E-I and F-J share fate 640 since the underlying server-layer connections 641 traverse the same path segments [G-H][H-I]. Macro 642 SRLG-ID "25" is assigned to both "TE links"] 643 3.3. MELGs 645 If two or more Virtual TE Links share fate, it means that the links 646 could be concurrently activated and used by client LSPs with a 647 caveat that the links could be taken out of service by a single 648 network failure, and, thus, cannot be used in the same protection 649 scheme. There could be a stronger (than fate sharing) relationship 650 between two or more Virtual TE Links. Because a set of Virtual TE 651 Links can depend on the same uncommitted network resources, the 652 situation can arise, when only one Virtual TE Link from the set 653 could be activated at any given time. In other words, two or more 654 Virtual TE Links can be mutually exclusive. 656 One example of the mutually exclusive relationship of Virtual TE 657 Links is when the paths for the server layer network LSPs supporting 658 the Virtual TE Links not only intersect, but also require usage of 659 the same resource (e.g. lambda channel) on the intersection. Another 660 example is when the said paths depend on a common physical resource 661 (e.g. transponder, regenerator, wavelength converter, etc.) that 662 could be used only by one LSP at a time. 664 For a client path computation function (especially a centralized one 665 capable of concurrent computation of multiple paths) it is important 666 to know about such mutually exclusive relationship between Virtual 667 TE Links. This document recommends the use of the extensions defined 668 in [MELG] to address this requirement. 670 3.4. Switching Constraints 672 Generally speaking, it SHOULD NOT be assumed that a Virtual TE Link 673 advertised by a given network domain border node can be cross- 674 connected within a client LSP with every access TE link advertised 675 by the said node. This circumstance necessitates the specification 676 of connectivity constraints by network domain border nodes. If such 677 information is not available for client domain path computers, there 678 is a significant risk of provisioning failures of client LSPs, 679 if/when they are signaled with the computed paths (see, Figure 7). 680 This document recommends the use of the advertisements specified in 681 [GEN_CNSTR] and [OSPF_GEN_CONSTR] to address the network element 682 switching limitations problem. 684 +---+-a1------b1--/-\--b3--------------c1--/-\--c3-----d1-+---+ 685 | A | ( B ) ( C ) | D | 686 +---+-a2------b2--\-/--b4--------------c2--\-/--c4-----d2-+---+ 688 Access TE-links: TE links served Valid paths: 689 By the server domain: 690 a1-b1, c3-d1 b3-c1 [a1-b1][b3-c1][c3-d1] 691 a2-b2, c4-d2 b4-c2 [a2-b2][b4-c2][c4-d2] 693 Binding constraints: Invalid paths: 694 b1<->b3 [a1-b1][b4-c2]... 695 b2<->b4 [a2-b2][b3-c1]... 696 c1<->c3 [a1-b1][b3-c1][c4-d2] 697 c2<->c4 [a2-b2][b4-c2][c3-d1] 699 Figure 7: Switching Constraints 701 4. GMPLS ENNI and Multiple Server Network Domains 703 In the previous sections a single server network domain GMPLS ENNI 704 configuration was considered. The said configuration is modeled as a 705 set of client nodes, belonging to one or more client domains, 706 connected to a single server network domain. The connectivity is 707 realized via access links in the data plane and GMPLS ENNI 708 interfaces in the control plane. The server domain is independent 709 from the client domain(s) (administratively and from the Traffic 710 Engineering and control/management plane point of view). The network 711 domain exposes its resources to the clients in a form of Virtual TE 712 Links, thus, enabling the clients to influence the way their LSPs 713 are routed across the network domain. 715 There are important use cases that require client LSPs to traverse 716 more than one server network domains. In such use cases the server 717 domains, generally speaking, are independent from each other and 718 from each of the client domains. In such configurations the clients 719 would still want to control the routing of their LSPs in each of the 720 server domains, the LSPs are going through, for the same reasons it 721 is necessary to do so in the single server domain configuration 722 (e.g. diversity, fate sharing, MELG considerations, etc.). 723 Fortunately, the Virtual TE Link approach allows for exposing of the 724 resources of multiple network domains in the same way as in the 725 single server domain case, and, thus, provides the same tools for 726 dynamic provisioning of client LSPs across either single or multiple 727 server network domains. 729 Multiple server network domains are modeled as separate independent 730 networks interconnected with each other on their respective border 731 nodes via inter-domain links in the data plane and GMPLS ENNI 732 interfaces in the control plane. A network border node sees no 733 difference between an access link and an inter-domain link 734 terminated on the node (nor can it tell whether it is connected via 735 a given link to a client node or a border node of a neighboring 736 server network domain). Just like in the single-domain case, each 737 server domain exposes its resources to other server and client 738 network domains via Virtual TE Links configured in accordance with 739 local domain policies. It is responsibility of server domain border 740 nodes to advertise into the neighboring domains all access, inter- 741 domain and Virtual TE Links it locally terminates, as well as 742 imposed on them switching limitations. The said advertisements are 743 flooded into the client domains and populate the client path 744 computer's TEDs. Successful path computations produce end-to-end 745 paths in the form of access, Virtual and inter-domain TE link 746 chains. 748 Client TE | +++++ - client-domain TE link 749 Database | 750 | ===== 751 | | N | - client-domain TE node 752 | ===== 753 |____________________________________ 755 {G} {K} 757 ===== ===== ===== ===== ===== ===== 758 | A |+++++|{F}|+++++|{H}|+++++|{J}|+++++|{L}|+++++|{D}| 759 ===== ===== ===== ===== ===== ===== 761 {I} {M} 763 Physical 764 Topology | 765 | *-*-* - potential server-layer 766 | WDM service 767 |___________________________________ 769 /-\ /-\ 770 ( G ) ( K ) 771 -\-/- -\-/- 772 */ \* */ \* 773 -/ \- -/ \- 774 */ \* */ \* 775 +---+ /-\ /-\ /-\ /-\ +---+ 776 | A |-----( F ) ( H )-----( J ) ( L )-----| B | 777 +---+ \-/ \-/ \-/ \-/ +---+ 778 \ / \ / 779 \ / \ / 780 \ / \ / 781 /-\ /-\ 782 ( I ) ( M ) 783 \-/ \-/ 785 Figure 8: Multiple Network Domains ([F,G,H,I] belong to Server 786 Network Domain 1;[J,K,L,M] belong to Server Network domain 2) 788 5. Path computation aspects 790 It is assumed that a client domain path computation function makes 791 use of advertised access TE links as well as Virtual TE Links, while 792 computing end-to-end paths for client LSPs. The said path 793 computation function could be local (i.e. located on client LSP 794 ingress nodes, as stipulated by [RFC4655] Composite PCE node) or 795 remote (i.e. on network PCEs). Path computations could be triggered 796 by client nodes or NMS. Generally speaking, the responsibility of 797 the client domain path computation function is to (concurrently) 798 compute one or several paths for each source-destination pair 799 (potential client LSP termination points) specified in a single path 800 computation request. The path computation SHOULD be subject to one 801 or more path optimization criterions (such as minimal cost, minimal 802 latency, etc.) and a set of path computation constraints (such as 803 link unreserved bandwidth, link colors, layer-specific constraints, 804 explicit inclusions and exclusions, etc.) 806 As the overlay topology hides actual server domain/layer links and 807 nodes, it is RECOMMENDED to support SRLG diverse computation of two 808 or more paths. 810 Furthermore, the path computation SHOULD consider the 811 connectivity/switching limitation constraint (when available) in 812 addition to all other path computation constraints. 814 The use of the PCE architecture and PCEP protocol is governed by 815 [RFC5440], [RFC5521] and [RFC5541]. 817 As described in section 3.3., two or more Virtual TE Links may not 818 only share risk, but also may exclusively depend on the same server 819 layer resources. Therefore, paths, computed on network topologies 820 containing Virtual TE Links, have an increased probability of LSP 821 setup failures (two LSPs, for example, could be routed over two 822 Virtual TE Links that exclusively depend on the same server layer 823 resource). In such cases concurrent path computation, taking in 824 consideration MELG information, will address this problem. PCEP 825 supports concurrent path computation per [RFC5440]. Specifying MELG 826 diversity constraint in path computation requests is out of scope of 827 this document. 829 In addition MELG may carry information on the establishment of 830 server-layer resources. A Path computation request MAY constraint 831 the path computation to TE-Links that are fully provisioned only. 832 This information MAY also be used in PCE path computation policies. 834 6. Access and Virtual TE link addressing 836 [RFC4208] implies that access TE links could be named from the same 837 address space as network domain TE links or from a separate address 838 space. This memo requires the following: 840 - It MAY be possible to assign addresses for access TE links from 841 the same address space as the one used for naming network internal 842 TE links (i.e. TE links interconnecting network domain devices); 843 - It MUST be possible to assign addresses for access TE links from a 844 separate address space, independent from the space used for 845 addressing network internal TE links; 846 - Virtual TE Links MUST share the address space with any access TE 847 links they are allowed to be cross-connected within a client LSP. 849 7. Use cases 851 7.1. Service Optimization and Restoration in Multi-layer networks 853 Multi-layer networks are a reality today, and they are operated by 854 different groups of people, following different operational 855 procedures. This requires an independent optimization of the client 856 and server layer networks. Such independence may cause a situation, 857 where the re-routing of a client layer LSP fails, because some of 858 resources on the selected alternate path share fate with some of 859 resources on the LSP's failed path. This usually happens due to 860 lack of knowledge of the server layer network by a client layer path 861 computation function at the time when the alternative path is 862 selected. 864 The high volume and importance of IP traffic in provider networks 865 today requires the client and server layer networks to share 866 sufficient information in order to enable an optimized transport for 867 IP/MPLS services and address existing inefficiencies. From the 868 carrier perspective it is very important that the SRLG information 869 is provided by the server layer TE application and is used by the 870 client layer path computation. 872 In a typical multi-layer network, where IP/MPLS is the client layer 873 network and WDM/OTN is the server layer network, the client layer 874 network is responsible for the protection of the IP/MPLS traffic 875 from networks failures. This is normally achieved via using 876 protection schemes, such as FRR and/or LFA. Regardless of the used 877 mechanism, the SRLG information, provided by the server layer 878 network, helps to optimize the client layer network with respect to 879 reduced link utilization and reliable and efficient protection of 880 the user traffic. 882 Today the SRLGs information is used mainly when calculating diverse 883 alternative paths for the IP/MPLS LSPs. Therefore, the following 884 procedures are performed periodically: 886 - Building traffic matrix for the server layer network 887 (based on IP links) 888 - Solving traffic engineering problems in the server layer network 889 - (Re-)Calculating SRLGs to be propagated into the client layer 890 network 891 - Simulating failure scenarios 892 - Making sure that the affected IP/MPLS LSPs function properly after 893 they are replaced onto SRLG diverse alternative paths 895 GMPLS ENNI reduces the OPEX costs of performing these procedures via 896 the automation as follows: 898 - server layer network automatically discovers and advertises the 899 SRLG information into client layer network via a common routing 900 protocol; 902 - client layer network path computer uses the SRLG information when 903 selecting diverse paths. 905 7.2. IP/MPLS Offloading with ENNI automation 907 A typical application in multi-layer (IP/MPLS over optical) networks 908 is termed 'IP Offloading', in which the network responds to the 909 increase in traffic of a particular service or across a segment in 910 the IP network by dynamically creating additional IP/MPLS links 911 served by GMPLS LSPs provisioned in the server layer network, and 912 placing the extra IP/MPLS traffic onto said links. Likewise, when 913 the IP/MPLS traffic decreases to a normal pattern, the said GMPLS 914 LSPs are torn down, and the extra IP/MPLS links are removed from the 915 client layer network TE domain. The increase in traffic is typically 916 caused by an elevated number of high traffic flows/services 917 traversing an IP network segment. 919 The decision process driving IP offloading is complex, and is 920 governed by a set of rules. These rules reduce the cost of running 921 the multi-layer network, while ensuring that it remains stable. 923 Automation of IP Offloading poses a number of challenges. It 924 includes dynamic provisioning, release and maintenance of GMPLS LSPs 925 in the server layer (e.g. WDM) network as well as automatic 926 advertising/withdrawing them as (numbered or/and unnumbered) TE 927 links into/from the client layer network. In order to pre-plan and 928 manage properly the said dynamic IP/MPLS TE links, it is important 929 to know in advance (and also in real time) the capabilities and 930 resource availability of server layer network. The network 931 domain/layer virtualization procedures described in this document 932 helps to solve this complex operational issue. 934 7.3. Use of PCE and VNTM in Multi-layer Network Operation 936 Two key elements have been proposed to help in the management and 937 coordination of multi-layer networks: the Path Computation Element 938 (PCE) and the Virtual Network Topology Manager (VNTM). PCE is 939 responsible for the calculation of paths between endpoints, 940 particularly in complex scenarios involving, for example, WDM layer 941 physical impairments. VNTM is in charge of maintaining the topology 942 of the client layer network by instantiating virtual links, in the 943 server layer network. I.e., it can be used to provide TE links to 944 the client layer network dynamically. 946 Several cooperation modes between PCE, VNTM and the NMS have been 947 proposed in [RFC5623]. For instance, the operator can request a new 948 MPLS tunnel via the NMS, which communicates with a PCE with 949 information of the multi-layer network. The PCE, in case there are 950 enough resources in the IP/MPLS layer, normally returns a path for 951 the tunnel made of real TE links. On the other hand, if there is a 952 lack of resources in the IP/MPLS layer, the response may contain a 953 path with one or more Virtual TE Links. In this case, the NMS can 954 cooperate with the VNTM to suggest the set-up of a GMPLS LSP(s) in 955 the server layer network. The VNTM, based on the local policies, can 956 accept the suggestion and cause the set-up of the GMPLS LSPs in the 957 server layer network. 959 In order for the computation to be effective, the PCE needs 960 knowledge of the overlay topology (SRLGs, MELGs, TE metrics of the 961 Virtual TE links), which can be provided via GMPLS ENNI. 963 8. Security Considerations 965 TBD 967 9. IANA Considerations 969 TBD. 971 10. References 973 10.1. Normative References 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, March 1997. 978 [RFC4202] K. Kompella, Y.Rekhter 979 "Routing Extensions in Support of Generalized 980 Multi-Protocol Label Switching (GMPLS)", 981 RFC 4202, October 2005. 983 [RFC4208] G. Swallow, J.Drake, H. Ishimatsu, and Y. Rekhter, 984 "GMPLS UNI: RSVP-TE Support for the Overlay Model", 985 RFC 4208, October 2005. 987 [GEN_CNSTR] G.Bernstein, Y.Lee, D.Li, W.Imajuku, "General 988 Network Element Constraint Encoding for GMPLS 989 Controlled Networks" 990 [draft-general-constraint-encode-10.txt] 992 [OSPF_GEN_CNSTR] F.Zhang, J.Han, Y.Lee, D.Li, G.Bernstein, Y.Hu 993 "OSPF-TE Extensions for General Network Element 994 Constraints" 995 [draft-general-constraints-ospf-te-04.txt] 997 [MELG] V.Beeram, I.Bryskin, et al, "Mutually Exclusive 998 Link Groups", [draft-beeram-ccamp-melg-01.txt] 1000 [TE INFO XCHG] A.Farrel, N.Bitar, G.Swallow, D.Ceccarelli, 1001 "Problem Statement and Architecture for Information 1002 Exchange Between Interconnected Traffic Engineered 1003 Networks", [draft-farrel-interconnected-te-info- 1004 exchange-01.txt] 1006 10.2. Informative References 1008 [RFC4847] T. Takeda, "Framework and Requirements for Layer 1 1009 VPNs", RFC 4847, April 2007. 1011 [RFC4655] A. Farrel, J.-P. Vasseur, J. Ash, "A Path 1012 Computation Element (PCE)-Based Architecture", RFC 1013 4655, August 2006. 1015 11. Acknowledgments 1017 Chris Bowers [cbowers@juniper.net] 1019 Authors' Addresses 1020 Igor Bryskin 1021 ADVA Optical Networking 1023 Email: ibryskin@advaoptical.com 1025 Wes Doonan 1026 ADVA Optical Networking 1028 Email: wdoonan@advaoptical.com 1030 Vishnu Pavan Beeram 1031 Juniper Networks 1033 Email:vbeeram@juniper.net 1035 John Drake 1036 Juniper Networks 1038 Email: jdrake@juniper.net 1040 Gert Grammel 1041 Juniper Networks 1043 Email: ggrammel@juniper.net 1045 Manuel Paul 1046 Deutsche Telekom 1048 Email: Manuel.Paul@telekom.de 1049 Ruediger Kunze 1050 Deutsche Telekom 1052 Email: Ruediger.Kunze@telekom.de 1054 Oscar Gonzalez de Dios 1055 Telefonica 1057 Email: ogondio@tid.es 1059 Cyril Margaria 1060 Coriant GmbH 1062 Email: cyril.margaria@coriant.com 1064 Friedrich Armbruster 1065 Coriant GmbH 1067 Email: friedrich.armbruster@coriant.com 1069 Daniele Ceccarelli 1070 Ericsson 1072 Email: daniele.ceccarelli@ericsson.com