idnits 2.17.1 draft-ietf-pce-inter-layer-frwk-06.txt: -(1375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1453. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1140: '...ter-layer policy SHOULD include the de...' RFC 2119 keyword, line 1144: '...er-layer policy is defined, it MUST be...' RFC 2119 keyword, line 1145: '...ughout the network, and SHOULD be made...' RFC 2119 keyword, line 1162: '... support inter-layer computations MUST...' RFC 2119 keyword, line 1167: '... MAY be provided in the same MIB m...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1061 has weird spacing: '...shed if there...' == Line 1067 has weird spacing: '... other lower...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2008) is 5936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Oki 2 Internet Draft NTT 3 Category: Informational J-L Le Roux 4 Expires: June 2008 France Telecom 5 A. Farrel 6 Old Dog Consulting 7 January 2008 9 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic 10 Engineering 12 draft-ietf-pce-inter-layer-frwk-06.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 A network may comprise multiple layers. It is important to 41 globally optimize network resource utilization, taking into 42 account all layers, rather than optimizing resource utilization at 43 each layer independently. This allows better network efficiency to 44 be achieved through a process that we call inter-layer traffic 45 engineering. The Path Computation Element (PCE) can be a powerful 46 tool to achieve inter-layer traffic engineering. 48 This document describes a framework for applying the PCE-based 49 architecture to inter-layer Multiprotocol Label Switching (MPLS) 50 and Generalized MPLS (GMPLS) traffic engineering. It provides 51 suggestions for the deployment of PCE in support of multi-layer 52 networks. This document also describes network models where PCE 53 performs inter-layer traffic engineering, and the relationship 54 between PCE and a functional component called the Virtual Network 55 Topology Manager (VNTM). 57 Table of Contents 59 1. Introduction....................................................3 60 1.1. Terminology..................................................4 61 2. Inter-Layer Path Computation....................................4 62 3. Inter-layer Path Computation Models.............................6 63 3.1. Single PCE Inter-Layer Path Computation......................6 64 3.2. Multiple PCE Inter-Layer Path Computation....................7 65 3.3. General Observations.........................................9 66 4. Inter-Layer Path Control........................................9 67 4.1. VNT Management...............................................9 68 4.2. Inter-Layer Path Control Models..............................9 69 4.2.1. PCE-VNTM Cooperation Model................................10 70 4.2.2. Higher-Layer Signaling Trigger Model......................12 71 4.2.3. NMS-VNTM Cooperation Model................................15 72 4.2.4. Possible Combinations of Inter-Layer Path Computation and 73 Inter-Layer Path Control Models....................................17 74 5. Choosing Between Inter-Layer Path Control Models...............18 75 5.1. VNTM Functions:.............................................18 76 5.2. Border LSR Functions:.......................................19 77 5.3. Complete Inter-Layer LSP Setup Time:........................20 78 5.4. Network Complexity..........................................20 79 5.5. Separation of Layer Management..............................21 80 6. Stability Considerations.......................................21 81 7. Manageability Considerations...................................22 82 7.1. Control of Function and Policy..............................23 83 7.1.1. Control of Inter-Layer Computation Function...............23 84 7.1.2. Control of Per-Layer Policy...............................23 85 7.1.3. Control of Inter-Layer Policy.............................23 86 7.2. Information and Data Models.................................24 87 7.3. Liveness Detection and Monitoring...........................24 88 7.4. Verifying Correct Operation.................................25 89 7.5. Requirements on Other Protocols and Functional Components...25 90 7.6. Impact on Network Operation.................................26 91 8. Security Considerations........................................26 93 Oki et al Expires June 2008 2 95 9. Acknowledgments................................................27 96 10. References...................................................27 97 10.1. Normative Reference.........................................27 98 10.2. Informative Reference.......................................28 99 11. Authors' Addresses...........................................29 100 12. Intellectual Property Statement..............................29 102 1. Introduction 104 A network may comprise multiple layers. These layers may represent 105 separations of technologies (e.g., packet switch capable (PSC), 106 time division multiplex (TDM), or lambda switch capable (LSC)) 107 [RFC3945], separation of data plane switching granularity levels 108 (e.g., PSC-1, PSC-2, VC4, or VC12) [MLN-REQ], or a distinction 109 between client and server networking roles. In this multi-layer 110 network, Label Switched Paths (LSPs) in a lower layer are used to 111 carry higher-layer LSPs across the lower-layer network. The 112 network topology formed by lower-layer LSPs and advertised as 113 traffic engineering links (TE links) to the higher layer is called 114 the Virtual Network Topology (VNT) [MLN-REQ]. 116 It may be effective to optimize network resource utilization 117 globally, i.e., taking into account all layers, rather than 118 optimizing resource utilization at each layer independently. This 119 allows better network efficiency to be achieved and is what we 120 call inter-layer traffic engineering. This includes mechanisms 121 allowing the computation of end-to-end paths across layers (known 122 as inter-layer path computation), and mechanisms for control and 123 management of the Virtual Network Topology (VNT) by setting up and 124 releasing LSPs in the lower layers [MLN-REQ]. 126 Inter-layer traffic engineering is included in the scope of the 127 Path Computation Element (PCE)-based architecture [RFC4655], and 128 PCE can provide a suitable mechanism for resolving inter-layer 129 path computation issues. 131 PCE Communication Protocol requirements for inter-layer traffic 132 engineering are set out in [PCE-INTER-LAYER-REQ]. 134 This document describes a framework for applying the PCE-based 135 architecture to inter-layer traffic engineering. It provides 136 suggestions for the deployment of PCE in support of multi-layer 137 networks. This document also describes network models where PCE 138 performs inter-layer traffic engineering, and the relationship 139 between PCE and a functional component in charge of the control 140 and management of the VNT, called the Virtual Network Topology 141 Manager (VNTM). 143 Oki et al Expires June 2008 3 145 1.1. Terminology 147 This document uses terminology from the PCE-based path computation 148 architecture [RFC4655] and also common terminology from Multi 149 Protocol Label Switching (MPLS) [RFC3031], Generalized MPLS 150 (GMPLS) [RFC3945] and Multi-Layer Networks [MLN-REQ]. 152 2. Inter-Layer Path Computation 154 This section describes key topics of inter-layer path computation 155 in MPLS and GMPLS networks. 157 [RFC4206] defines a way to signal a higher-layer LSP, which has an 158 explicit route that includes hops traversed by LSPs in lower 159 layers. The computation of end-to-end paths across layers is 160 called Inter-Layer Path Computation. 162 A Label Switching Router (LSR) in the higher-layer might not have 163 information on the topology of the lower-layer, particularly in an 164 overlay or augmented model deployment, and hence may not be able 165 to compute an end-to-end path across layers. 167 PCE-based Inter-Layer Path Computation, consists of using one or 168 more PCEs to compute an end-to-end path across layers. This could 169 be achieved by a single PCE path computation where the PCE has 170 topology information about multiple layers and can directly 171 compute an end-to-end path across layers considering the topology 172 of all of the layers. Alternatively, the inter-layer path 173 computation could be performed as a multiple-PCE computation where 174 each member of a set of PCEs has information about the topology of 175 one or more layers (but not all layers), and the PCEs collaborate 176 to compute an end-to-end path. 178 ----- ----- ----- ----- 179 | LSR |--| LSR |................| LSR |--| LSR | 180 | H1 | | H2 | | H3 | | H4 | 181 ----- -----\ /----- ----- 182 \----- -----/ 183 | LSR |--| LSR | 184 | L1 | | L2 | 185 ----- ----- 187 Figure 1: A Simple Example of a Multi-Layer Network. 189 Consider, for instance, the two-layer network shown in Figure 1, 190 where the higher-layer network is a packet-based IP/MPLS or GMPLS 191 network (LSRs H1, H2, H3, and H4), and the lower-layer network 192 (LSRs, H2, L1, L2, and H3) is a GMPLS optical network. An ingress 193 LSR in the higher-layer network (H1) tries to set up an LSP to an 195 Oki et al Expires June 2008 4 196 egress LSR (H4) also in the higher-layer network across the 197 lower-layer network, and needs a path in the higher-layer network. 198 However, suppose that there is no TE link in the higher-layer 199 network between the border LSRs located on the boundary between 200 the higher-layer and lower-layer networks (H2 and H3). Suppose 201 also that the ingress LSR does not have topology visibility into 202 the lower layer. If a single-layer path computation is applied for 203 the higher-layer, the path computation fails because of the 204 missing TE link. On the other hand, inter-layer path computation 205 is able to provide a route in the higher-layer (H1-H2-H3-H4) and a 206 suggestion that a lower-layer LSP be set up between the border 207 LSRs (H2-L1-L2-H3). 209 Lower-layer LSPs that are advertised as TE links into the higher- 210 layer network form a Virtual Network Topology (VNT) that can be 211 used for routing higher-layer LSPs. Inter-layer path computation 212 for end-to-end LSPs in the higher-layer network that span the 213 lower-layer network may utilize the VNT, and PCE is a candidate 214 for computing the paths of such higher-layer LSPs within the 215 higher-layer network. Alternatively, the PCE-based path 216 computation model can: 218 - Perform a single computation on behalf of the ingress LSR using 219 information gathered from more than one layer. This mode is 220 referred to as Single PCE Computation in [RFC4655]. 222 - Compute a path on behalf of the ingress LSR through cooperation 223 with PCEs responsible for each layer. This mode is referred to as 224 Multiple PCE Computation with inter-PCE communication in [RFC4655]. 226 - Perform separate path computations on behalf of the TE-LSP head- 227 end and each transit border LSR that is the entry point to a new 228 layer. This mode is referred to as Multiple PCE Computation 229 (without inter-PCE communication) in [RFC4655]. This option 230 utilizes per-layer path computation performed independently by 231 successive PCEs. 233 The PCE invoked by the head-end LSR computes a path that the LSR 234 can use to signal an MPLS-TE or GMPLS LSP once the path 235 information has been converted to an Explicit Route Object (ERO) 236 for use in RSVP-TE signaling. There are two options. 238 - Option 1: Mono-layer path. 239 The PCE computes a "mono-layer" path, i.e., a path that includes 240 only TE links from the same layer. There are two cases for this 241 option. In the first case the PCE computes a path that includes 242 already established lower-layer LSPs or lower-layer LSPs to be 243 established on demand. That is, the resulting ERO includes sub- 244 object(s) corresponding to lower-layer hierarchical LSPs expressed 246 Oki et al Expires June 2008 5 247 as the TE link identifiers of the hierarchical LSPs when 248 advertised as TE links in the higher-layer network. The TE link 249 may be a regular TE link that is actually established, or a 250 virtual TE link that is not established yet (see [MLN-REQ]). If it 251 is a virtual TE link, this triggers a setup attempt for a new 252 lower-layer LSP when signaling reaches the head-end of the lower- 253 layer LSP. Note that the path of a virtual TE link is not 254 necessarily known in advance, and this may require a further 255 (lower-layer) path computation. 257 The second case is that the PCE computes a path that includes a 258 loose hop that spans the lower-layer network. The higher layer 259 path computation selects which lower layer network to use, and 260 selects the entry and exit points from that lower-layer network, 261 but does not select the path across the lower-layer network. A 262 transit LSR that is the entry point to the lower-layer network is 263 expected to expand the loose hop (either itself or relying on the 264 services of a PCE). The path expansion process on the border LSR 265 may result either in the selection of an existing lower-layer LSP, 266 or in the computation and setup of a new lower-layer LSP. 268 - Option 2: Multi-layer path. The PCE computes a "multi-layer" 269 path, i.e., a path that includes TE links from distinct layers 270 [RFC4206]. Such a path can include the complete path of one or 271 more lower-layer LSPs that already exist or are not yet 272 established. In the latter case, the signaling of the higher-layer 273 LSP will trigger the establishment of the lower-layer LSPs. 275 3. Inter-layer Path Computation Models 277 As stated in Section 2, two PCE modes defined in the PCE 278 architecture can be used to perform inter-layer path computation. 279 They are discussed in the sections that follow. 281 3.1. Single PCE Inter-Layer Path Computation 283 In this model Inter-layer path computation is performed by a 284 single PCE that has topology visibility into all layers. Such a 285 PCE is called a multi-layer PCE. 287 In Figure 2, the network is comprised of two layers. LSRs H1, H2, 288 H3, and H4 belong to the higher layer, and LSRs H2, H3, L1, and L2 289 belong to the lower layer. The PCE is a multi-layer PCE that has 290 visibility into both layers. It can perform end-to-end path 291 computation across layers (single PCE path computation). For 292 instance, it can compute an optimal path H1-H2-L1-L2-H3-H4, for a 293 higher layer LSP from H1 to H4. This path includes the path of a 294 lower layer LSP from H2 to H3, already in existence or not yet 295 established. 297 Oki et al Expires June 2008 6 298 ----- 299 | PCE | 300 ----- 301 ----- ----- ----- ----- 302 | LSR |--| LSR |................| LSR |--| LSR | 303 | H1 | | H2 | | H3 | | H4 | 304 ----- -----\ /----- ----- 305 \----- -----/ 306 | LSR |--| LSR | 307 | L1 | | L2 | 308 ----- ----- 310 Figure 2: Single PCE Inter-Layer Path Computation 312 3.2. Multiple PCE Inter-Layer Path Computation 314 In this model there is at least one PCE per layer, and each PCE 315 has topology visibility restricted to its own layer. Some 316 providers may want to keep the layer boundaries due to factors 317 such as organizational and/or service management issues. The 318 choice for multiple PCE computation instead of single PCE 319 computation may also be driven by scalability considerations, as 320 in this mode a PCE only needs to maintain topology information for 321 one layer (resulting in a size reduction for the Traffic 322 Engineering Database (TED)). 324 These PCEs are called mono-layer PCEs. Mono-layer PCEs collaborate 325 to compute an end-to-end optimal path across layers. 327 Figure 3 shows multiple PCE inter-layer computation with inter-PCE 328 communication. There is one PCE in each layer. The PCEs from each 329 layer collaborate to compute an end-to-end path across layers. PCE 330 Hi is responsible for computations in the higher layer and may 331 "consult" with PCE Lo to compute paths across the lower layer. PCE 332 Lo is responsible for path computation in the lower layer. A 333 simple example of cooperation between the PCEs could be as 334 follows: 335 - LSR H1 sends a request for a path H1-H4 to PCE Hi 336 - PCE Hi selects H2 as the entry point to the lower layer, and H3 337 as the exit point. 338 - PCE Hi requests a path H2-H3 from PCE Lo. 339 - PCE Lo returns H2-L1-L2-H3 to PCE Hi. 340 - PEC Hi is now able to compute the full path (H1-H2-L1-L2-H3-H4) 341 and return it to H1. 343 Of course more complex cooperation may be required if an optimal 344 end-to-end path is desired. 346 Oki et al Expires June 2008 7 347 ----- 348 | PCE | 349 | Hi | 350 --+-- 351 | 352 ----- ----- | ----- ----- 353 | LSR |--| LSR |............|...........| LSR |--| LSR | 354 | H1 | | H2 | | | H3 | | H4 | 355 ----- -----\ --+-- /----- ----- 356 \ | PCE | / 357 \ | Lo | / 358 \ ----- / 359 \ / 360 \----- -----/ 361 | LSR |--| LSR | 362 | L1 | | L2 | 363 ----- ----- 365 Figure 3: Multiple PCE Inter-Layer Path Computation with Inter-PCE 366 Communication 368 Figure 4 shows multiple PCE inter-layer path computation without 369 inter-PCE communication. As described in Section 2, separate path 370 computations are performed on behalf of the TE-LSP head-end and 371 each transit border LSR that is the entry point to a new layer. 373 ----- 374 | PCE | 375 | Hi | 376 ----- 378 ----- ----- ----- ----- 379 | LSR |--| LSR |........................| LSR |--| LSR | 380 | H1 | | H2 | | H3 | | H4 | 381 ----- -----\ ----- /----- ----- 382 \ | PCE | / 383 \ | Lo | / 384 \ ----- / 385 \ / 386 \----- -----/ 387 | LSR |--| LSR | 388 | L1 | | L2 | 389 ----- ----- 391 Figure 4: Multiple PCE Inter-layer Path Computation without Inter- 392 PCE Communication 394 Oki et al Expires June 2008 8 396 3.3. General Observations 398 - Depending on implementation details, the time to perform inter- 399 layer path computation in the Single PCE inter-layer path 400 computation model may be less than that of the Multiple PCE model 401 with cooperating mono-layer PCEs, because there is no requirement 402 to exchange messages between cooperating PCEs. 404 - When TE topology for all layer networks is visible within one 405 routing domain, the single PCE inter-layer path computation model 406 may be adopted because a PCE is able to collect all layers' TE 407 topologies by participating in only one routing domain. 409 - As the single PCE inter-layer path computation model uses more 410 TE topology information in one computation than is used by PCEs in 411 the Multiple PCE path computation model, it requires more 412 computation power and memory. 414 When there are multiple candidate layer border nodes (we may say 415 that the higher layer is multi-homed), optimal path computation 416 requires that all the possible paths transiting different layer 417 border nodes or links be examined. This is relatively simple in 418 the single PCE inter-layer path computation model because the PCE 419 has full visibility - 420 - the computation is similar to the 421 computation within a single domain of a single layer. In the 422 multiple PCE inter-layer path computation model, backward 423 recursive techniques described in [BRPC] could be used, by 424 considering layers as separate domains. 426 4. Inter-Layer Path Control 428 4.1. VNT Management 430 As a result of inter-layer path computation, a PCE may determine 431 that there is insufficient bandwidth available in the higher-layer 432 network to support this or future higher-layer LSPs. The problem 433 might be resolved if new LSPs were provisioned across the lower- 434 layer network. Furthermore, the modification, re-organization and 435 new provisioning of lower-layer LSPs may enable better utilization 436 of lower-layer network resources given the demands of the higher- 437 layer network. In other words, the VNT needs to be controlled or 438 managed in cooperation with inter-layer path computation. 440 A VNT Manager (VNTM) is defined as a functional element that 441 manages and controls the VNT. PCE and VNT Manager are distinct 442 functional elements that may or may not be co-located. 444 4.2. Inter-Layer Path Control Models 446 Oki et al Expires June 2008 9 448 4.2.1. 449 PCE-VNTM Cooperation Model 451 ----- ------ 452 | PCE |--->| VNTM | 453 ----- ------ 454 ^ : 455 : : 456 : : 457 v V 458 ----- ----- ----- ----- 459 | LSR |----| LSR |................| LSR |----| LSR | 460 | H1 | | H2 | | H3 | | H4 | 461 ----- -----\ /----- ----- 462 \----- -----/ 463 | LSR |--| LSR | 464 | L1 | | L2 | 465 ----- ----- 467 Figure 5: PCE-VNTM Cooperation Model 469 A multi-layer network consists of higher-layer and lower-layer 470 networks. LSRs H1, H2, H3, and H4 belong to the higher-layer 471 network, LSRs H2, L1, L2, and H3 belong to the lower-layer network, 472 as shown in Figure 5. The case of single PCE inter-layer path 473 computation is considered here to explain the cooperation model 474 between PCE and VNTM, but multiple PCE path computation with or 475 without inter-PCE communication can also be applied to this model. 477 Consider that H1 requests the PCE to compute an inter-layer path 478 between H1 and H4. There is no TE link in the higher-layer between 479 H2 and H3 before the path computation request, so the request 480 fails. But the PCE may provide information to the VNT Manager 481 responsible for the lower layer network that may help resolve the 482 situation for future higher-layer LSP setup. 484 The roles of PCE and VNTM are as follows. PCE performs inter-layer 485 path computation and is unable to supply a path because there is 486 no TE link between H2 and H3. The computation fails, but PCE 487 suggests to VNTM that a lower-layer LSP (H2-H3) could be 488 established to support future LSP requests. Messages from PCE to 489 VNTM contain information about the higher-layer demand (from H2 to 490 H3), and may include a suggested path in the lower layer (if the 491 PCE has visibility into the lower layer network). VNTM uses local 492 policy and possibly management/configuration input to determine 493 how to process the suggestion from PCE, and may request an ingress 494 LSR (e.g. H2) to establish a lower-layer LSP. VNTM or the ingress 495 LSR (H2) may themselves use a PCE with visibility into the lower 496 layer to compute the path of this new LSP. 498 Oki et al Expires June 2008 10 499 When the higher-layer PCE fails to compute a path and notifies 500 VNTM, it may wait for the lower-layer LSP to be set up and 501 advertised as a TE link. PCE may have a timer. After TED is 502 updated within a specified duration, PCE will know a new TE link. 503 It could then compute the complete end-to-end path for the higher- 504 layer LSP and return the result to the PCC. In this case, the PCC 505 may be kept waiting for some time, and it is important that the 506 PCC understands this. It is also important that the PCE and VNTM 507 have an agreement that the lower-layer LSP will be set up in a 508 timely manner, or that the PCE will be notified by VNTM that no 509 new LSP will become available. In any case, if the PCE decides to 510 wait, it must operates a timeout. An example of such a cooperative 511 procedure between PCE and VNTM is as follows using the example 512 network in Figure 4. 514 Step 1: H1 (PCC) requests PCE to compute a path between H1 and H4. 516 Step 2: The path computation fails because there is no TE link 517 across the lower-layer network. 519 Step 3: PCE suggests to VNTM that a new TE link connecting H2 and 520 H3 would be useful. The PCE notifies VNTM that it will be waiting 521 for the TE link to be created. VNTM considers whether lower-layer 522 LSPs should be established if necessary and if acceptable within 523 VNTM's policy constraints. 525 Step 4: VNTM requests an ingress LSR in the lower-layer network 526 (e.g., H2) to establish a lower-layer LSP. The request message may 527 include a lower-layer LSP route obtained from the PCE responsible 528 for the lower-layer network. 530 Step 5: The ingress LSR signals to establish the lower-layer LSP. 532 Step 6: If the lower-layer LSP setup is successful, the ingress 533 LSR notifies VNTM that the LSP is complete and supplies the tunnel 534 information. 536 Step 7: The ingress LSR (H2) advertises the new LSP as a TE link 537 in the higher-layer network routing instance. 539 Step 8: PCE notices the new TE link advertisement and recomputes 540 the requested path. 542 Step 9: PCE replies to H1 (PCC) with a computed higher-layer LSP 543 route. The computed path is categorized as a mono-layer path that 544 includes the already-established lower layer-LSP as a single hop 545 in the higher layer. The higher-layer route is specified as H1-H2- 546 H3-H4, where all hops are strict. 548 Oki et al Expires June 2008 11 549 Step 9: H1 initiates signaling with the computed path H2-H3-H4 to 550 establish the higher-layer LSP. 552 4.2.2. 553 Higher-Layer Signaling Trigger Model 555 ----- 556 | PCE | 557 ----- 558 ^ 559 : 560 : 561 v 562 ----- ----- ----- ----- 563 | LSR |----| LSR |................| LSR |--| LSR | 564 | H1 | | H2 | | H3 | | H4 | 565 ----- -----\ /----- ----- 566 \----- -----/ 567 | LSR |--| LSR | 568 | L1 | | L2 | 569 ----- ----- 571 Figure 6: Higher-layer Signaling Trigger Model 573 Figure 6 shows the higher-layer signaling trigger model. The case 574 of single PCE path computation is considered to explain the 575 higher-layer signaling trigger model here, but multiple PCE path 576 computation with/without inter-PCE communication can also be 577 applied to this model. 579 As in the case described in Section 4.2.1, consider that H1 580 requests PCE to compute a path between H1 and H4. There is no TE 581 link in the higher-layer between H2 and H3 before the path 582 computation request. 584 PCE is unable to compute a mono-layer path, but may judge that the 585 establishment of a lower-layer LSP between H2 and H3 would provide 586 adequate connectivity. If the PCE has inter-layer visibility it 587 may return a path that includes hops in the lower layer (H1-H2-L1- 588 L2-H3-H4), but if it has no visiblity into the lower layer, it may 589 return a path with a loose hop from H2 to H3 (H1-H2-H3(loose)-H4). 590 The former is a multi-layer path, and the latter a mono-layer path 591 that includes loose hops. 593 In the higher-layer signaling trigger model with a multi-layer 594 path, the LSP route supplied by the PCE includes the route of a 596 Oki et al Expires June 2008 12 597 lower-layer LSP that is not yet established. A border LSR that is 598 located at the boundary between the higher-layer and lower-layer 599 networks (H2 in this example) receives a higher-layer signaling 600 message, notices that the next hop is in the lower-layer network, 601 starts to setup the lower-layer LSP as described in [RFC4206]. 602 Note that these actions depends on a policy being applied at the 603 border LSR. An example procedure of the signaling trigger model 604 with a multi-layer path is as follows. 606 Step 1: H1 (PCC) requests PCE to compute a path between H1 and H4. 607 The request indicates that inter-layer path computation is allowed. 609 Step 2: As a result of the inter-layer path computation, PCE 610 judges that a new lower-layer LSP needs to be established. 612 Step 3: PCE replies to H1 (PCC) with a computed multi-layer route 613 including higher-layer and lower-layer LSP routes. The route may 614 be specified as H1-H2-L1-L2-H3-H4, where all hops are strict. 616 Step 4: H1 initiates higher-layer signaling using the computed 617 explicit router of H2-L1-L2-H3-H4. 619 Step 5: The border LSR (H2) that receives the higher-layer 620 signaling message starts lower-layer signaling to establish a 621 lower-layer LSP along the specified lower-layer route of H2-L1-L2- 622 H3. That is, the border LSR recognizes the hops within the 623 explicit route that apply to the lower-layer network, verifies 624 with local policy that a new LSP is acceptable, and establishes 625 the required lower-layer LSP. Note that it is possible that a 626 suitable lower-layer LSP has already been established (or become 627 available) between the time that the computation was performed and 628 the moment when the higher-layer signaling message reached the 629 border LSR. In this case, the border LSR may select such a lower- 630 layer LSP without the need to signal a new LSP provided that the 631 lower-layer LSP satisfies the explicit route in the higher-layer 632 signaling request. 634 Step 6: After the lower-layer LSP is established, the higher-layer 635 signaling continues along the specified higher-layer route of H2- 636 H3-H4 using hierarchical signaling [RFC4206]. 638 On the other hand, in the signaling trigger model with a mono- 639 layer path, a higher-layer LSP route includes a loose hop to 640 traverse the lower-layer network between the two border LSRs. A 641 border LSR that receives a higher-layer signaling message needs to 642 determine a path for a new lower-layer LSP. It applies local 643 policy to verify that a new LSP is acceptable and then either 644 consults a PCE with responsibility for the lower-layer network or 645 computes the path by itself, and initiates signaling to establish 647 Oki et al Expires June 2008 13 648 the lower-layer LSP. Again, it is possible that a suitable lower- 649 layer LSP has already been established (or become available). In 650 this case, the border LSR may select such a lower-layer LSP 651 without the need to signal a new LSP provided that the existing 652 lower-layer LSP satisfies the explicit route in the higher-layer 653 signaling request. Since the higher-layer signaling request used a 654 loose hop without specifying any specifics of the path within the 655 lower-layer network, the border LSR has greater freedom to choose 656 a lower-layer LSP than in the previous example. 658 The difference between procedures of the signaling trigger model 659 with a multi-layer path and a mono-layer path is Step 5. Step 5 of 660 the signaling trigger model with a mono layer path is as follows: 662 Step 5': The border LSR (H2) that receives the higher-layer 663 signaling message applies local policy to verify that a new LSP is 664 acceptable and then initiates establishment of a lower-layer LSP. 665 It either consults a PCE with responsibility for the lower-layer 666 network or computes the route by itself to expand the loose hop 667 route in the higher-layer path. 669 Finally, note that a virtual TE link may have been advertised into 670 the higher-layer network. This causes the PCE to return a path H1- 671 H2-H3-H4 where all the hops are strict. But when the higher-layer 672 signaling message reaches the layer border node H2 (that was 673 responsible for advertising the virtual TE link) it realizes that 674 the TE link does not exist yet, and signals the necessary LSP 675 across the lower-layer network using its own path determination 676 (just as for a loose hop in the higher layer) before continuing 677 with the higher-layer signaling. 679 PCE 680 ^ 681 : 682 : 683 V 684 H1--H2 H3--H4 685 \ / 686 L1==L2==L3--L4--L5 687 | 688 | 689 L6--L7 690 \ 691 H5--H6 693 Figure 7: Example of a Multi-Layer Network 695 Examples of multi-layer EROs are explained using Figure 7. It is 696 described how lower-layer LSP setup is performed in the higher- 698 Oki et al Expires June 2008 14 699 layer signaling trigger model using an ERO that can include 700 subobjects in both the higher and lower layers. It gives rise to 701 several options for the ERO when it reaches the last LSR in the 702 higher layer network (H2). 703 1. The next subobject is a loose hop to H3 (mono layer ERO). 704 2. The next subobject is a strict hop to L1 followed by a loose 705 hop to H3. 706 3. The next subobjects are a series of hops (strict or loose) in 707 the lower-layer network followed by H3. For example, {L1(strict), 708 L3(loose), L5(loose), H3(strict)} 710 In the first example, the lower layer can utilize any LSP tunnel 711 that will deliver the end-to-end LSP to H3. In the third case, the 712 lower layer must select an LSP tunnel that traverses L3 and L5. 713 However, this does not mean that the lower layer can or should use 714 an LSP from L1 to L3 and another from L3 to L5. 716 4.2.3. 717 NMS-VNTM Cooperation Model 719 ----- 720 | NMS | 721 | | ----- 722 ----- | PCE | 723 ^ ^ | Hi | 724 : : ----- 725 : : ^ 726 : : : 727 : : : 728 : v v 729 : ------ ----- ----- ------ 730 : | LSR |--| LSR |........................| LSR |--| LSR | 731 : | H1 | | H2 | | H3 | | H4 | 732 : ------ -----\ /----- ------ 733 : ^ \ / 734 : : \ / 735 : -------- \ / 736 v : \ / 737 ------ ----- \----- -----/ 738 | VNTM |<-->| PCE | | LSR |--| LSR | 739 | | | Lo | | L1 | | L2 | 740 ------ ----- ----- ----- 742 Figure 8: NMS-VNTM Cooperation Model 744 Figure 8 show the Network Management System (NMS)-VNTM cooperation 745 model. The NMS manages the upper layer. The case of multiple PCE 746 computation without inter-PCE communication is used to explain the 748 Oki et al Expires June 2008 15 749 NMS-VNTM cooperation model here, but single PCE path computation 750 could also be applied to this model. Note that multiple PCE path 751 computation with inter-PCE communication does not fit in with this 752 model. 754 The NMS requests a head-end LSR (H1 in this example) to set up a 755 higher-layer LSP between head-end and tail-end LSRs without 756 specifying any route. The head-end LSR, which is a PCC, requests 757 the higher-layer PCE to compute a path between head-end and tail- 758 end LSRs. There is no TE link in the higher-layer between border 759 LSRs (H2 and H3 in this example). When the PCE fails to compute a 760 path, it informs the PCC (i.e. head-end LSR) that notifies the NMS. 761 The notification may include the information that there is no TE 762 link between the border LSRs. 764 Note that it is equally valid for the higher-layer PCE to be 765 consulted by the NMS rather than by the head-end LSR. In this case, 766 the result is the same - 767 - the NMS discovers that an end-to-end LSP 768 cannot be provisioned owing to the lack of a TE link between H2 769 and H3. 771 The NMS may now suggest (or request) to the VNTM that a lower- 772 layer LSP between the border LSRs could be established and could 773 be advertised as a TE link in the higher layer to support future 774 higher-layer LSP requests. The communication between the NMS and 775 the VNTM may be performed in an automatic manner or in a manual 776 manner, and is a key interaction between layers that may also be 777 separate administrative domains. Thus, this communication is 778 potentially a point of application of administrative, billing, and 779 security policy. The NMS may wait for the lower-layer LSP to be 780 set up and advertised as a TE link, or may reject the operator's 781 request for the service that requires the higher-layer LSP with a 782 suggestion that the operator tries again later. 784 The VNTM requests the lower-layer PCE to compute a path, and then 785 requests H2 to establish a lower-layer LSP. Alternatively, the 786 VNTM may make a direct request to H2 for the LSP, and H2 may 787 consult the lower-layer PCE. After the NMS is informed or notices 788 that the lower-layer LSP has been established, it can request the 789 head-end LSR (H1) to set up the higher-layer end-to-end LSP 790 between H1 and H4. 792 Thus, cooperation between the high layer and lower layer is 793 performed though communication between NMS and VNTM. An example of 794 such a procedure of the NSM-VNTM cooperation model is as follows 795 using the example network in Figure 6. 797 Step 1: NMS requests a head-end LSR (H1) to set up a higher-layer 798 LSP between H1 and H4 without specifying any route. 800 Oki et al Expires June 2008 16 801 Step 2: H1 (PCC) requests PCE to compute a path between H2 and H3. 803 Step 3: The path computation fails because there is no TE link 804 across the lower-layer network. 806 Step 4: H1 (PCC) notifies NMS. The notification may include an 807 indication that there is no TE link between H2 and H4. 809 Step 5: NMS suggests (or requests) to VNTM that a new TE link 810 connecting H2 and H3 would be useful. The NMS notifies VNTM that 811 it will be waiting for the TE link to be created. VNTM considers 812 whether lower-layer LSPs should be established if necessary and if 813 acceptable within VNTM's policy constraints. 815 Step 6: VNTM requests the lower-layer PCE for path computation. 817 Step 7: VNTM requests the ingress LSR in the lower-layer network 818 (H2) to establish a lower-layer LSP. The request message includes 819 a lower-layer LSP route obtained from the lower-layer PCE 820 responsible for the lower-layer network. 822 Step 5: H2 signals the lower-layer LSP. 824 Step 6: If the lower-layer LSP setup is successful, H2 notifies 825 VNTM that the LSP is complete and supplies the tunnel information. 827 Step 7: H2 advertises the new LSP as a TE link in the higher-layer 828 network routing instance. 830 Step 8: VNTM notifies NMS that the underlying lower-layer LSP has 831 been set up, and NMS notices the new TE link advertisement. 833 Step 9: NMS again requests H1 to set up a higher-layer LSP between 834 H1 and H4. 836 Step 10: H1 requests the higher-layer PCE to compute a path and 837 obtains a successful result that includes the higher-layer route 838 that is specified as H1-H2-H3-H4, where all hops are strict. 840 Step 11: H1 initiates signaling with the computed path H2-H3-H4 to 841 establish the higher-layer LSP. 843 4.2.4. 844 Possible Combinations of Inter-Layer Path Computation and 845 Inter-Layer Path Control Models 847 Table 1 summarizes the possible combinations of inter-layer path 848 computation and inter-layer path control models. There are three 850 Oki et al Expires June 2008 17 851 inter-layer path computation models: the single PCE path 852 computation model; the multiple PCE path computation with inter- 853 PCE communication model; and the multiple PCE path computation 854 without inter-PCE communication model. There are also three inter- 855 layer path control models: the PCE-VNTM cooperation model; the 856 higher-layer signaling trigger model; and the NMS-VNTM cooperation 857 model. All the combinations between inter-layer path computation 858 and path control models, except for the combination of the 859 multiple PCE path computation with inter-layer PCE communication 860 model and the NMS-VNTM cooperation model are possible. 862 Table 1: Possible Combinations of Inter-Layer Path Computation and 863 Inter-Layer Path Control Models. 865 ---------------------------------------------------- 866 | Path computation | Single | Multiple | Multiple | 867 | \ | PCE | PCE with | PCE w/o | 868 | Path control | | inter-PCE | inter-PCE | 869 |----------------------------------------------------| 870 | PCE-VNTM | Yes | Yes | Yes | 871 | cooperation | | | | 872 |----------------------------+-----------+-----------| 873 | Higher-layer | Yes | Yes | Yes | 874 | signaling trigger | | | | 875 |----------------------------------------------------| 876 | NMS-VNTM | No* | No | Yes | 877 | cooperation | | | | 878 -------------------+--------+-----------+----------- 880 *Note that, in case of NSM-VNTM cooperation and single PCE inter- 881 layer path computation, the PCE function used by NMS and VNTM may 882 be collocated, but it will operate on separate TEDs. 884 5. Choosing Between Inter-Layer Path Control Models 886 This section compares the cooperation model between PCE and VNTM, 887 and the higher-layer signaling trigger model, in terms of VNTM 888 functions, border LSR functions, higher-layer signaling time, and 889 complexity (in terms of number of states and messages). An 890 appropriate model may be chosen by a network operator in different 891 deployment scenarios taking all these considerations into account. 893 5.1. VNTM Functions: 895 VNTM functions are required in both the PCE-VNTM cooperation model 896 and the NMS-VNTM model. In the PCE-VNTM cooperation model, 897 communications are required between PCE and VNTM, and between VNTM 899 Oki et al Expires June 2008 18 900 and a border LSR. Communications between a higher-layer PCE and 901 the VNTM are event notifications and may use SNMP notifications 902 from the PCE MIB modules [PCE-MIB]. Note that communications from 903 the PCE to the VNTM do not have any acknowledgements. 905 VNTM-LSR communication can use existing GMPLS-TE MIB modules 906 [RFC4802]. In the NMS-VNTM cooperation model, communications are 907 required between NMS and VNTM, between VNTM and a lower-layer PCE, 908 and between VNTM and a border LSR. NMS-VNTM communications, which 909 are out of scope of this document, may use proprietary or standard 910 interfaces, some of which, for example, are standardized in TM 911 Forum. Communications between VNTM and a lower-layer PCE use PCEP 912 [PCEP]. VNTM-LSR communications are the same as in the PCE-VNTM 913 cooperation model. 915 In the higher-layer signaling trigger model, no VNTM functions are 916 required, and no such communications are required. 918 If VNTM functions are not supported in a multi-layer network, the 919 higher-layer signaling trigger model has to be chosen. 921 The inclusion of VNTM functionality allows better coordination of 922 cross-network LSP tunnels and application of network-wide policy 923 that is far harder to apply in the trigger model since it requires 924 the coordination of policy between multiple border LSRs. 926 5.2. Border LSR Functions: 928 In the higher-layer signaling trigger model, a border LSR must 929 have some additional functions. It needs to trigger lower-layer 930 signaling when a higher-layer path message suggests that lower- 931 layer LSP setup is necessary. Note that, if virtual TE links are 932 used, the border LSRs must be capable of triggered signaling. 934 If the ERO in the higher-layer Path message uses a mono-layer path 935 or specifies a loose hop, the border LSR receiving the Path 936 message must obtain a lower-layer route either by consulting a PCE 937 or by using its own computation engine. If the ERO in the higher- 938 layer Path message uses a multi-layer path, the border LSR must 939 judge whether lower-layer signaling is needed. 941 In the PCE-VNTM cooperation model and the NMS-VNTM model, no 942 additional function for triggered signaling is required in border 943 LSRs except when virtual TE links are used. Therefore, if these 944 additional functions are not supported in border LSRs, where a 945 border LSR is controlled by VNTM to set up a lower-layer LSP, the 946 cooperation model has to be chosen. 948 Oki et al Expires June 2008 19 950 5.3. Complete Inter-Layer LSP Setup Time: 952 The complete inter-layer LSP setup time includes inter-layer path 953 computation, signaling, and the communication time between PCC and 954 PCE, PCE and VNTM, NSM and VNTM, and VNTM and LSR. In the PCE-VNTM 955 cooperation model and the NMS-VNTM model, the additional 956 communication steps are required compared with the higher-layer 957 signaling trigger model. On the other hand, the cooperation model 958 provides better control at the cost of a longer service setup time. 960 Note that, in terms of higher-layer signaling time, in the higher- 961 layer signaling trigger model, the required time from when higher- 962 layer signaling starts to when it is completed, is more than that 963 of the cooperation model except when a virtual TE link is included. 964 This is because the former model requires lower-layer signaling to 965 take place during the higher-layer signaling. A higher-layer 966 ingress LSR has to wait for more time until the higher-layer 967 signaling is completed. A higher-layer ingress LSR is required to 968 be tolerant of longer path setup times. 970 5.4. Network Complexity 972 If the higher and lower layer networks have multiple interconnects 973 then optimal path computation for end-to-end LSPs that cross the 974 layer boundaries is non-trivial. The higher layer LSP must be 975 routed to the correct layer border nodes to achieve optimality in 976 both layers. 978 Where the lower layer LSPs are advertised into the higher layer 979 network as TE links, the computation can be resolved in the higher 980 layer network. Care needs to be taken in the allocation of TE 981 metrics (i.e., costs) to the lower layer LSPs as they are 982 advertised as TE links into the higher layer network, and this 983 might be a function for a VNT Manager component. Similarly, 984 attention should be given to the fact that the LSPs crossing the 985 lower-layer network might share points of common failure (e.g., 986 they might traverse the same link in the lower-layer network) and 987 the shared risk link groups (SRLGs) for the TE links advertised in 988 the higher-layer must be set accordingly. 990 In the single PCE model an end-to-end path can be found in a 991 single computation because there is full visibility into both 992 layers and all possible paths through all layer interconnects can 993 be considered. 995 Where PCEs cooperate to determine a path, an iterative computation 996 model such as [BRPC] can be used to select an optimal path across 997 layers. 999 Oki et al Expires June 2008 20 1000 When non-cooperating mono-layer PCEs, each of which is in a 1001 separate layer, are used with the triggered LSP model, it is not 1002 possible to determine the best border LSRs, and connectivity 1003 cannot even be guaranteed. In this case, signaling crankback 1004 techniques [CRANK] can be used to eventually achieve connectivity, 1005 but optimality is far harder to achieve. In this model, a PCE that 1006 is requested by an ingress LSR to compute a path expects a border 1007 LSR to setup a lower-layer path triggered by high-layer signaling 1008 when there is no TE link between border LSRs. 1010 5.5. Separation of Layer Management 1012 Many network operators may want to provide a clear separation 1013 between the management of the different layer networks. In some 1014 cases, the lower layer network may come from a separate commercial 1015 arm of an organization or from a different corporate body entirely. 1016 In these cases, the policy applied to the establishment of LSPs in 1017 the lower-layer network and to the advertisement of these LSPs as 1018 TE links in the higher-layer network will reflect commercial 1019 agreements and security concerns (see next section). Since the 1020 capacity of the LSPs in the lower-layer network are likely to be 1021 significantly larger than those in the client higher-layer network 1022 (multiplex-server model), the administrator of the lower-layer 1023 network may want to exercise caution before allowing a single 1024 small demand in the higher layer to tie up valuable resources in 1025 the lower layer. 1027 The necessary policy points for this separation of administration 1028 and management are more easily achieved through the VNTM approach 1029 than by using triggered signaling. In effect, the VNTM is the 1030 coordination point for all lower layer LSPs and can be closely 1031 tied to a human operator as well as to policy and billing. Such a 1032 model can also be achieved using triggered signaling. 1034 6. Stability Considerations 1036 Inter-layer traffic engineering needs to be managed and operated 1037 correctly to avoid introducing instability problems. 1039 Lower-layer LSPs are likely, by the nature of the technologies 1040 used in layered networks, to be of considerably higher capacity 1041 than the higher-layer LSPs. This has the benefit of allowing 1042 multiple higher-layer LSPs to be carried across the lower-layer 1043 network in a single lower-layer LSP. However, when a new lower- 1044 layer LSP is set up to support a request for a higher-layer LSP 1045 because there is no suitable route in the higher-layer network, it 1046 may be the case that a very large LSP is established in support of 1047 a very small traffic demand. Further, if the higher-layer LSP is 1048 short-lived, the requirement for the lower-layer LSP will go away 1050 Oki et al Expires June 2008 21 1051 leaving it either in-place but unused, or requiring it to be torn 1052 down. This may cause excessive tie-up of unused lower-layer 1053 network resources, or may introduce instability into the lower- 1054 layer network. It is important that appropriate policy controls or 1055 configuration features are available so that demand-led 1056 establishment of lower-layer LSPs (the so-called "bandwidth on 1057 demand") is filtered according to the requirements of the lower- 1058 layer network. 1060 When a higher-layer LSP is requested to be set up, a new lower- 1061 layer LSP may be established if there is no route with the 1062 requested bandwidth for the higher-layer LSP. After the lower- 1063 layer LSP is established, existing high-layer LSPs could be re- 1064 routed to use the newly established lower-layer LSP if using the 1065 lower-layer LSP provides a better route than that taken by the 1066 existing LSPs. This re-routing may result in lower utilization of 1067 other lower-layer LSPs that used to carry the existing higher- 1068 layer LSPs. When the utilization of a lower-layer LSP drops below 1069 a threshold (or drops to zero), the LSP is deleted according to 1070 lower-layer network policy. But consider that some other new 1071 higher-layer LSP may be requested at once requiring the 1072 establishment or re-establishment of a lower-layer LSP. This, in 1073 turn, may cause higher-layer re-routing making other lower-layer 1074 LSPs under-utilized, in a cyclic manner. This behavior makes the 1075 higher-layer network unstable. 1077 Inter-layer traffic engineering needs to avoid network instability 1078 problems. To solve the problem, network operators may have some 1079 constraints achieved through configuration or policy, where inter- 1080 layer path control actions such as re-routing and deletion of 1081 lower-layer LSPs are not easily allowed. For example, threshold 1082 parameters for the actions are determined so that hysteresis 1083 control behavior can be performed. 1085 7. Manageability Considerations 1087 Inter-layer MPLS or GMPLS traffic engineering must be considered 1088 in the light of administrative and management boundaries that are 1089 likely to coincide with the technology layer boundaries. That is, 1090 each layer network may possibly be under separate management 1091 control with different policies applied to the networks, and 1092 specific policy rules applied at the boundaries between the layers. 1094 Management mechanisms are required to make sure that inter-layer 1095 traffic engineering can be applied without violating the policy 1096 and administrative operational procedures used by the network 1097 operators. 1099 Oki et al Expires June 2008 22 1101 7.1. Control of Function and Policy 1103 7.1.1. 1104 Control of Inter-Layer Computation Function 1106 PCE implementations that are capable of supporting inter-layer 1107 computations should provide a configuration switch to allow 1108 support of inter-layer path computations to be enabled or disabled. 1110 When a PCE is capable of, and configured for, inter-layer path 1111 computation, it should advertise this capability as described in 1112 [PCE-INTER-LAYER-REQ], but this advertisement may be suppressed 1113 through a secondary configuration option. 1115 7.1.2. 1116 Control of Per-Layer Policy 1118 Where each layer is operated as a separate network, the operators 1119 must have control over the policies applicable to each network, 1120 and that control should be independent of the control of policies 1121 for other networks. 1123 Where multiple layers are operated as part of the same network, 1124 the operator may have a single point of control for an integrated 1125 policy across all layers, or may have control of separate policies 1126 for each layer. 1128 7.1.3. 1129 Control of Inter-Layer Policy 1131 Probably the most important issue for inter-layer traffic 1132 engineering is inter-layer policy. This may cover issues such as 1133 under what circumstances a lower layer LSP may be established to 1134 provide connectivity in the higher layer network. Inter-layer 1135 policy may exist to protect the lower layer (high capacity) 1136 network from very dynamic changes in micro-demand in the higher 1137 layer network (see Section 6). It may also be used to ensure 1138 appropriate billing for the lower layer LSPs. 1140 Inter-layer policy SHOULD include the definition of the points of 1141 connectivity between the network layers, the inter-layer TE model 1142 to be applied (for example, the selection between the models 1143 described in this document), and the rules for path computation 1144 and LSP setup. Where inter-layer policy is defined, it MUST be 1145 used consistently throughout the network, and SHOULD be made 1146 available to the PCEs that perform inter-layer computation so that 1147 appropriate paths are computed. Mechanisms for providing policy 1148 information to PCEs are discussed in [PCE-POLICY]. 1150 VNTM may provide a suitable functional component for the 1151 implementation of inter-layer policy. Use of VNTM allows the 1152 administrator of the lower layer network to apply inter-layer 1154 Oki et al Expires June 2008 23 1155 policy without making that policy public to the operator of the 1156 higher layer network. Similarly, a cooperative PCE model (with or 1157 without inter-PCE communication) allows separate application of 1158 policy during the selection of paths. 1160 7.2. Information and Data Models 1162 Any protocol extensions to support inter-layer computations MUST 1163 be accompanied by the definition of MIB objects for the control 1164 and monitoring of the protocol extensions. These MIB object 1165 definitions will conventionally be placed in a separate document 1166 from that which defines the protocol extensions. The MIB objects 1167 MAY be provided in the same MIB module as used for the management 1168 of the base protocol that is being extended. 1170 Note that inter-layer PCE functions SHOULD, themselves, be 1171 manageable through MIB modules. In general, this means that the 1172 MIB modules for managing PCEs SHOULD include objects that can be 1173 used to select and report on the inter-layer behavior of each PCE. 1174 It MAY also be appropriate to provide statistical information that 1175 reports on the inter-layer PCE interactions. 1177 Where there are communications between a PCE and VNTM, additional 1178 MIB modules MAY be necessary to manage and model these 1179 communications. On the other hand, if these communications are 1180 provided through MIB notifications, then those notifications MUST 1181 form part of a MIB module definition. 1183 Policy Information Base (PIB) modules MAY also be appropriate to 1184 meet the requirements as described in Section 6.1 and [PCE-POLICY]. 1186 7.3. Liveness Detection and Monitoring 1188 Liveness detection and monitoring is required between PCEs and 1189 PCCs, and between cooperating PCEs as described in [RFC4657]. 1190 Inter-layer traffic engineering does not change this requirement. 1192 Where there are communications between a PCE and VNTM, additional 1193 liveness detection and monitoring MAY be required to allow the PCE 1194 to know whether the VNTM has received its information about failed 1195 path computations and desired TE links. 1197 When a lower layer LSP fails (perhaps because of the failure of a 1198 lower layer network resource) or is torn down as a result of lower 1199 layer network policy, the consequent change SHOULD be reported to 1200 the higher layer as a change in the VNT, although inter-layer 1201 policy MAY dictate that such a change is hidden from the higher 1202 layer. The upper layer network MAY additionally operate data plane 1203 failure techniques over the virtual TE links in the VNT in order 1205 Oki et al Expires June 2008 24 1206 to monitor the liveness of the connections, but it should be noted 1207 that if the virtual TE link is advertised but not yet established 1208 as an LSP in the lower layer, such higher layer OAM techniques 1209 will report a failure. 1211 7.4. Verifying Correct Operation 1213 The correct operation of the PCE computations and interactions are 1214 described in [RFC4657], [PCEP], etc., and does not need further 1215 discussion here. 1217 The correct operation of inter-layer traffic engineering may be 1218 measured in several ways. First, the failure rate of higher layer 1219 path computations owing to an absence of connectivity across the 1220 lower layer may be observed as a measure of the effectiveness of 1221 the VNT and MAY be reported as part of the data model described in 1222 Section 6.2. Second, the rate of change of the VNT (i.e., the rate 1223 of establishment and removal of higher layer TE links based on 1224 lower layer LSPs) may be seen as a measure of the correct planning 1225 of the VNT and MAY also form part of the data model described in 1226 Section 6.2. Third, network resource utilization in the lower 1227 layer (both in terms of resource congestion, and in consideration 1228 of under utilization of LSPs set up to support virtual TE links) 1229 can indicate whether effective inter-layer traffic engineering is 1230 being applied. 1232 Management tools in the higher layer network SHOULD provide a view 1233 of which TE links are provided using planned lower layer capacity 1234 (that is, physical connectivity or permanent connections) and 1235 which TE links are dynamic and achieved through inter-layer 1236 traffic engineering. Management tools in the lower layer SHOULD 1237 provide a view of the use to which lower layer LSPs are put 1238 including whether they have been set up to support TE links in a 1239 VNT, and if so for which client network. 1241 7.5. Requirements on Other Protocols and Functional Components 1243 There are no protocols or protocol extensions defined in this 1244 document and so it is not appropriate to consider specific 1245 interactions with other protocols. It should be noted, however, 1246 that the objective of this document is to enable inter-layer 1247 traffic engineering for MPLS-TE and GMPLS networks and so it is 1248 assumed that the necessary features for inter-layer operation of 1249 routing and signaling protocols are in existence or will be 1250 developed. 1252 This document introduces roles for various network components (PCE, 1253 LSR, NMS, and VNTM). Those components are all required to play 1254 their part in order that inter-layer TE can be effective. That is, 1256 Oki et al Expires June 2008 25 1257 an inter-layer TE model that assumes the presence and operation of 1258 any of these functional components obviously depends on those 1259 components to fulfill their roles as described in this document. 1261 7.6. Impact on Network Operation 1263 The use of a PCE to compute inter-layer paths is expected to have 1264 a significant and beneficial impact on network operations. Inter- 1265 layer traffic engineering of itself may provide additional 1266 flexibility to the higher layer network while allowing the lower 1267 layer network to support more and varied client networks in a more 1268 efficient way. Traffic engineering across network layers allows 1269 optimal use to be made of network resources in all layers. 1271 The use of PCE as described in this document may also have a 1272 beneficial effect on the loading of PCEs responsible for 1273 performing inter-layer path computation while facilitating a more 1274 independent operation model for the network layers. 1276 8. Security Considerations 1278 Inter-layer traffic engineering with PCE raises new security 1279 issues in all three inter-layer path control models. 1281 In the cooperation model between PCE and VNTM, when the PCE 1282 determines that a new lower-layer LSP is desirable, communications 1283 are needed between the PCE and VNTM and between VNTM and a border 1284 LSR. In this case, these communications should have security 1285 mechanisms to ensure authenticity, privacy and integrity of the 1286 information exchanged. In particular, it is important to protect 1287 against false triggers for LSP setup in the lower-layer network 1288 since such falsification could tie up lower-layer network 1289 resources (achieving a denial of service attack on the lower-layer 1290 network and on the higher layer network that is attempting to use 1291 it) and could result in incorrect billing for services provided by 1292 the lower-layer network. Where the PCE MIB modules are used to 1293 provide the notification exchanges between the higher-layer PCE 1294 and the VNTM, SNMP v3 should be used to ensure adequate security. 1295 Additionally, the VNTM should provide configurable or dynamic 1296 policy functions so that the VNTM behavior upon receiving 1297 notification from a higher-layer PCE can be controlled. 1299 The main security concern in the higher-layer signaling trigger 1300 model is related to confidentiality. The PCE may inform a higher- 1301 layer PCC about a multi-layer path that includes an ERO in the 1302 lower-layer network, but the PCC may not have TE topology 1303 visibility into the lower-layer network and might not be trusted 1304 with this information. A loose hop across the lower-layer network 1306 Oki et al Expires June 2008 26 1307 could be used, but this decreases the benefit of multi-layer 1308 traffic engineering. A better alternative may be to mask the 1309 lower-layer path using a path key [PATH-KEY] that can be expanded 1310 within the lower-layer network. Consideration must also be given 1311 to filtering the recorded path information from the lower-layer - 1312 - 1313 see [RFC4208], for example. 1315 Additionally, in the higher-layer signaling trigger model, 1316 consideration must be given to the security of signaling at the 1317 inter-layer interface since the layers may belong to different 1318 administrative or trust domains. 1320 The NMS-VNTM cooperation model introduces communication between 1321 the NMS and the VNTM. Both of these components belong to the 1322 management plane and the communication is out of scope for this 1323 PCE document. Note that the NMS-VNTM cooperation model may be 1324 considered to address many security and policy concerns because 1325 the control and decision-making is placed within the sphere of 1326 influence of the operator in contrast to the more dynamic 1327 mechanisms of the other models. However, the security issues have 1328 simply moved, and will require authentication of operators and of 1329 policy. 1331 Security issues may also exist when a single PCE is granted full 1332 visibility of TE information that applies to multiple layers. Any 1333 access to the single PCE will immediately gain access to the 1334 topology information for all network layers - 1335 - effectively, a 1336 single security breach can expose information that requires 1337 multiple breaches in other models. 1339 Note that, as described in Section 6, inter-layer TE can cause 1340 network stability issues, and this could be leveraged to attack 1341 either the higher or lower layer network. Precautionary measures, 1342 such as those described in Section 7.1.3, can be applied through 1343 policy or configuration to dampen any network oscillations. 1345 9. Acknowledgments 1347 We would like to thank Kohei Shiomoto, Ichiro Inoue, Julien Meuric, 1348 Jean-Francois Peltier, Young Lee, Ina Minei, and Jean-Philippe 1349 Vasseur for their useful comments. 1351 10. References 1353 10.1. Normative Reference 1355 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 1356 "Multiprotocol Label Switching Architecture", RFC 3031, January 1357 2001. 1359 Oki et al Expires June 2008 27 1361 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1362 Architecture", RFC 3945, October 2004. 1364 [RFC4206] K. Kompella and Y. Rekhter, "Label Switched Paths (LSP) 1365 Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) 1366 Traffic Engineering (TE)", RFC 4206, October 2005. 1368 10.2. Informative Reference 1370 [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi- 1371 region networks (MRN)", draft-ietf-ccamp-gmpls-mln-reqs (work in 1372 progress). 1374 [PCE-INTER-LAYER-REQ] E. Oki et al., "PCC-PCE Communication 1375 Requirements for Inter-Layer Traffic Engineering��, draft-ietf-pce- 1376 inter-layer-req (work in progress). 1378 [BRPC] JP. Vasseur et al., "A Backward Recursive PCE-based 1379 Computation (BRPC) procedure to compute shortest inter-domain 1380 Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc 1381 (work in progress). 1383 [CRANK] A. Farrel et al., "Crankback Signaling Extensions for MPLS 1384 and GMPLS RSVP-TE", RFC 4920, July 2007. 1386 [PCE-MIB] E. Stephan, "Definitions of Textual Conventions for Path 1387 Computation Element", draft-ietf-pce-tc-mib.txt (work in progress). 1389 [RFC4802] A. Farrel and T. Nadeau, "Generalized Multiprotocol 1390 Label Switching (GMPLS) Traffic Engineering Management Information 1391 Base", RFC 4802, February 2007. 1393 [PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A., "Preserving 1394 Topology Confidentiality in Inter-Domain Path Computation Using a 1395 Key Based Mechanism", draft-ietf-pce-path-key, work in progress. 1397 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y., 1398 " Generalized Multiprotocol Label Switching (GMPLS) User-Network 1399 Interface (UNI): Resource ReserVation Protocol-Traffic Engineering 1400 (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. 1402 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 1403 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1405 [RFC4657] J. Ash and J.L. Le Roux (Ed.), "Path Computation Element 1406 (PCE) Communication Protocol Generic Requirements", RFC 4657, 1407 September 2006. 1409 Oki et al Expires June 2008 28 1411 [PCE-POLICY] Bryskin, I., Papadimitriou, P., and Berger, L., 1412 "Policy-Enabled Path Computation Framework", draft-ietf-pce- 1413 policy-enabled-path-comp, (work in progress). 1415 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 1416 communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep 1417 (work in progress). 1419 11. Authors' Addresses 1421 Eiji Oki 1422 NTT 1423 3-9-11 Midori-cho, 1424 Musashino-shi, Tokyo 180-8585, Japan 1425 Email: oki.eiji@lab.ntt.co.jp 1427 Jean-Louis Le Roux 1428 France Telecom R&D, 1429 Av Pierre Marzin, 1430 22300 Lannion, France 1431 Email: jeanlouis.leroux@orange-ftgroup.com 1433 Adrian Farrel 1434 Old Dog Consulting 1435 Email: adrian@olddog.co.uk 1437 12. Intellectual Property Statement 1439 The IETF takes no position regarding the validity or scope of any 1440 Intellectual Property Rights or other rights that might be claimed 1441 to pertain to the implementation or use of the technology 1442 described in this document or the extent to which any license 1443 under such rights might or might not be available; nor does it 1444 represent that it has made any independent effort to identify any 1445 such rights. Information on the procedures with respect to rights 1446 in RFC documents can be found in BCP 78 and BCP 79. 1448 Copies of IPR disclosures made to the IETF Secretariat and any 1449 assurances of licenses to be made available, or the result of an 1450 attempt made to obtain a general license or permission for the use 1451 of such proprietary rights by implementers or users of this 1452 specification can be obtained from the IETF on-line IPR repository 1453 at http://www.ietf.org/ipr. 1455 The IETF invites any interested party to bring to its attention 1456 any copyrights, patents or patent applications, or other 1457 proprietary rights that may cover technology that may be required 1459 Oki et al Expires June 2008 29 1460 to implement this standard. Please address the information to the 1461 IETF at ietf-ipr@ietf.org. 1463 Disclaimer of Validity 1465 This document and the information contained herein are provided on 1466 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1467 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1468 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1469 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1470 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1471 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1472 FOR A PARTICULAR PURPOSE. 1474 Copyright Statement 1476 Copyright (C) The IETF Trust (2008). 1478 This document is subject to the rights, licenses and restrictions 1479 contained in BCP 78, and except as set forth therein, the authors 1480 retain all their rights. 1482 Oki et al Expires June 2008 30