idnits 2.17.1 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 588. 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 (September 24, 2007) is 6059 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. -------------------------------------------------------------------------------- 2 Network Working Group K. Kumaki, Ed. 3 Internet Draft KDDI Corporation 4 Intended Status: Informational 5 Created: September 24, 2007 6 Expires: March 24, 2008 8 Interworking Requirements to Support operation of MPLS-TE over GMPLS 9 Networks 11 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Operation of an Multiprotocol Label Switching (MPLS) traffic 39 engineering (TE) network as a client network to a Generalized MPLS 40 (GMPLS) network has enhanced operational capabilities compared to 41 those provided by a co-existent protocol model (ships in the night). 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 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 51 This document describes a framework and Service Provider requirements 52 for operating MPLS-TE networks over GMPLS networks. 54 Table of Contents 56 1. Introduction...................................................2 57 1.1 Terminology................................................3 58 2. Reference model................................................4 59 3. Detailed Requirements..........................................4 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.5 64 3.5 Selective Advertisement of MPLS-TE Information via a Border 65 Node...........................................................5 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.......................................6 69 3.9 Scalability Considerations.................................6 70 3.10 Performance Considerations................................7 71 3.11 Management Considerations.................................7 72 4. Security Considerations........................................7 73 5. Recommended Solution Architecture..............................8 74 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs.........8 75 5.2 MPLS-TE Control Plane Connectivity.........................9 76 5.3 Fast Reroute Protection....................................9 77 5.4 GMPLS LSP Advertisement....................................9 78 5.5 GMPLS Deployment Considerations...........................10 79 6. IANA Considerations...........................................10 80 7. Acknowledgments...............................................10 81 8. References....................................................10 82 8.1 Normative References......................................10 83 8.2 Informative References....................................11 84 9. Author's Address..............................................11 85 10. Contributors' Addresses......................................11 86 11. Intellectual Property Statement..............................12 88 1. Introduction 90 Multiprotocol Label Switching traffic engineering (MPLS-TE) networks 91 are often deployed over transport networks such that the transport 92 networks provide connectivity between the Label Switching Routers 93 (LSRs) in the MPLS-TE network. Increasingly, these transport networks 94 are operated using a Generalized Multiprotocol Label Switching 95 (GMPLS) control plane, and label Switched Paths (LSPs) in the GMPLS 96 network provide connectivity as virtual data links advertised as TE 97 links in the MPLS-TE network. 99 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 101 GMPLS protocols were developed as extensions to MPLS-TE protocols. 102 MPLS-TE is limited to the control of packet switching networks, but 103 GMPLS can also control technologies at layers one and two. 105 The GMPLS network may be managed by an operator as a separate network 106 (as it may have been when it was under management plane control 107 before the use of GMPLS as a control plane), but optimizations of 108 management and operation may be achieved by coordinating the use of 109 the MPLS-TE and GMPLS networks and operating the two networks with a 110 close client/server relationship. 112 GMPLS LSP setup may triggered by the signaling of MPLS-TE LSPs in the 113 MPLS-TE network so that the GMPLS network is reactive to the needs of 114 the MPLS-TE network. The triggering process can be under the control 115 of operator policies without needing direct intervention by an 116 operator. 118 The client/server configuration just described can also apply in 119 migration scenarios for MPLS-TE packet switching networks that are 120 being migrated to be under GMPLS control. [MIGRATE] describes a 121 migration scenario called the Island Model. In this scenario, groups 122 of nodes (islands) are migrated from the MPLS-TE protocols to the 123 GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the 124 sea). This scenario can be effectively managed as a client/server 125 network relationship using the framework described in this document. 127 In order to correctly manage the dynamic interaction between the MPLS 128 and GMPLS networks, it is necessary to understand the operational 129 requirements and the control that the operator can impose. Although 130 this problem is very similar to the multi-layer networks described in 131 [MLN], it must be noted that those networks operate GMPLS protocols 132 in both the client and server networks which facilitates smoother 133 interworking. Where the client network uses MPLS-TE protocols over 134 the GMPLS server network there is a need to study the interworking of 135 the two protocol sets. 137 This document examines the protocol requirements for protocol 138 interworking to operate an MPLS-TE network as a client network over a 139 GMPLS server network, and provides a framework for such operations. 141 1.1 Terminology 143 Although this Informational document is not a protocol specification, 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119] for clarity 147 of exposure of the requirements. 149 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 151 2. Reference model 153 The reference model used in this document is shown in Figure 1. It 154 can easily be seen that the interworking between MPLS-TE and GMPLS 155 protocols must occur on a node and not on a link. Nodes on the 156 interface between the MPLS-TE and GMPLS networks must be responsible 157 for handling both protocol sets and for providing any protocol 158 interworking that is required. We call these nodes Border Routers. 160 -------------- ------------------------- -------------- 161 | MPLS Client | | GMPLS Server Network | | MPLS Client | 162 | Network | | | | Network | 163 | | | | | | 164 | ---- --+--+-- ----- ----- --+--+-- ---- | 165 | | | | | | | | | | | | | | 166 | |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS| | 167 | |LSR | | Router | | LSR | | LSR | | Router | |LSR | | 168 | | | | | | | | | | | | | | 169 | ---- --+--+-- ----- ----- --+--+-- ---- | 170 | | | | | | 171 | | | | | | 172 -------------- ------------------------- -------------- 174 | | GMPLS LSP | | 175 | |<------------------------->| | 176 | | 177 |<--------------------------------------------->| 178 End-to-End MPLS-TE LSP 180 Figure 1. Reference model of MPLS-TE/GMPLS interworking 182 MPLS-TE network connectivity is provided through a GMPLS LSP which is 183 created between Border Routers. End-to-end connectivity between MPLS 184 LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP 185 that is carried across the MPLS-TE network by the GMPLS LSP using 186 hierarchical LSP techniques [RFC4206], LSP stitching segments 187 [STITCH], or a contiguous LSP. LSP stitching segments and contiguous 188 LSPs are only available where the GMPLS network is a packet switching 189 network. 191 3. Detailed Requirements 193 This section describes detailed requirements for MPLS-TE/GMPLS 194 interworking in support of the reference model shown in Figure 1. 196 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 198 3.1 End-to-End Signaling 200 The solution MUST be able to preserve MPLS signaling information 201 signaled within the MPLS-TE client network at the start of the MPLS- 202 TE LSP, and deliver it on the other side of the GMPLS server network 203 for use within the MPLS-TE client network at the end of the MPLS-TE 204 LSP. This may require protocol mapping (and re-mapping), protocol 205 tunneling, or the use of remote protocol adjacencies. 207 3.2 Triggered Establishment of GMPLS LSPs 209 The solution MUST provide the ability to establish end-to-end MPLS- 210 TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS 211 LSPs across the core network to be set up between Border Routers 212 triggered by the signaling of MPLS-TE LSPs in the client network, and 213 in this case, policy controls MUST be made available at the border 214 routers so that the operator of the GMPLS network can manage how core 215 network resources are utilized. GMPLS LSPs MAY also be pre- 216 established as the result of management plane control. 218 3.3 Diverse Paths for End-to-End MPLS-TE LSPs 220 The solution SHOULD provide the ability to establish end-to-end MPLS- 221 TE LSPs having diverse paths for protection of the LSP traffic. This 222 means that MPLS-TE LSPs SHOULD be kept diverse both within the client 223 MPLS-TE network and as they cross the server GMPLS network. This 224 means that there SHOULD be a mechanism to request the provision of 225 diverse GMPLS LSPs between a pair of Border Routers to provide 226 protection of the GMPLS span, but also that there SHOULD be a way to 227 keep GMPLS LSPs between different Border Routers disjoint. 229 3.4 Advertisement of MPLS-TE Information via the GMPLS Network 231 The solution SHOULD provide the ability to exchange advertisements of 232 TE information between MPLS-TE client networks across the GMPLS 233 server network. 235 The advertisement of TE information from within an MPLS-TE client 236 network to all LSRs in the client network enables a head end LSR to 237 compute an optimal path for an LSP to a tail end LSR that is reached 238 over the GMPLS server network. 240 Where there is more than one client MPLS-TE network, the TE 241 information from separate MPLS-TE networks MUST be kept private, 242 confidential and secure. 244 3.5 Selective Advertisement of MPLS-TE Information via a Border Node 245 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 247 The solution SHOULD provide the ability to distribute TE reachability 248 information from the GMPLS server network to MPLS-TE networks 249 selectively. This information is useful for the LSRs in the MPLS-TE 250 networks to compute paths that cross the GMPLS server network and to 251 select the correct Border Routers to provide connectivity. 253 The solution MUST NOT distribute TE information from within a non-PSC 254 GMPLS server network to any client MPLS-TE network as that 255 information may cause confusion and selection of inappropriate paths. 257 3.6 Interworking of MPLS-TE and GMPLS Protection 259 If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR) 260 [RFC4090], then similar protection MUST be provided over the GMPLS 261 island. Operator and policy controls SHOULD be made available at the 262 Border Router to determine how suitable protection is provided in the 263 GMPLS island. 265 3.7 Independent Failure Recovery and Reoptimization 267 The solution SHOULD provide failure recovery and reoptimization in 268 the GMPLS server network without impacting the MPLS-TE client network 269 and vice versa. That is, it SHOULD be possible to recover from a 270 fault within the GMPLS island or to reoptimize the path across the 271 GMPLS island without requiring signaling activity within the MPLS-TE 272 client network. Similarly, it SHOULD be possible to perform recovery 273 or reoptimization within the MPLS-TE client network without requiring 274 signaling activity within the GMPLS server networks. 276 If a failure in the GMPLS server network can not be repaired 277 transparently, some kind of notification of the failure SHOULD be 278 transmitted to MPLS-TE network. 280 3.8 Complexity and Risks 282 The solution SHOULD NOT introduce unnecessary complexity to the 283 current operating network to such a degree that it would affect the 284 stability and diminish the benefits of deploying such a solution in 285 service provider networks. 287 3.9 Scalability Considerations 289 The solution MUST scale well with consideration to at least the 290 following metrics. 292 - The number of GMPLS-capable nodes (i.e., the size of the GMPLS 293 server network). 294 - The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE 295 client network). 297 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 299 - The number of MPLS-TE client networks. 300 - The number of GMPLS LSPs. 301 - The number of MPLS-TE LSPs. 303 3.10 Performance Considerations 305 The solution SHOULD be evaluated with regard to the following 306 criteria. 308 - Failure and restoration time. 309 - Impact and scalability of the control plane due to added 310 overheads. 311 - Impact and scalability of the data/forwarding plane due to added 312 overheads. 314 3.11 Management Considerations 316 Manageability of the deployment of an MPLS-TE client network over 317 GMPLS server network MUST addresses the following considerations. 319 - Need for coordination of MIB modules used for control plane 320 management and monitoring in the client and server networks. 321 - Need for diagnostic tools that can discover and isolate faults 322 across the border between the MPLS-TE client and GMPLS server 323 networks. 325 4. Security Considerations 327 Security issues for this model relate to control and data planes, and 328 to authentication at border routers. Actually, border routers are 329 administrative boundaries. Therefore, if the MPLS-TE client network 330 and GMPLS server network are in completely different administrations, 331 some functions for limiting control and data packet exchanges at the 332 domain boundary are required. 334 Authentication mechanisms to separate operators in the MPLS-TE client 335 network from operators in the GMPLS server network are also required 336 in the border routers. In this case, operators in the MPLS-TE client 337 network MUST NOT be allowed to configure the GMPLS server network, 338 and vice versa. But, in some cases, both types of operator MAY check 339 the state of both networks. 341 On the other hand, if the MPLS-TE client and GMPLS server network are 342 part of the same administration, functions for limiting control and 343 data packet exchange are not required. Also, authentication 344 mechanisms to separate operators in the MPLS-TE client network from 345 operators in the GMPLS server network in border routers are not 346 required. But, in some cases, loose restriction at command and 347 configuration levels MAY exist between operators in the MPLS-TE 348 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 350 client network and operators in the GMPLS server network. 352 5. Recommended Solution Architecture 354 The recommended solution architecture to meet the requirements set 355 out in Section 3 is known as the Border Peer Model. This architecture 356 is a variant of the Augmented Model described in [RFC3945]. The 357 remainder of this document presents an overview of this architecture. 359 In the Augmented Model, routing information from the lower layer 360 (server) network is filtered at the interface to the higher layer 361 (client) network and a subset of the information is distributed 362 within the higher layer network. 364 In the Border Peer Model, the interface between the client and server 365 networks is the Border Router. This router has visibility of the 366 routing information in the server network yet also participates as a 367 peer in the client network. Thus the Border Router has full 368 visibility into both networks. However, the Border Router does not 369 distribute server routing information into the client network, nor 370 does it distribute client routing information into the server 371 network. 373 The Border Peer Model may also be contrasted with the Overlay Model 374 [RFC3945]. In this model there is a protocol request/response 375 interface (the user network interface - UNI) between the client and 376 server networks. [RFC4208] shows how this interface may be supported 377 by GMPLS protocols operated between client edge and server edge 378 routers while retaining the routing information within the server 379 network. That is, in the Overlay Model there is no exchange of 380 routing or reachability information between client and server 381 networks, and no network element has visibility into both client and 382 server networks. The Border Peer Model can be viewed as placing the 383 UNI within the Border Router thus giving the Border Router peer 384 capabilities in both the client and server network. 386 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs 388 All three LSP types MAY be supported in the Border Peer Model, but 389 contiguous LSPs are the hardest to support because they require 390 protocol mapping between the MPLS-TE client network and the GMPLS 391 server network. Such protocol mapping can be achieved currently since 392 MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism 393 is not future-proofed. 395 Contiguous and stitched LSPs can only be supported where the GMPLS 396 server network has the same switching type (that is, packet 397 switching) as the MPLS-TE network. Requirements for independent 398 failure recovery within the GMPLS island require the use of loose 399 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 401 path reoptimization techniques [RFC4736] and end-to-end make-before- 402 break [RFC3209] which will not provide rapid recovery. 404 For these reasons, the use of hierarchical LSPs across the server 405 network is RECOMMENDED for the Border Peer Model, but see the 406 discussion of Fast Reroute protection in Section 5.3. 408 5.2 MPLS-TE Control Plane Connectivity 410 Control plane connectivity between MPLS-TE LSRs connected by a GMPLS 411 island in the Border Peer Model MAY be provided by the control 412 channels of the GMPLS network. If this is done, a tunneling mechanism 413 (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE 414 information is not consumed by the GMPLS LSRs. But care is required 415 to avoid swamping the control plane of the GMPLS network with MPLS-TE 416 control plane (particularly routing) messages. 418 In order to ensure scalability, control plane messages for the MPLS- 419 TE client network MAY be carried between Border Routers in a single 420 hop MPLS-TE LSP routed through the data plane of the GMPLS server 421 network. 423 5.3 Fast Reroute Protection 425 If the GMPLS network is packet switching, Fast Reroute protection can 426 be offered on all hops of a contiguous LSP. If the GMPLS network is 427 packet switching then all hops of a hierarchical GMPLS LSP or GMPLS 428 stitching segment can be protected using Fast Reroute. If the end-to- 429 end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet 430 switching network SHOULD provide such protection. 432 However, note that it is not possible to provide FRR node protection 433 of the upstream Border Router without careful consideration of 434 available paths, and protection of the downstream Border Router is 435 not possible where hierarchical LSPs or stitching segments are used. 437 Note further that Fast Reroute is not available in non-packet 438 technologies. However, other protection techniques are supported by 439 GMPLS for non-packet networks and are likely to provide similar 440 levels of protection. 442 The limitations of FRR need careful consideration by the operator and 443 may lead to the decision to provide end-to-end protection for the 444 MPLS-TE LSP. 446 5.4 GMPLS LSP Advertisement 448 In the Border Peer Model, the LSPs established by the Border Routers 449 in the GMPLS server network SHOULD be advertised in the MPLS-TE 450 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 452 client network as real or virtual links. In case real links are 453 advertised into the MPLS-TE client network, the Border Routers in the 454 MPLS-TE client network MAY establish IGP neighbors. The Border 455 Routers MAY automatically advertise the GMPLS LSPs when establishing 456 them. 458 5.5 GMPLS Deployment Considerations 460 The Border Peer Model does not require the existing MPLS-TE client 461 network to be GMPLS aware and does not affect on the operation and 462 management of the existing MPLS-TE client network. Only border 463 routers need to be upgraded with the GMPLS functionality. In this 464 fashion, the Border Peer Model renders itself for incremental 465 deployment of the GMPLS server network, without requiring 466 reconfiguration of existing areas/ASes, changing operation of IGP and 467 BGP or software upgrade of the existing MPLS-TE client network. 469 6. IANA Considerations 471 This requirements document makes no requests for IANA action. 473 [RFC Editor: please remove this section before publication.] 475 7. Acknowledgments 477 The author would like to express thanks to Raymond Zhang, Adrian 478 Farrel, and Deborah Brungard for their helpful and useful comments 479 and feedback. 481 8. References 483 8.1 Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 489 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 490 Tunnels", RFC 3209, December 2001. 492 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 493 (GMPLS) Architecture", RFC3945, October 2004. 495 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 496 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 498 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 499 Hierarchy with Generalized Multi-Protocol Label Switching 500 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 502 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 504 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 505 Switching (GMPLS) User-Network Interface (UNI): Resource 506 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 507 for the Overlay Model", RFC 4208, October 2005. 509 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 510 with Generalized MPLS Traffic Engineering", draft-ietf- 511 ccamp-lsp-stitching, work in progress. 513 8.2 Informative References 515 [RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation 516 (GRE)", RFC 2784, March 2000. 518 [RFC4736] Vasseur, JP., Ikejiri, Y., and Zhang, R., "Reoptimization 519 of Multiprotocol Label Switching (MPLS) Traffic Engineering 520 (TE) loosely routed Label Switch Path (LSP)", RFC4736, 521 November 2006. 523 [MIGRATE] Shiomoto, K., et al., "Framework for MPLS-TE to GMPLS 524 migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, 525 work in progress. 527 [MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 528 M., Brungard, D., "Requirements for GMPLS-based multi- 529 region and multi-layer networks (MRN/MLN)", draft-ietf- 530 ccamp-gmpls-mln-reqs, work in progress. 532 9. Author's Address 534 Kenji Kumaki 535 KDDI Corporation 536 Garden Air Tower 537 Iidabashi, Chiyoda-ku, 538 Tokyo 102-8460, JAPAN 539 Email: ke-kumaki@kddi.com 541 10. Contributors' Addresses 543 Tomohiro Otani 544 KDDI R&D Laboratories, Inc. 545 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 546 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 548 Shuichi Okamoto 549 NICT JGN II Tsukuba Reserach Center 550 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117 551 Tokyo, 100-0004, Japan E-mail :okamoto-s@nict.go.jp 552 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 554 Kazuhiro Fujihara 555 NTT Communications Corporation 556 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 557 Tokyo 163-1421, Japan 558 EMail: kazuhiro.fujihara@ntt.com 560 Yuichi Ikejiri 561 NTT Communications Corporation 562 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 563 Tokyo 163-1421, Japan 564 EMail: y.ikejiri@ntt.com 566 11. Intellectual Property Statement 568 The IETF takes no position regarding the validity or scope of any 569 Intellectual Property Rights or other rights that might be claimed to 570 pertain to the implementation or use of the technology described in 571 this document or the extent to which any license under such rights 572 might or might not be available; nor does it represent that it has 573 made any independent effort to identify any such rights. Information 574 on the procedures with respect to rights in RFC documents can be 575 found in BCP 78 and BCP 79. 577 Copies of IPR disclosures made to the IETF Secretariat and any 578 assurances of licenses to be made available, or the result of an 579 attempt made to obtain a general license or permission for the use of 580 such proprietary rights by implementers or users of this 581 specification can be obtained from the IETF on-line IPR repository at 582 http://www.ietf.org/ipr. 584 The IETF invites any interested party to bring to its attention any 585 copyrights, patents or patent applications, or other proprietary 586 rights that may cover technology that may be required to implement 587 this standard. Please address the information to the IETF at ietf- 588 ipr@ietf.org. 590 Disclaimer of Validity 592 This document and the information contained herein are provided on 593 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 594 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 595 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 596 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 597 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 598 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 599 PARTICULAR PURPOSE. 601 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 603 Copyright Statement 605 Copyright (C) The IETF Trust (2007). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights.