idnits 2.17.1 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 13, 2008) is 5941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kumaki, Ed. 2 Internet Draft KDDI Corporation 3 Intended Status: Informational 4 Created: January 13, 2008 5 Expires: July 13, 2008 7 Interworking Requirements to Support operation of MPLS-TE over GMPLS 8 Networks 10 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Operation of a Multiprotocol Label Switching (MPLS) traffic 38 engineering (TE) network as a client network to a Generalized MPLS 39 (GMPLS) network has enhanced operational capabilities compared to 40 those provided by a co-existent protocol model (i.e., operation of 41 MPLS-TE over an independently managed transport layer). 43 The GMPLS network may be a packet or a non-packet network, and may 44 itself be a multi-layer network supporting both packet and non-packet 45 technologies. A MPLS-TE Label Switched Path (LSP) originates and 46 terminates on an MPLS Label Switching Router (LSR). The GMPLS network 47 provides transparent transport for the end-to-end MPLS-TE LSP. 49 This document describes a framework and Service Provider requirements 50 for operating MPLS-TE networks over GMPLS networks. 52 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 54 Table of Contents 56 1. Introduction.....................................................2 57 1.1 Terminology..................................................3 58 2. Reference Model..................................................4 59 3. Detailed Requirements............................................5 60 3.1 End-to-End Signaling.........................................5 61 3.2 Triggered Establishment of GMPLS LSPs........................5 62 3.3 Diverse Paths for End-to-End MPLS-TE LSPs....................5 63 3.4 Advertisement of MPLS-TE Information via the GMPLS Network...6 64 3.5 Selective Advertisement of MPLS-TE Information via a 65 Border Node..................................................6 66 3.6 Interworking of MPLS-TE and GMPLS Protection.................6 67 3.7 Independent Failure Recovery and Reoptimization..............6 68 3.8 Complexity and Risks.........................................7 69 3.9 Scalability Considerations...................................7 70 3.10 Performance Considerations..................................7 71 3.11 Management Considerations...................................7 72 4. Security Considerations..........................................8 73 5. Recommended Solution Architecture................................8 74 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs...........9 75 5.2 MPLS-TE Control Plane Connectivity...........................9 76 5.3 Fast Reroute Protection.....................................10 77 5.4 GMPLS LSP Advertisement.....................................10 78 5.5 GMPLS Deployment Considerations.............................10 79 6. IANA Considerations.............................................11 80 7. Acknowledgments.................................................11 81 8. References......................................................11 82 8.1 Normative References........................................11 83 8.2 Informative References......................................11 84 9. Author's Address................................................12 85 10. Contributors' Addresses........................................12 86 11. Full Copyright Statement.......................................13 87 12. Intellectual Property..........................................13 89 1. Introduction 91 Multiprotocol Label Switching traffic engineering (MPLS-TE) networks 92 are often deployed over transport networks such that the transport 93 networks provide connectivity between the Label Switching Routers 94 (LSRs) in the MPLS-TE network. Increasingly, these transport networks 95 are operated using a Generalized Multiprotocol Label Switching 96 (GMPLS) control plane, and label Switched Paths (LSPs) in the GMPLS 97 network provide connectivity as virtual data links advertised as TE 98 links in the MPLS-TE network. 100 GMPLS protocols were developed as extensions to MPLS-TE protocols. 101 MPLS-TE is limited to the control of packet switching networks, but 102 GMPLS can also control technologies at layers one and two. 104 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 106 The GMPLS network may be managed by an operator as a separate network 107 (as it may have been when it was under management plane control 108 before the use of GMPLS as a control plane), but optimizations of 109 management and operation may be achieved by coordinating the use of 110 the MPLS-TE and GMPLS networks and operating the two networks with a 111 close client/server relationship. 113 GMPLS LSP setup may triggered by the signaling of MPLS-TE LSPs in the 114 MPLS-TE network so that the GMPLS network is reactive to the needs of 115 the MPLS-TE network. The triggering process can be under the control 116 of operator policies without needing direct intervention by an 117 operator. 119 The client/server configuration just described can also apply in 120 migration scenarios for MPLS-TE packet switching networks that are 121 being migrated to be under GMPLS control. [MIGRATE] describes a 122 migration scenario called the Island Model. In this scenario, groups 123 of nodes (islands) are migrated from the MPLS-TE protocols to the 124 GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the 125 sea). This scenario can be effectively managed as a client/server 126 network relationship using the framework described in this document. 128 In order to correctly manage the dynamic interaction between the MPLS 129 and GMPLS networks, it is necessary to understand the operational 130 requirements and the control that the operator can impose. Although 131 this problem is very similar to the multi-layer networks described in 132 [MLN], it must be noted that those networks operate GMPLS protocols 133 in both the client and server networks which facilitates smoother 134 interworking. Where the client network uses MPLS-TE protocols over 135 the GMPLS server network there is a need to study the interworking of 136 the two protocol sets. 138 This document examines the protocol requirements for protocol 139 interworking to operate an MPLS-TE network as a client network over a 140 GMPLS server network, and provides a framework for such operations. 142 1.1 Terminology 144 Although this Informational document is not a protocol specification, 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119] for clarity 148 of exposure of the requirements. 150 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 152 2. Reference Model 154 The reference model used in this document is shown in Figure 1. It 155 can easily be seen that the interworking between MPLS-TE and GMPLS 156 protocols must occur on a node and not on a link. Nodes on the 157 interface between the MPLS-TE and GMPLS networks must be responsible 158 for handling both protocol sets and for providing any protocol 159 interworking that is required. We call these nodes Border Routers. 161 -------------- ------------------------- -------------- 162 | MPLS Client | | GMPLS Server Network | | MPLS Client | 163 | Network | | | | Network | 164 | | | | | | 165 | ---- --+--+-- ----- ----- --+--+-- ---- | 166 | | | | | | | | | | | | | | 167 | |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS| | 168 | |LSR | | Router | | LSR | | LSR | | Router | |LSR | | 169 | | | | | | | | | | | | | | 170 | ---- --+--+-- ----- ----- --+--+-- ---- | 171 | | | | | | 172 | | | | | | 173 -------------- ------------------------- -------------- 175 | | GMPLS LSP | | 176 | |<------------------------->| | 177 | | 178 |<--------------------------------------------->| 179 End-to-End MPLS-TE LSP 181 Figure 1. Reference model of MPLS-TE/GMPLS interworking 183 MPLS-TE network connectivity is provided through a GMPLS LSP which is 184 created between Border Routers. End-to-end connectivity between MPLS 185 LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP 186 that is carried across the MPLS-TE network by the GMPLS LSP using 187 hierarchical LSP techniques [RFC4206], LSP stitching segments 188 [STITCH], or a contiguous LSP. LSP stitching segments and contiguous 189 LSPs are only available where the GMPLS network is a packet switching 190 network. 192 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 194 3. Detailed Requirements 196 This section describes detailed requirements for MPLS-TE/GMPLS 197 interworking in support of the reference model shown in Figure 1. 199 The functional requirements for GMPLS-MPLS interworking described in 200 this section must be met by any device participating in the 201 interworking. This may include routers, servers, network management 202 devices, path computation elements, etc. 204 3.1 End-to-End Signaling 206 The solution MUST be able to preserve MPLS signaling information 207 signaled within the MPLS-TE client network at the start of the MPLS- 208 TE LSP, and deliver it on the other side of the GMPLS server network 209 for use within the MPLS-TE client network at the end of the MPLS-TE 210 LSP. This may require protocol mapping (and re-mapping), protocol 211 tunneling, or the use of remote protocol adjacencies. 213 3.2 Triggered Establishment of GMPLS LSPs 215 The solution MUST provide the ability to establish end-to-end MPLS- 216 TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS 217 LSPs across the core network to be set up between Border Routers 218 triggered by the signaling of MPLS-TE LSPs in the client network, and 219 in this case, policy controls MUST be made available at the border 220 routers so that the operator of the GMPLS network can manage how core 221 network resources are utilized. GMPLS LSPs MAY also be pre- 222 established as the result of management plane control. 224 Note that multiple GMPLS LSPs may be set up between a given pair of 225 Border Routers in support of connectivity in the MPLS client network. 226 If these LSPs are advertised as TE links in the client network, the 227 use of link bundling [RFC4201] can reduce any scaling concerns 228 associated with the advertisements. 230 The application of the Path Computation Element (PCE) [RFC4655] in 231 the context of an inter-layer network [PCE-INTER-LAYER] may be 232 considered to determine an end-to-end LSP with triggered GMPLS 233 segment or tunnel. 235 3.3 Diverse Paths for End-to-End MPLS-TE LSPs 237 The solution SHOULD provide the ability to establish end-to-end MPLS- 238 TE LSPs having diverse paths for protection of the LSP traffic. This 239 means that MPLS-TE LSPs SHOULD be kept diverse both within the client 240 MPLS-TE network and as they cross the server GMPLS network. This 241 means that there SHOULD be a mechanism to request the provision of 242 diverse GMPLS LSPs between a pair of Border Routers to provide 243 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 245 protection of the GMPLS span, but also that there SHOULD be a way to 246 keep GMPLS LSPs between different Border Routers disjoint. 248 3.4 Advertisement of MPLS-TE Information via the GMPLS Network 250 The solution SHOULD provide the ability to exchange advertisements of 251 TE information between MPLS-TE client networks across the GMPLS 252 server network. 254 The advertisement of TE information from within an MPLS-TE client 255 network to all LSRs in the client network enables a head end LSR to 256 compute an optimal path for an LSP to a tail end LSR that is reached 257 over the GMPLS server network. 259 Where there is more than one client MPLS-TE network, the TE 260 information from separate MPLS-TE networks MUST be kept private, 261 confidential and secure. 263 3.5 Selective Advertisement of MPLS-TE Information via a Border Node 265 The solution SHOULD provide the ability to distribute TE reachability 266 information from the GMPLS server network to MPLS-TE networks 267 selectively. This information is useful for the LSRs in the MPLS-TE 268 networks to compute paths that cross the GMPLS server network and to 269 select the correct Border Routers to provide connectivity. 271 The solution MUST NOT distribute TE information from within a non-PSC 272 (Packet Switch Capable) GMPLS server network to any client MPLS-TE 273 network as that information may cause confusion and selection of 274 inappropriate paths. 276 The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS 277 networks supporting PSC MPLS networks. 279 3.6 Interworking of MPLS-TE and GMPLS Protection 281 If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR) 282 [RFC4090], then similar protection MUST be provided over the GMPLS 283 island. Operator and policy controls SHOULD be made available at the 284 Border Router to determine how suitable protection is provided in the 285 GMPLS island. 287 3.7 Independent Failure Recovery and Reoptimization 289 The solution SHOULD provide failure recovery and reoptimization in 290 the GMPLS server network without impacting the MPLS-TE client network 291 and vice versa. That is, it SHOULD be possible to recover from a 292 fault within the GMPLS island or to reoptimize the path across the 293 GMPLS island without requiring signaling activity within the MPLS-TE 294 client network. Similarly, it SHOULD be possible to perform recovery 295 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 297 or reoptimization within the MPLS-TE client network without requiring 298 signaling activity within the GMPLS server networks. 300 If a failure in the GMPLS server network can not be repaired 301 transparently, some kind of notification of the failure SHOULD be 302 transmitted to MPLS-TE network. 304 3.8 Complexity and Risks 306 The solution SHOULD NOT introduce unnecessary complexity to the 307 current operating network to such a degree that it would affect the 308 stability and diminish the benefits of deploying such a solution in 309 service provider networks. 311 3.9 Scalability Considerations 313 The solution MUST scale well with consideration to at least the 314 following metrics. 316 - The number of GMPLS-capable nodes (i.e., the size of the GMPLS 317 server network). 318 - The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE 319 client network). 320 - The number of MPLS-TE client networks. 321 - The number of GMPLS LSPs. 322 - The number of MPLS-TE LSPs. 324 3.10 Performance Considerations 326 The solution SHOULD be evaluated with regard to the following 327 criteria. 329 - Failure and restoration time. 330 - Impact and scalability of the control plane due to added 331 overheads. 332 - Impact and scalability of the data/forwarding plane due to added 333 overheads. 335 3.11 Management Considerations 337 Manageability of the deployment of an MPLS-TE client network over 338 GMPLS server network MUST addresses the following considerations. 340 - Need for coordination of MIB modules used for control plane 341 management and monitoring in the client and server networks. 342 - Need for diagnostic tools that can discover and isolate faults 343 across the border between the MPLS-TE client and GMPLS server 344 networks. 346 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 348 4. Security Considerations 350 Border routers in the model described in this document are present on 351 administrative domain boundaries. That is, the administrative 352 boundary does not lie on a link as it might in the inter-Autonomous 353 System case seen in IP networks. Thus, many security concerns for the 354 inter-domain exchange of control plane messages do not arise in this 355 model - the border router participates fully in both the MPLS and the 356 GMPLS network and must participate in the security procedures of both 357 networks. Security considerations for MPLS-TE and GMPLS protocols are 358 discussed in [SECURITY]. 360 However, policy considerations at the border routers are very 361 important and may be considered to form part of the security of the 362 networks. In particular, the server network (the GMPLS network) may 363 wish to protect itself from behavior in the client network (such as 364 frequent demands to set up and tear down server LSPs) by appropriate 365 policies implemented at the border routers. It should be observed 366 that, because the border routers form part of both networks, they are 367 trusted in both networks, and policies configured (whether locally or 368 centrally) for use by a border router are expected to be observed. 370 Nevertheless, authentication and access controls for operators will 371 be particularly important at border routers. Operators of the client 372 MPLS-TE network MUST NOT be allowed to configure the server GMPLS 373 network (including setting server network policies), and operators of 374 the server GMPLS network MUST NOT be able configure the client MPLS- 375 TE network. Obviously, it SHOULD be possible to grant an operator 376 privileges in both networks. It may also be desirable to give 377 operators of one network access to (for example) status information 378 about the other network. 380 Mechanisms for authenticating operators and providing access controls 381 do not form part of the responsibilities of the GMPLS protocol set, 382 and will depend on the management plane protocols and techniques 383 implemented. 385 5. Recommended Solution Architecture 387 The recommended solution architecture to meet the requirements set 388 out in Section 3 is known as the Border Peer Model. This architecture 389 is a variant of the Augmented Model described in [RFC3945]. The 390 remainder of this document presents an overview of this architecture. 392 In the Augmented Model, routing information from the lower layer 393 (server) network is filtered at the interface to the higher layer 394 (client) network and a subset of the information is distributed 395 within the higher layer network. 397 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 399 In the Border Peer Model, the interface between the client and server 400 networks is the Border Router. This router has visibility of the 401 routing information in the server network yet also participates as a 402 peer in the client network. Thus the Border Router has full 403 visibility into both networks. However, the Border Router does not 404 distribute server routing information into the client network, nor 405 does it distribute client routing information into the server 406 network. 408 The Border Peer Model may also be contrasted with the Overlay Model 409 [RFC3945]. In this model there is a protocol request/response 410 interface (the user network interface - UNI) between the client and 411 server networks. [RFC4208] shows how this interface may be supported 412 by GMPLS protocols operated between client edge and server edge 413 routers while retaining the routing information within the server 414 network. That is, in the Overlay Model there is no exchange of 415 routing or reachability information between client and server 416 networks, and no network element has visibility into both client and 417 server networks. The Border Peer Model can be viewed as placing the 418 UNI within the Border Router thus giving the Border Router peer 419 capabilities in both the client and server network. 421 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs 423 All three LSP types MAY be supported in the Border Peer Model, but 424 contiguous LSPs are the hardest to support because they require 425 protocol mapping between the MPLS-TE client network and the GMPLS 426 server network. Such protocol mapping can be achieved currently since 427 MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism 428 is not future-proofed. 430 Contiguous and stitched LSPs can only be supported where the GMPLS 431 server network has the same switching type (that is, packet 432 switching) as the MPLS-TE network. Requirements for independent 433 failure recovery within the GMPLS island require the use of loose 434 path reoptimization techniques [RFC4736] and end-to-end make-before- 435 break [RFC3209] which will not provide rapid recovery. 437 For these reasons, the use of hierarchical LSPs across the server 438 network is RECOMMENDED for the Border Peer Model, but see the 439 discussion of Fast Reroute protection in Section 5.3. 441 5.2 MPLS-TE Control Plane Connectivity 443 Control plane connectivity between MPLS-TE LSRs connected by a GMPLS 444 island in the Border Peer Model MAY be provided by the control 445 channels of the GMPLS network. If this is done, a tunneling mechanism 446 (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE 447 information is not consumed by the GMPLS LSRs. But care is required 448 to avoid swamping the control plane of the GMPLS network with MPLS-TE 449 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 451 control plane (particularly routing) messages. 453 In order to ensure scalability, control plane messages for the MPLS- 454 TE client network MAY be carried between Border Routers in a single 455 hop MPLS-TE LSP routed through the data plane of the GMPLS server 456 network. 458 5.3 Fast Reroute Protection 460 If the GMPLS network is packet switching, Fast Reroute protection can 461 be offered on all hops of a contiguous LSP. If the GMPLS network is 462 packet switching then all hops of a hierarchical GMPLS LSP or GMPLS 463 stitching segment can be protected using Fast Reroute. If the end-to- 464 end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet 465 switching network SHOULD provide such protection. 467 However, note that it is not possible to provide FRR node protection 468 of the upstream Border Router without careful consideration of 469 available paths, and protection of the downstream Border Router is 470 not possible where hierarchical LSPs or stitching segments are used. 472 Note further that Fast Reroute is not available in non-packet 473 technologies. However, other protection techniques are supported by 474 GMPLS for non-packet networks and are likely to provide similar 475 levels of protection. 477 The limitations of FRR need careful consideration by the operator and 478 may lead to the decision to provide end-to-end protection for the 479 MPLS-TE LSP. 481 5.4 GMPLS LSP Advertisement 483 In the Border Peer Model, the LSPs established by the Border Routers 484 in the GMPLS server network SHOULD be advertised in the MPLS-TE 485 client network as real or virtual links. In case real links are 486 advertised into the MPLS-TE client network, the Border Routers in the 487 MPLS-TE client network MAY establish IGP neighbors. The Border 488 Routers MAY automatically advertise the GMPLS LSPs when establishing 489 them. 491 5.5 GMPLS Deployment Considerations 493 The Border Peer Model does not require the existing MPLS-TE client 494 network to be GMPLS aware and does not affect on the operation and 495 management of the existing MPLS-TE client network. Only border 496 routers need to be upgraded with the GMPLS functionality. In this 497 fashion, the Border Peer Model renders itself for incremental 498 deployment of the GMPLS server network, without requiring 499 reconfiguration of existing areas/ASes, changing operation of IGP and 500 BGP or software upgrade of the existing MPLS-TE client network. 502 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 504 6. IANA Considerations 506 This requirements document makes no requests for IANA action. 508 7. Acknowledgments 510 The author would like to express thanks to Raymond Zhang, Adrian 511 Farrel, and Deborah Brungard for their helpful and useful comments 512 and feedback. 514 8. References 516 8.1 Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 522 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 523 Tunnels", RFC 3209, December 2001. 525 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 526 (GMPLS) Architecture", RFC3945, October 2004. 528 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 529 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 531 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 532 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 534 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 535 Hierarchy with Generalized Multi-Protocol Label Switching 536 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 538 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 539 Switching (GMPLS) User-Network Interface (UNI): Resource 540 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 541 for the Overlay Model", RFC 4208, October 2005. 543 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 544 with Generalized MPLS Traffic Engineering", draft-ietf- 545 ccamp-lsp-stitching, work in progress. 547 8.2 Informative References 549 [RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation 550 (GRE)", RFC 2784, March 2000. 552 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 553 Element (PCE)-Based Architecture", RFC 4655, August 2006. 555 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 557 [RFC4736] Vasseur, JP., Ikejiri, Y., and Zhang, R., "Reoptimization 558 of Multiprotocol Label Switching (MPLS) Traffic Engineering 559 (TE) loosely routed Label Switch Path (LSP)", RFC4736, 560 November 2006. 562 [MIGRATE] Shiomoto, K., et al., "Framework for MPLS-TE to GMPLS 563 migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, 564 work in progress. 566 [MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 567 M., Brungard, D., "Requirements for GMPLS-based 568 multi-region and multi-layer networks (MRN/MLN)", 569 draft-ietf-ccamp-gmpls-mln-reqs, work in progress. 571 [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework 572 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 573 Engineering," draft-ietf-pce-inter-layer-frwk, work in 574 progress. 576 [SECURITY] Fang, L., "Security Framework for MPLS and GMPLS 577 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 578 framework, work in progress. 580 9. Author's Address 582 Kenji Kumaki 583 KDDI Corporation 584 Garden Air Tower 585 Iidabashi, Chiyoda-ku, 586 Tokyo 102-8460, JAPAN 587 Email: ke-kumaki@kddi.com 589 10. Contributors' Addresses 591 Tomohiro Otani 592 KDDI R&D Laboratories, Inc. 593 2-1-15 Ohara Kamifukuoka 594 Saitama, 356-8502. Japan 595 Phone: +81-49-278-7357 596 Email: otani@kddilabs.jp 598 Shuichi Okamoto 599 NICT JGN II Tsukuba Reserach Center 600 1-8-1, Otemachi Chiyoda-ku, 601 Tokyo, 100-0004, Japan 602 Phone: +81-3-5200-2117 603 Email: okamoto-s@nict.go.jp 604 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 606 Kazuhiro Fujihara 607 NTT Communications Corporation 608 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 609 Tokyo 163-1421, Japan EMail: kazuhiro.fujihara@ntt.com 611 Yuichi Ikejiri 612 NTT Communications Corporation 613 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 614 Tokyo 163-1421, Japan EMail: y.ikejiri@ntt.com 616 11. Full Copyright Statement 618 Copyright (C) The IETF Trust (2008). 620 This document is subject to the rights, licenses and restrictions 621 contained in BCP 78, and except as set forth therein, the authors 622 retain all their rights. 624 This document and the information contained herein are provided on an 625 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 626 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 627 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 628 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 629 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 630 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 632 12. Intellectual Property 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed to 636 pertain to the implementation or use of the technology described in 637 this document or the extent to which any license under such rights 638 might or might not be available; nor does it represent that it has 639 made any independent effort to identify any such rights. Information 640 on the procedures with respect to rights in RFC documents can be 641 found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use of 646 such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository at 648 http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at ietf- 654 ipr@ietf.org.