idnits 2.17.1 draft-oki-pce-vntm-def-00.txt: 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 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 768. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- 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 are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 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 15 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 573 has weird spacing: '...erfaces are, ...' -- 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 (June 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eiji Oki 2 Internet Draft NTT 3 Category: Informational Jean-Louis Le Roux 4 Expires: December 2006 France Telecom 5 Adrian Farrel 6 Old Dog Consulting 7 June 2006 9 Definition of Virtual Network Topology Manager (VNTM) for PCE-based 10 Inter-Layer MPLS and GMPLS Traffic Engineering 12 draft-oki-pce-vntm-def-00.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 be built from multiple layers that may be technology- 41 specific divisions, or may be administrative divisions. It is 42 important to globally optimize network resource utilization, taking 43 into account all layers, rather than optimizing resource 44 utilization at each layer independently. This allows better network 45 efficiency to be achieved through a process that we call inter- 46 layer traffic engineering (TE). 48 The Virtual Network Topology (VNT) is defined as the network 49 topology formed by lower-layer LSPs and advertised to the higher 50 layer as TE links. The Path Computation Element (PCE) can be a 51 powerful tool to achieve inter-layer traffic engineering, but 52 requires a separate function to manage and control the VNT. 54 This document defines the VNT Manager (VNTM), which manages and 55 controls the VNT for PCE-based inter-layer traffic engineering. 57 Table of Contents 59 1. Terminology.....................................................2 60 2. Introduction....................................................3 61 2.1. Multiple Lower-Layer Networks................................4 62 3. Cooperation model between PCE and VNTM for Inter-Layer Path 63 Control.............................................................4 64 3.1. VNT Management...............................................4 65 4. Functions of VNT Manager........................................6 66 4.1. Lower-layer LSP Setup........................................6 67 4.1.1. Configuration and Management Control Triggers..............6 68 4.1.2. Higher-Layer PCE Triggers..................................6 69 4.1.3. Establishment of Lower-Layer LSPs..........................6 70 4.1.4. Ownership of Lower-Layer LSPs..............................7 71 4.1.5. Ongoing Management of VNT Resources and Lower-Layer LSPs...7 72 4.2. Advertisement of the VNT to the Higher Layer.................7 73 4.3. Policy Control...............................................8 74 4.3.1. Policies for VNT Establishment.............................8 75 4.3.2. Policies for Handling PCE Triggers.........................8 76 4.3.3. Policies for Responding to PCEs............................9 77 4.3.4. Policies for Control of Advertisement......................9 78 4.3.5. Policies for Ongoing Management............................9 79 4.3.6. Policies for Preemptive Advertisement.....................10 80 4.3.7. Policies for Preemptive LSP Establishment.................10 81 5. Communications between PCE and VNT Manager.....................11 82 5.1. Interface From Higher-Layer PCE to VNT Manager..............11 83 5.2. Interface From VNT Manager to Higher-Layer PCE..............11 84 5.3. Interfaces From VNT Manager to Lower-Layer PCE..............11 85 6. Communications between VNT Manager and LSRs....................12 86 6.1. Interfaces From VNT Manager to LSR..........................12 87 6.2. Interfaces From LSR to VNT Manager..........................12 88 7. Security Considerations........................................12 89 8. Management Considerations......................................13 90 9. Acknowledgment.................................................13 91 10. References...................................................13 92 10.1. Normative Reference.........................................13 93 10.2. Informative Reference.......................................13 94 11. Authors' Addresses...........................................14 95 12. Intellectual Property Statement..............................14 97 1. Terminology 99 This document uses terminology from the PCE-based path computation 100 Architecture [PCE-ARCH] and also common terminology from Multi 102 Oki et al Expires December 2006 2 103 Protocol Label Switching (MPLS) [RFC3031], Generalized MPLS (GMPLS) 104 [RFC3945], and Multi-Layer Networks [MLN-REQ]. 106 VNT Manager (VNTM): an entity that manages and controls the Virtual 107 Network Topology (VNT). 109 2. Introduction 111 A network may be built from multiple layers. These layers may 112 represent separations of technologies (e.g., packet switch capable 113 (PSC), time division multiplex (TDM) lambda switch capable (LSC)) 114 [RFC3945], separation of data plane switching granularity levels 115 (e.g. PSC-1, PSC-2, VC4, VC12) [MLN-REQ], or a distinction between 116 client and server networking roles [MLN-REQ]. In this multi-layer 117 network, LSPs in a lower layer are used to carry higher-layer LSPs 118 across the lower-layer network. The network topology formed by 119 lower-layer LSPs and advertised to the higher layer as TE links is 120 called a Virtual Network Topology (VNT) [MLN-REQ]. 122 It is important to optimize network resource utilization globally, 123 i.e. taking into account all layers, rather than optimizing 124 resource utilization at each layer independently. This allows 125 better network efficiency to be achieved and is what we call inter- 126 layer traffic engineering. This includes mechanisms allowing the 127 computation of end-to-end paths across layers (known as inter-layer 128 path computation), and mechanisms for the control and management of 129 the VNT by setting up and releasing LSPs in the lower layers [MLN- 130 REQ]. 132 Inter-layer traffic engineering is included in the scope of the 133 PCE-based path computation architecture [PCE-ARCH], and PCE can 134 provide a suitable mechanism for resolving inter-layer path 135 computation issues. 137 PCE Communication Protocol requirements for inter-layer traffic 138 engineering are set forth in [PCE-INTER-LAYER-REQ]. A framework for 139 PCE-based inter-layer traffic engineering is described in [PCE- 140 INTER-LAYER-FRWK]. 142 As a result of inter-layer path computation, a PCE may determine 143 that there is insufficient bandwidth available in the higher-layer 144 network to support this or future higher-layer LSPs. The problem 145 might be resolved if new LSPs were provisioned across the lower- 146 layer network and advertised as TE links into the higher-layer 147 network. Further, the modification, re-organization and new 148 provisioning of lower-layer LSPs might enable better utilization of 149 lower-layer network resources given the demands of the higher-layer 150 network. In other words, the VNT needs to be controlled and managed 151 in cooperation with inter-layer path computation. 153 PCE can be a powerful tool to achieve inter-layer traffic 154 engineering. PCE has a path computation function, but does not 155 include a function to manage and control the VNT [PCE-ARCH]. A 157 Oki et al Expires December 2006 3 158 function, separate from PCE, to manage and control the VNT needs to 159 be defined. 161 This document defines the VNT Manager (VNTM) that manages and 162 controls the VNT for PCE-based inter-layer traffic engineering. 163 Path computation and "VNT Management" are distinct functions that 164 may, or may not, be collocated. To describe each function clearly, 165 VNTM is considered as a functional element in this document. 167 2.1. Multiple Lower-Layer Networks 169 It may be the case that a VNT is constructed from LSPs provisioned 170 in more than one lower-layer network, in which case the VNT Manager 171 coordinates the resources of multiple lower-layer networks in order 172 to construct a VNT for use by a higher layer network. 174 Unless necessary to highlight a specific point, this document 175 describes just a single lower-layer network since this makes for 176 easier reading. The reader should recall, however, that anywhere 177 that a lower-layer network is mentioned, the VNT Manager may have 178 made a choice between multiple such networks. 180 3. Cooperation model between PCE and VNTM for Inter-Layer Path Control 182 Two PCE modes defined in the PCE architecture [PCE-ARCH] can be 183 used to perform inter-layer path computation, and these are 184 described as two models for inter-layer path control in [PCE-INTER- 185 LAYER-FRWK]. One is a cooperation model between PCE and VNTM, and 186 the other is a higher-layer signaling trigger model, where VNTM is 187 not involved [MLN-REQ]. This document discusses VNTM and therefore 188 considers only the cooperation model between PCE and VNTM. The 189 higher-layer signaling model is out of scope in this document. 191 From a topology visibility point of view, there are two models: a 192 single PCE path computation model, where a single PCE has 193 visibility of both layers' topology; and a multiple PCE path 194 computation model, where each PCE has visibility of a single 195 layer�s topology. In the following discussion, both path 196 computation models can be applied. 198 3.1. VNT Management 200 -------- ------ -------- 201 | PCE-Hi |--->| VNTM |<-->| PCE-Lo | 202 -------- ------ -------- 203 ^ : ^ 204 : : ..........: 205 : : : 206 v V V 207 ----- ----- ----- ----- 208 | LSR |------| LSR |................| LSR |----| LSR | 209 | H1 | | H2 | | H3 | | H4 | 210 ----- -----\ /----- ----- 212 Oki et al Expires December 2006 4 213 \----- -----/ 214 | LSR |--| LSR | 215 | L1 | | L2 | 216 ----- ----- 218 Figure 1: Cooperation model between PCE and VNTM 220 A multi-layer network consists of higher-layer and lower-layer 221 networks. In Figure 1, LSRs H1, H2, H3, and H4 belong to the 222 higher-layer network, LSRs H2, L1, L2, and H3 belong to the lower- 223 layer network - H2 and H3 are layer border nodes. There are two 224 PCEs: PCE-Hi has visibility in he higher-layer network, and PCE-Lo 225 can see the topology of the lower-layer network. PCE-Hi may 226 communicate with PCE-Lo. PCE-Hi and PCE-Lo can be combined to a 227 single PCE that has both layers' topology visibility. 229 Consider that H1 requests PCE-Hi to compute an inter-layer path 230 between H1 and H4. There is no available TE link in the higher- 231 layer between H2 and H3 before the path computation request. 233 The roles of the PCEs and VNTM are as follows: 235 - PCE-Hi performs inter-layer path computation and is unable to 236 supply a path because there is no available TE link between H2 237 and H3. 239 - The computation fails, and PCE-Hi may suggest to VNTM that a 240 lower-layer LSP (H2-H3) could be established to support future 241 LSP requests. 243 - VNTM uses local policy and possibly management/configuration 244 input to determine how to process the suggestion from PCE-Hi, and 245 may request an ingress LSR (in this case H2) to establish a 246 lower-layer LSP, or may directly configure the LSRs in the lower- 247 layer network in order to achieve the lower-layer LSP. 249 - VNTM or the ingress LSR (H2) may use a second PCE (PCE-Lo) with 250 visibility into the lower layer to compute the path of this new 251 LSP. 253 If PCE-Hi cannot compute a path for the higher-layer LSP without 254 the establishment of a further lower-layer LSP, PCE-Hi that 255 notifies VNTM may wait for the lower-layer LSP to be set up and 256 advertised as a TE link. It can then compute the complete end-to- 257 end path for the higher-layer LSP and return the result to the PCC. 258 In this case, the PCC may be kept waiting some time, and it is 259 important that the PCC understands this. The higher-layer PCE and 260 VNTM must have mechanisms to control the time that the PCE will 261 wait and that the PCC will be kept waiting. This may take the form 262 of any or all of the following: 264 - An agreement between the PCE and VNTM that the lower-layer LSP 265 will be set up in a timely manner. That is, an agreement that 267 Oki et al Expires December 2006 5 268 following such a notification by PCE, a lower-layer LSP will be 269 provided within a well-known time period. 271 - A timeout operated by the PCE such that if no lower-layer LSP is 272 provided in a well-known time, the PCE will give up and fail the 273 computation request back to the PCC. Such a timeout might be a 274 default on the PCE, or might be supplied as part of the request by 275 the PCC. 277 - A timeout operated by the PCC such that if no response is 278 received by the PCC within a certain time it will give up and 279 cancel the computation request. 281 - A notification mechanism so that the VNTM can inform the PCE that 282 it is attempting to set up the necessary LSP or that no new LSP 283 will become available. 285 An example of such a cooperative procedure between PCE and VNTM is 286 described in [PCE-INTER-LAYER-FRWK]. 288 4. Functions of VNT Manager 290 This section lists the major functions performed by the VNT Manager. 292 4.1. Lower-layer LSP Setup 294 Management of the LSPs in the lower layer network falls into 295 several distinct functional elements. 297 4.1.1. Configuration and Management Control Triggers 299 The VNT may be entirely under the control of the operator through 300 configuration or management control. In this case, VNT Manager 301 performs functions to map the operator's requests onto requests to 302 provision lower-layer LSPs. For example, the operator may request 303 the establishment of a TE link in the higher-layer (that is, in the 304 VNT) between two layer border nodes leaving it to VNT Manager to 305 determine how to realize this TE link. The operator may also be 306 more specific and define how this TE link will be supported by the 307 lower-layer network. 309 4.1.2. Higher-Layer PCE Triggers 311 VNTM may receive suggestions (notification or lower-layer LSP setup 312 request) from a PCE that new TE links in the higher-layer network 313 would be helpful and that lower-layer LSPs should be established if 314 judged by VNTM to be necessary and possible, and if acceptable 315 within VNTM�s policy constraints. 317 4.1.3. Establishment of Lower-Layer LSPs 319 VNTM reviews the triggers that it receives, the existing lower- 320 layer LSPs, the available resources, and the current and predicted 322 Oki et al Expires December 2006 6 323 VNT usage, and may request ingress LSRs in the lower-layer network 324 to establish one or more lower-layer LSPs. These requests may 325 include pre-computed lower-layer LSP routes obtained from the PCE 326 responsible for the lower-layer network, or may require the ingress 327 LSRs to perform path computations (possibly using the PCE for the 328 lower layer network) in order to determine the routes of the LSPs. 330 The VNTM may also configure the LSRs in the lower-layer network 331 directly if that network is under management plane control. 333 Further, where (as described in Section 2.1) the VNT is constructed 334 from resources in more than one lower-layer network, VNT Manager 335 will apply policies to determine in which lower-layer network the 336 new LSPs should be established. 338 4.1.4. Ownership of Lower-Layer LSPs 340 VNTM is the 'owner' of the lower-layer LSPs that it causes to be 341 created. It receives notifications from the ingress LSRs when the 342 LSRs are established, and collects information about the TE 343 attributes, status, and usage of those LSPs. 345 4.1.5. Ongoing Management of VNT Resources and Lower-Layer LSPs 347 VNTM constantly monitors the demand and usage of VNT resources 348 (that is, of the TE links provided to the higher-layer network), 349 and the usage and status of the lower-layer LSPs that it has 350 created. It uses this information together with local policy (see 351 Section 4.3) to manage the lower-layer LSPs. 353 Such management might include: 355 - Teardown of unused lower-layer LSPs. 357 - Predictive establishment of lower-layer LSPs to increase the 358 capacity of TE links in the VNT or to provide additional TE links. 360 - Coordination with the higher layer to achieve controlled grooming 361 and reoptimization of the use of the higher-layer TE links in 362 order to release LSPs and resources in the lower layer. Such 363 reoptimization may require correlated path computation of lower 364 layer LSPs paths, which may be achieved using a PCE in the lower 365 layer. 367 4.2. Advertisement of the VNT to the Higher Layer 369 VNT Manager is responsible for determining which TE links provided 370 by the lower layer are advertised to the higher-layer network. That 371 is, it defines the VNT. 373 Advertisement may take two non exclusive forms: 375 - Where VNTM has received a trigger notification from a higher- 376 layer PCE, and where that notification has requested it, VNTM may 378 Oki et al Expires December 2006 7 379 inform the PCE directly that the lower-layer LSP is established 380 and provide the related TE information (TE link ids, etc.) That is, 381 it notifies the 382 PCE of the existence of a new TE link, or of the change in 383 capabilities of an existing TE link. 385 - The VNTM may advertise the new TE link or changed 386 TE link capabilities into the Traffic Engineering Database (TED) 387 used by the PCE in the higher-layer network. Such an 388 advertisement might be: 390 - through the routing protocols (IGPs) operating in the higher 391 layer with the ingress layer border node being instructed by 392 the VNTM about what to advertise 394 - through the routing protocols (IGPs) operating in the higher 395 layer with the VNTM playing an active part in advertising TE 396 links. 398 - by other means direct to the TED on the PCE. 400 Thus, PCE may get to know about the existence of the new VNT 401 resources immediately or when the IGP converges. 403 4.3. Policy Control 405 VNT Manager may have significant policy control functions that can 406 be configured by the service provider. 408 4.3.1. Policies for VNT Establishment 410 Initial VNT establishment and the establishment of the lower-layer 411 LSPs necessary to support the VNT is under the control of the 412 operator. This is a policy function for several reasons. 414 - The lower-layer network may have other responsibilities as well 415 as supporting the VNT. That is, it may also have to carry traffic 416 in its own right. There is a policy-based balance between the use 417 of lower-layer resources for the VNT and for native LSPs. 419 - There may be more than one VNT supported by the lower-layer 420 network. That is, there may be more than one higher-layer network 421 that depends on the lower-layer network to provide it with 422 connectivity and capacity. These VNTs may be entirely independent. 423 There is a role for policy in determining how lower-layer 424 resources are allocated to support the different VNTs, and to 425 what extent the VNTs are able to share lower-layer resources. 427 4.3.2. Policies for Handling PCE Triggers 429 When VNTM receives a suggestion from PCE that new upper-layer TE 430 resources are desired, VNTM determines whether lower-layer LSPs 431 should be established and what type of LSPs are set up according to 432 the local policy, requested parameters, and network conditions. 434 Oki et al Expires December 2006 8 435 This policy is very likely to vary depending on the PCE that sends 436 the notification - some PCEs may have higher trust levels, and some 437 may have greater authority. 439 Acceptable policies for VNTM include: 440 - ignoring (discarding) the notification 441 - rejecting the request by informing the PCE that no action will be 442 taken 443 - storing the notification to build a pattern of demand 444 - acting immediately to establish the necessary lower-layer LSPs 445 - responding as though lower-layer LSPs had already been 446 established (see Section 4.3.6). 448 Note that VNTM may choose to establish LSPs to provide a TE link 449 considerably larger than indicated by the notification from the PCE. 450 This choice, under control of local policy, could reduce the 451 requirement for small incremental change to the VNT and might 452 reduce the interactions between PCE and VNTM. Such policy might 453 also be influenced by the capacity of resources in the lower-layer 454 network. 456 4.3.3. Policies for Responding to PCEs 458 Section 3 describes how a PCE may wait for a response from VNTM 459 before completing a computation request. But VNTM does not 460 necessarily have to provide a positive or negative response. 461 According to policy, VNTM may also either simply not respond to the 462 PCE, or may respond to say that it is not providing any further 463 information. These policies may be applicable in conjunction with 464 policies for advertisement (see Section 4.3.4). 466 4.3.4. Policies for Control of Advertisement 468 It is possible that a VNT Manager will choose not to advertise all 469 TE link changes into the higher-layer network immediately or at all. 470 For example, some changes may be relatively small and might cause 471 unnecessary advertisement traffic (such as in the IGP). Other TE 472 links might be notified directly to the requesting PCE, but not 473 generally advertised - such TE links are on a par with static links 474 configured only at the PCE. 476 Such advertising policies should be under the control of the 477 operator. 479 4.3.5. Policies for Ongoing Management 481 Local policy will determine how VNTM handles lower-layer LSPs that 482 are not carrying traffic but support TE links in the VNT. Such LSPs 483 may be retained for use in the VNT, reassigned for other uses (such 484 as for other VNTs), or torn down. Careful consideration would be 485 necessary to prevent LSP flapping. 487 Oki et al Expires December 2006 9 488 When an LSP is torn down or reassigned, the TE link would normally 489 be removed or appropriately reduced within the VNT. However, the 490 same policy-based considerations as described in Section 4.3.6 for 491 preemptive advertisement apply in this case. 493 Further, ongoing management of the VNT may determine a pattern of 494 notifications from the PCEs or a pattern of increasing traffic 495 demand and may react by increasing the TE capacity in the VNT as 496 described in Section 4.3.7. 498 Note that when a VNT is modified as the result of a PCE trigger, it 499 is possible that VNT Manager does not inform the PCE directly, but 500 simply causes a change to the advertisement of the available VNT 501 resources, requiring PCE to pick this information up in the usual 502 way. 504 A VNT Manager may implement its own policies for protection and 505 recovery of the LSPs that support the TE links in the VNT. This may 506 enable the TE links to be recovered within the lower-layers without 507 disruption of the VNT. This policy is likely to be coordinated with 508 the desired protection qualities indicated by the PCE, and the link 509 protection attributes advertised for the TE link into the higher- 510 layer network. 512 4.3.6. Policies for Preemptive Advertisement 514 A VNT Manager may choose to advertise VNT resources (TE capacity) 515 before the lower-layer LSPs have been established. This may be done 516 to facilitate a better TE mesh in the higher-layer network while 517 conserving resources in the lower-layer network. 519 In this case the lower-layer LSPs should be theoretically possible 520 based on an analysis of the available lower-layer resources, and 521 might rely on PCE path computations within the lower-layer network. 522 Periodic reassessment of the state of the lower-layer network might 523 cause changes in the preemptively advertised TE links. 525 Note that if an attempt is made by the higher-layer network to use 526 such TE links, the layer border router will need to trigger the 527 establishment of the requisite lower-layer LSPs, therefore, VNT 528 Manager must also coordinate with those LSRs. 530 This behavior is dependent on policy configured at the VNT Manager. 532 4.3.7. Policies for Preemptive LSP Establishment 534 VNT Manager may also pre-establish LSPs that it predicts will be 535 useful to support TE links in one or more VNTs. This behavior ties 536 up lower-layer resources, but allows a more rapid response when TE 537 links are needed in the higher-layer networks. 539 Since there is an operational trade-off here, it is a feature that 540 should be under the control of policy at the VNT Manager. 542 Oki et al Expires December 2006 10 543 Such policies might be linked to knowledge of time-based resource 544 requirements in the higher-layer network especially where resources 545 are needed at peak times or to meet certain scheduled services. 547 5. Communications between PCE and VNT Manager 549 5.1. Interface From Higher-Layer PCE to VNT Manager 551 PCE needs to be able to communicate to VNT Manager that it would 552 like additional TE capacity in the higher-layer network. Such a 553 notification needs at least the following information: 554 - end points of the TE link capacity desired 555 - whether a modification of existing TE links would be acceptable 556 - protection type and diversity from existing TE links 557 - desired QoS characteristics (especially delay) for the new TE 558 link 559 - switching and encoding types. 561 The PCE can also supply information as follows: 562 - whether the PCE intends to wait for a response, and if so, for 563 how long 564 - some measure of the urgency of the demand it is facing (for 565 example, whether it is receiving repeated requests, or whether 566 this is as a result for a high priority service) 567 - some description of the service it will place on the TE link 568 (that is, it may request a high capacity TE link, but only plan 569 on placing a low capacity service) 570 - advice about what cost metric to assign when the created TE link 571 is advertised. 573 Potential candidate protocols for the interfaces are, for example, 574 PCEP extensions, SOAP, and proprietary interfaces. 576 5.2. Interface From VNT Manager to Higher-Layer PCE 578 VNT Manager may want to be able to respond to PCE as follows: 579 - No action will be taken as a result of your notification. 580 - Don't wait for a TE link to be created/modified. 581 - TE link creation/modification not possible or failed. 582 - TE link creation/modification in progress. 583 - TE link creation/modification performed. New TE link details will 584 be advertised as normal. 585 - TE link creation/modification performed. New TE link details 586 included. 588 Note that this response interface is optional. That is, since the 589 VNT is already advertised through normal mechanisms, there is no 590 direct need for this interface. 592 5.3. Interfaces From VNT Manager to Lower-Layer PCE 594 VNT Manager may need to consult a PCE responsible for the lower- 595 layer network in order to determine the viability of new TE link 596 creation or to select the paths of new lower-layer LSPs. 598 Oki et al Expires December 2006 11 599 In this relationship with the lower-layer PCE, VNTM acts as a PCC 600 and uses the normal PCC-PCE interface. 602 6. Communications between VNT Manager and LSRs 604 6.1. Interfaces From VNT Manager to LSR 606 When VNT Manager requires one or more LSPs to be set up or modified 607 in the lower-layer network it issues commands to the LSRs in the 608 lower-layer network. 610 If the lower-layer network is under management plane control, these 611 commands will be sent to each LSR along the path of the desired 612 LSPs in order to provision resources and cross-connects. In this 613 case, VNT Manager would use existing standard (for example, SNMP 614 control of MPLS-LSR-STD-MIB [RFC3813] and GMPLS-LSR-STD-MIB [GMPLS- 615 LSR-MIB]) or proprietary management interfaces. 617 If the lower-layer network is under the control of a control plane, 618 these commands are sent to the head-end (ingress) LSRs for each of 619 the required LSPs. In this case, VNT Manager would use existing 620 standard (for example, SNMP control of MPLS-TE-STD-MIB [RFC3812] 621 and GMPLS-TE-STD-MIB [GMPLS-TE-MIB]) or proprietary management 622 interfaces. The head-end LSRs might need to consult a PCE to 623 complete the necessary path computation. 625 Additionally, VNT Manager needs to control the way that new TE 626 links are advertised into the higher-layer network as part of the 627 VNT. If the head-end LSR is responsible for this advertisement, 628 this information can be passed to the head-end LSR either on the 629 LSP setup request, or in a separate exchange after the LSP has been 630 set up. 632 6.2. Interfaces From LSR to VNT Manager 634 VNT Manager may need to know when lower-layer LSPs have been set up, 635 or when they have been impacted by network events. This is not a 636 requirement in all models because the head-end LSRs may be 637 responsible for managing TE link advertisement into the higher- 638 layer network, and because the VNTM might not be sending responses 639 direct to the higher-layer PCE. 641 If this feature is required, the interface can be provided by 642 notifications from existing standard (for example, SNMP control of 643 MPLS-TE-STD-MIB [RFC3812] and GMPLS-TE-STD-MIB [GMPLS-TE-MIB]) or 644 proprietary management interfaces. 646 7. Security Considerations 648 Inter-layer traffic engineering with PCE may raise new security 649 issues in the cooperation model between PCE and VNTM. 651 Oki et al Expires December 2006 12 652 VNTM introduces new communication flows and these must be secured 653 against all normal attacks. Using existing protocol techniques 654 (such as SNMPv3 [SNMPv3] and PCEP [PCEP]) will allow the security 655 model to be constructed easily. The introduction of new protocols 656 would require careful analysis of the protocol issues. 658 Further analysis of the security mechanisms necessary for VNTM to 659 ensure authenticity, privacy and integrity will be provided in a 660 later version of this document. 662 8. Management Considerations 664 TBD 666 9. Acknowledgment 668 We would like to thank Kohei Shiomoto and Ichiro Inoue for their 669 useful comments. 671 10. References 673 10.1. Normative Reference 675 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 676 Label Switching Architecture", RFC 3031, January 2001. 678 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 679 Architecture", RFC 3945, October 2004. 681 [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi- 682 region networks (MRN) ", draft-ietf-ccamp-gmpls-mln-reqs (work in 683 progress). 685 [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, "Path Computation 686 Element (PCE) Architecture", draft-ietf-pce-architecture (work in 687 progress). 689 10.2. Informative Reference 691 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 692 "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 693 Management Information Base (MIB)", RFC 3812, June 2004. 695 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 696 "Multiprotocol Label Switching (MPLS) Label Switching (LSR) Router 697 Management Information Base (MIB)", RFC 3813, June 2004. 699 [GMPLS-LSR-MIB] Nadeau, T. and A. Farrel, "Generalized 700 Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) 701 Management Information Base", draft-ietf-ccamp-gmpls-lsr-mib, (work 702 in progress). 704 Oki et al Expires December 2006 13 706 [GMPLS-TE-MIB] Nadeau, T. and A. Farrel, "Generalized Multiprotocol 707 Label Switching (GMPLS) Traffic Engineering Management Information 708 Base", draft-ietf-ccamp-gmpls-te-mib, (work in progress). 710 [PCE-INTER-LAYER-FRWK] E. Oki et al., " Framework for PCE-Based 711 Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce- 712 inter-layer-frwk (work in progress). 714 [PCE-INTER-LAYER-REQ] E. Oki et al., "PCC-PCE Communication 715 Requirements for Inter-Layer Traffic Engineering" draft-ietf-pce- 716 inter-layer-req (work in progress). 718 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 719 communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep 720 (work in progress). 722 [SNMPv3] Case, J., Mundy, R., Partain, D., and B. Stewart, 723 "Introduction and Applicability Statements for Internet-Standard 724 Management Framework", RFC 3410, December 2002. 726 11. Authors' Addresses 728 Eiji Oki 729 NTT 730 3-9-11 Midori-cho, 731 Musashino-shi, Tokyo 180-8585, Japan 732 Email: oki.eiji@lab.ntt.co.jp 734 Jean-Louis Le Roux 735 France Telecom R&D, 736 Av Pierre Marzin, 737 22300 Lannion, France 738 Email: jeanlouis.leroux@francetelecom.com 740 Adrian Farrel 741 Old Dog Consulting 742 Email: adrian@olddog.co.uk 744 12. Intellectual Property Statement 746 The IETF takes no position regarding the validity or scope of any 747 Intellectual Property Rights or other rights that might be claimed 748 to pertain to the implementation or use of the technology described 749 in this document or the extent to which any license under such 750 rights might or might not be available; nor does it represent that 751 it has made any independent effort to identify any such rights. 752 Information on the procedures with respect to rights in RFC 753 documents can be found in BCP 78 and BCP 79. 755 Copies of IPR disclosures made to the IETF Secretariat and any 756 assurances of licenses to be made available, or the result of an 757 attempt made to obtain a general license or permission for the use 758 of such proprietary rights by implementers or users of this 760 Oki et al Expires December 2006 14 761 specification can be obtained from the IETF on-line IPR repository 762 at http://www.ietf.org/ipr. 764 The IETF invites any interested party to bring to its attention any 765 copyrights, patents or patent applications, or other proprietary 766 rights that may cover technology that may be required to implement 767 this standard. Please address the information to the IETF at ietf- 768 ipr@ietf.org. 770 Disclaimer of Validity 772 This document and the information contained herein are provided on 773 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 774 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 775 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 776 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 777 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 778 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 779 PARTICULAR PURPOSE. 781 Copyright Statement 783 Copyright (C) The Internet Society (2006). This document is 784 subject to the rights, licenses and restrictions contained in BCP 785 78, and except as set forth therein, the authors retain all their 786 rights. 788 Oki et al Expires December 2006 15