idnits 2.17.1 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** 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. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 2006) is 6635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3031' is mentioned on line 154, but not defined Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Kenji Kumaki 4 Category: Informational KDDI Corporation 5 Expires: August 2006 Tomohiro Otani 6 KDDI R&D Labs 7 Shuichi Okamoto 8 NICT 9 Kazuhiro Fujihara 10 Yuichi Ikejiri 11 NTT 12 Communications 13 February 2006 15 Requirements for IP/MPLS-GMPLS interworking in support of GMPLS 16 deployment 18 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-00.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 47 deployment February 2006 49 This document describes Service Provider requirements for IP/MPLS- 50 GMPLS interworking in support of GMPLS deployment. 52 The main objective is to present a set of requirements and scenarios 53 which result in general guidelines for the definition, selection and 54 specification of a technical solution addressing these requirements 55 and supporting the scenarios. Specification for this solution itself 56 is out of scope in this document. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Terminology....................................................4 68 3. Problem Statement..............................................4 69 4. Reference model................................................5 70 5. Application Scenario...........................................5 71 5.1 Overlay model..............................................6 72 5.2 Integrated model...........................................6 73 5.3 Augmented model............................................6 74 6. Detailed Requirements..........................................7 75 6.1 Software Upgrade Requirement...............................8 76 6.2 Use of GMPLS network resources in IP/MPLS networks.........8 77 6.3 Routing adjacency for IP/MPLS networks over GMPLS networks.8 78 6.4 Mapping routing information between IP/MPLS and GMPLS......8 79 6.5 Mapping signaling information between MPLS and GMPLS.......9 80 6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs 81 signaling......................................................9 82 6.7 Establishment of end-to-end MPLS LSPs having diverse paths 83 over GMPLS network.............................................9 84 6.8 Advertisement of TE / IP reachability information via GMPLS 85 domain.........................................................9 86 6.9 Selective advertisement of TE/IP reachability information via 87 a border node..................................................9 88 6.10 Interworking of MPLS and GMPLS protection................10 89 6.11 Separation of IP/MPLS domain and GMPLS domain............10 90 6.12 Failure recovery.........................................10 91 6.13 Complexity and Risks.....................................10 92 6.14 Scalability consideration................................10 93 6.15 Performance consideration................................11 94 6.16 Management consideration.................................11 95 7. Security Considerations.......................................11 96 deployment February 2006 98 8. IANA Considerations...........................................12 99 9. Normative References..........................................12 100 10. Informative References.......................................12 101 11. Acknowledgments..............................................12 102 12. Author's Addresses...........................................12 103 13. Intellectual Property Statement..............................13 105 1. Introduction 107 Recently, the deployment of a GMPLS network is planned or under 108 investigation among many service providers and some of very advanced 109 research networks have been already operated based on GMPLS 110 technology. GMPLS is developed as an extension of MPLS in order to 111 mainly control a transport network consisting of TDM cross-connect, 112 optical/lambda switches, and fibers. By introducing GMPLS technology, 113 some service providers expect that IP/MPLS network connectivity is 114 effectively and reliably established over the GMPLS network. If MPLS 115 and GMPLS protocols can interwork with each other, the introduction 116 of GMPLS would be more beneficial for service providers, because this 117 is expected to improve the resource utilization, network resiliency 118 and manageability all over the network, less impacting the existing 119 IP/MPLS networks. 121 On the other hand, GMPLS protocols additionally define the packet 122 switch capable mechanism, although existing MPLS networks already 123 achieve the almost same functionalities and are being well-operated. 124 Some service providers are considering to gradually replace all the 125 IP/MPLS routers with GMPLS routers or upgrade the software so as to 126 support GMPLS in conjunction with the introduction of GMPLS 127 controlled optical networks. 129 In both cases, there is no clear definition and standardization work 130 so far to interwork between IP/MPLS routers as well as GMPLS routers, 131 i.e. IP/MPLS networks and GMPLS networks. In order to accelerate the 132 deployment of GMPLS technology, MPLS/GMPLS interworking is a key to 133 gain more benefit than without any interworking. 135 These types of network architecture to investigated, however, are 136 much varied among service providers, and as a result, the 137 requirements in support of those may be different from each other. 138 In order to create the definition of MPLS/GMPLS interworking 139 technology, the concrete requirement is preferably defined from the 140 point of operational experience of MPLS/GMPLS networks and future 141 view on these technologies by collecting the input and requirements 142 from various service providers. 144 deployment February 2006 146 Considering such environment, this document focuses on the 147 requirement of IP/MPLS-GMPLS interworking especially in support of 148 GMPLS deployment. 150 2. Terminology 152 IP/MPLS network: Service Provider Network where MPLS switching 153 capabilities and signaling control (e.g., ones 154 described in [RFC3031]) are activated in addition 155 to IP routing protocols. 157 LSP: Label Switched Path 159 PSC: Packet Switch Capable 161 LSC: Lambda Switch Capable 163 FA-LSP: Forwarding Adjacency Label Switched Path 165 Head-end LSR: ingress LSR 167 Tail-end LSR: egress LSR 169 LSR: Label Switched Router 171 MPLS LSP: Multi Protocol Label Switching LSP 173 3. Problem Statement 175 GMPLS technology is deployed or will be deployed in various forms to 176 provide a highly efficient transport for existing IP/MPLS network, 177 depending on the deployment model of each service provider. Some 178 service providers may allow the hybrid architecture of IP/MPLS and 179 GMPLS so that the introduction of GMPLS technology has less impact on 180 an existing IP/MPLS network with regard to routing instance, 181 addressing and the running software. On the other hand, some service 182 providers may need to control almost all devices by a single control 183 plane of GMPLS, which may require the running software upgrade. 184 In order to operate such a hybrid network appropriately and 185 effectively, clear definition should be formulated so as to cover 186 each service provider's strategy. 188 In terms of MPLS/GMPLS signaling, although the created GMPLS LSP over 189 optical networks will be utilized by the IP/MPLS network, the clear 190 mechanism of how to use it has not yet been defined. On the other 191 hand, if the routing mechanism is considered, the method to transport 192 routing information has not yet been also defined between IP/MPLS 193 deployment February 2006 195 networks and GMPLS networks. Feature richness of MPLS and GMPLS 196 technology allows service providers to use a set of options on how 197 GMPLS services can be used by IP/MPLS networks. In this document, 198 the requirement for IP/MPLS-GMPLS interworking is presented with some 199 operations considerations associated with use of GMPLS services by 200 IP/MPLS networks. 202 Note that an IP/MPLS-GMPLS interworking to deploy GMPLS technology is 203 not only tentatively required for a migration from MPLS RSVP-TE to 204 GMPLS RSVP-TE but also permanently required for the use of LDP and 205 IGP (e.g. OSPF and IS-IS) instead of MPLS RSVP-TE in IP/MPLS networks. 207 4. Reference model 209 The reference model used in this document is shown in Figure 1. As 210 indicated in [RFC3945], the optical transport network consists of, 211 for example, GMPLS controlled OXCs and GMPLS-enabled IP/MPLS routers. 213 | | | | 214 |IP/MPLS network |------------------------------|IP/MPLS network | 215 | | | | 216 | Optical Transport | 217 | (GMPLS) Network | 218 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 219 | | | | | | | | | | | | 220 | IP/MPLS +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ IP/MPLS | 221 | Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service | 222 | Network +--+ router | | +--+ | | router +--+ Network | 223 | | | | | | | | | | | | 224 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 226 Figure 1. Reference model of MPLS/GMPLS interworking 228 IP/MPLS network connectivity is provided through GMPLS LSP which is 229 created between GMPLS routers. In this document, the requirement how 230 the IP/MPLS network and the GMPLS network are interworked is 231 described in order to effectively operate the entire network and 232 smoothly deployed the GMPLS network. 234 5. Application Scenario 236 This section describes three different scenarios to deploy GMPLS 237 technology. 238 From the deployment point of view, GMPLS architecture document lists 239 [RFC3945] three different scenarios in which GMPLS technology can be 240 deployment February 2006 242 deployed: overlay, integrated and augmented. 244 The key difference among these models is how much and what kind of 245 network information can be shared between packet (e.g. PSC) and 246 optical (e.g. LSC) domains. 248 In this section, in case that GMPLS technology is deployed in 249 existing IP/MPLS networks, pros and cons of each model are discussed. 251 5.1 Overlay model 253 In overlay model, all the devices in optical domains have no 254 visibility into others topology and/or routing information such as 255 packet network (e.g. IP/MPLS service network) and vice versa. 256 But IP/MPLS domain and optical domain can interact with signaling 257 operation. 258 Overlay model is suitable for such scenario, however it does not 259 offer the benefits of integrated model approach for efficient 260 resource utilization, optimal routing, and protection and restoration 261 between IP/MPLS and optical networks. 262 Note that some service providers need a way to make effective use 263 of GMPLS network resources (e.g. bandwidth, protection and recovery) 264 for the IP/MPLS service networks. 266 5.2 Integrated model 268 In integrated model, since all the devices in optical domains and 269 IP/MPLS domains share the same topology and routing information with 270 the same IGP instance, it requires all the devices within peer model 271 to be MPLS/GMPLS aware. 272 This model is also suitable, where optical transport and IP/MPLS 273 service networks are operated by a single entity. 274 Currently, many service providers have traditionally built their 275 networks, where optical transport and IP/MPLS service networks belong 276 to different operation, management and ownership. The most important 277 thing is that service providers want to operate and manage their 278 networks independently, and deploy them without changing existing 279 IP/MPLS network topologies, protocols and scalability. 280 But in this model, in case that a lot of devices exist in a network, 281 there are scalability issues. Note that most of real service 282 providers have thousands or tens of thousands of devices in real 283 networks. 285 5.3 Augmented model 287 Augmented model is suitable in the scenario, where optical transport 288 and IP/MPLS service networks are administrated by different entities 289 and the service provider would like to maintain a separation between 290 deployment February 2006 292 IP/MPLS and Optical layers while getting the benefits of integrated 293 model approach. 294 In augmented model, as shown in figure 2, devices within optical 295 domains have no visibility into others topology and/or routing 296 information, except the border nodes. This will help augmented model 297 to accommodate both MPLS based or non-MPLS based service networks 298 connected to border nodes, as long as the border node in augmented 299 model can support GMPLS control plane. Only the border node can share 300 optical domains and IP/MPLS domains. Once IP/MPLS nodes signal to 301 border nodes, the border nodes make effective use of GMPLS network 302 resources (e.g. bandwidth, protection and recovery) for the IP/MPLS 303 service networks. 304 Note that an IP/MPLS routing instance and GMPLS routing instance have 305 different routing instances at a border node. 306 One of the main advantages of the augmented model in the context of 307 GMPLS deployment is that it does not require existing IP/MPLS 308 networks to be GMPLS aware. Only border nodes need to be upgraded 309 with the GMPLS functionality. In this fashion, the augmented model 310 renders itself for incremental deployment of the optical regions, 311 without requiring reconfiguration of existing areas/ASes, changing 312 operation of IGP and EGP or software upgrade of the existing IP/MPLS 313 service networks. 314 Furthermore, to deploy GMPLS technology without changing the existing 315 IP/MPLS networks as much as possible is desirable by simply 316 establishing a routing adjacency at IP/MPLS instance between border 317 nodes. 319 | | | | 320 |IP/MPLS network |------------------------------|IP/MPLS network | 321 | | | | 322 | Optical Transport | 323 | (GMPLS) Network | 324 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 325 | | | | | | | | | | | | 326 | IP/MPLS +--+ Border +--+ +--+ +--+ Border +--+ IP/MPLS | 327 | Service | | node | | OXC1 | | OXC2 | | node | | Service | 328 | Network +--+ | | +--+ | | +--+ Network | 329 | | | | | | | | | | | | 330 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 332 Figure 2. Augmented Model 334 6. Detailed Requirements 336 This section describes detailed requirements for IP/MPLS-GMPLS 337 interworking in support of GMPLS deployment. 339 deployment February 2006 341 6.1 Software Upgrade Requirement 343 The solution SHOULD provide the way not to upgrade all IP/MPLS 344 routers to GMPLS capable routers. 345 Generally speaking, it is not practical to upgrade all IP/MPLS 346 routers to GMPLS capable routers in real service provider networks 347 due to a number of reasons. Especially, in case of accommodating 348 enterprise customers, it is difficult for service providers to 349 upgrade from IP/MPLS capable routers to GMPLS capable routers. 350 This means that some routers would not be upgraded to support GMPLS 351 and some routers would support it in the IP/MPLS production networks. 353 6.2 Use of GMPLS network resources in IP/MPLS networks 355 The solution SHOULD provide the ability to make effective use of 356 GMPLS network resources (e.g. bandwidth, protection & recovery) by 357 the IP/MPLS service networks. 358 Most of service providers have different networks for various 359 services; their GMPLS deployment plans are to have these service 360 networks use a common GMPLS controlled optical network as a core 361 network of various services. 363 6.3 Routing adjacency for IP/MPLS networks over GMPLS networks 365 The solution SHOULD provide the ability to establish a routing 366 adjacency at IP/MPLS instance between border nodes. 367 Most of service providers expect to deploy GMPLS technology without 368 changing the existing IP/MPLS networks as much as possible. In case 369 that GMPLS technology is deployed at a border node, the routing 370 adjacency at IP/MPLS instance between the border nodes is required. 371 Note that the routing adjacency is not established between IP/MPLS 372 routers in case of using FA-LSPs. 374 6.4 Mapping routing information between IP/MPLS and GMPLS 376 The solution SHOULD provide the ability to map routing information 377 between IP/MPLS and GMPLS. From an IP/MPLS routing domain point of 378 view, the routers in the IP/MPLS domain should be able to see a GMPLS 379 LSP as a link or TE link. Furthermore, they should be able to choose 380 an appropriate GMPLS LSP in GMPLS optical domain as a link or TE link. 381 In this case, routers in the IP/MPLS domain can choose a link or TE 382 link based on some policy such as optimality, diversity, protected or 383 QoS inferred. It would enable an IP/MPLS network operating LDP/IGP 384 (e.g. OSPF and IS-IS) as well as RSVP-TE to use GMPLS as an effective 385 transport network. 387 deployment February 2006 389 6.5 Mapping signaling information between MPLS and GMPLS 391 The solution SHOULD provide the ability to map signaling information 392 between MPLS and GMPLS. From an IP/MPLS signaling domain point of 393 view, the routers in IP/MPLS domain should be able to signal over 394 GMPLS optical domain. In this case, an interworking between MPLS and 395 GMPLS protocol is needed. Note that it is supposed that MPLS 396 signaling here is RSVP based signaling. 398 6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs 399 signaling 401 The solution SHOULD provide the ability to establish end-to-end MPLS 402 LSPs over GMPLS network regardless of existence of FA-LSPs in GMPLS 403 network. When there are no FA-LSPs in it, they should be set up 404 triggered by the signaling of MPLS LSP. 406 6.7 Establishment of end-to-end MPLS LSPs having diverse paths over 407 GMPLS network 409 The solution SHOULD provide the ability to establish end-to-end 410 LSPs having diverse paths including diverse GMPLS FA-LSPs 411 corresponding to the request of the head-end MPLS LSR for protection 412 of MPLS LSPs. The GMPLS network SHOULD assure the diversity of GMPLS 413 FA-LSPs, even if their ingress nodes in GMPLS network are different. 415 6.8 Advertisement of TE / IP reachability information via GMPLS domain 417 The solution SHOULD provide the ability to control advertisements of 418 TE information and/or IP reachability information of IP/MPLS service 419 networks via GMPLS network regardless of existence of FA-LSPs. 420 The TE / IP reachability information within the same MPLS service 421 networks should be exchanged in order for a head end LSR of the MPLS 422 network to compute an LSP to a tail end LSR over the GMPLS network. 423 On the other hand, the TE / IP reachabality information SHOULD NOT be 424 advertised to the other IP/MPLS service networks in order to avoid 425 establishing undesirable connections. 427 6.9 Selective advertisement of TE/IP reachability information via a 428 border node 430 The solution SHOULD provide the ability to distribute TE/IP 431 reachability information 432 from the GMPLS network to IP/MPLS networks selectively, which are 433 useful for the head-end MPLS routers to compute MPLS LSPs. 435 deployment February 2006 437 6.10 Interworking of MPLS and GMPLS protection 439 The solution SHOULD provide the ability to select GMPLS protection 440 type with the option by protected MPLS LSPs. 441 If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR 442 protected packet LSP is signaled, we should be able to select 443 protected FA-LSPs from GMPLS network. In terms of MPLS protection, 444 MPLS path message can include some flags in FAST REROUTE object 445 and SESSION_ATTRIBUTE object. 446 In terms of GMPLS protection, there are both signaling aspects 447 [RFC3471] [RFC3473] and routing aspects [RFC4202]. 449 6.11 Separation of IP/MPLS domain and GMPLS domain 451 The solution SHOULD provide the ability to separate IP/MPLS domain 452 and GMPLS domain. 453 Most of service providers have had different networks for every 454 service, where optical networks and IP/MPLS networks belong to 455 different operation, management and ownership. The most important 456 thing is that service providers want to operate and manage their 457 networks independently, and deploy them without changing existing 458 IP/MPLS network topologies and protocols and without affecting 459 scalability. 461 6.12 Failure recovery 463 The solution SHOULD provide failure recovery in optical domain 464 without impacting IP/MPLS domain and vice versa. 465 Failure in optical routing domain SHOULD NOT affect services in 466 IP/MPLS routing domain and failure can be restored/repaired in 467 optical domain without impacting IP/MPLS domain and vice versa. 468 But in case that failure in optical domain associates with IP/MPLS 469 domain, some kind of notification of the failure may be transmitted 470 to IP/MPLS domain and vice versa. 472 6.13 Complexity and Risks 474 The solution SHOULD NOT introduce unnecessary complexity to the 475 current operating network to such a degree that it would affect the 476 stability and diminish the benefits of deploying such a solution over 477 service provider networks. 479 6.14 Scalability consideration 481 The solution MUST have a minimum impact on network scalability for 482 deploying GMPLS technology in the existing IP/MPLS networks. 483 Scalability of GMPLS deployment in the existing IP/MPLS networks MUST 484 address the following consideration. 486 deployment February 2006 488 - the number of GMPLS capable node (e.g. the number of non-PSC GMPLS 489 capable node) 490 - the number of MPLS capable node 491 - the number of IP capable node 492 - the number of OSPF capable node 493 - the number of OSPF non-backbone area 494 - the number of BGP capable node 496 6.15 Performance consideration 498 The solution SHOULD be evaluated with regard to the following 499 criteria. 501 - the number of routing instance 502 - Failure and restoration time 503 - Impact and scalability of the control plane due to added 504 overheads and so on 505 - Impact and scalability of the data/forwarding plane due to added 506 overheads and so on 508 6.16 Management consideration 510 Manageability of GMPLS deployment in the existing IP/MPLS networks 511 MUST addresses the following consideration for section 6. 513 - need for a MIB module for control plane and monitoring 514 - need for diagnostic tools 516 Basically MIB module should be implemented per routing instance. 518 Today, diagnostic tools can detect failures of control plane and data 519 plane for general MPLS TE LSPs [LSP-PING]. 520 The diagnostic tools must detect failures of control and data plane 521 for general GMPLS TE LSPs. 522 Especially, in case that an interworking between MPLS and GMPLS 523 protocol is done, a failure between them MUST be detected. 525 Furthermore, many service providers have traditionally built their 526 networks, where optical transport and IP/MPLS service networks belong 527 to different operation, management and ownership. The most important 528 thing is that service providers want to operate and manage their 529 networks independently. 531 7. Security Considerations 533 Many service providers have traditionally built their networks, where 534 optical transport and IP/MPLS service networks belong to different 535 deployment February 2006 537 operation, management and ownership. The most important thing is that 538 service providers want to operate and manage their networks 539 independently. In that sense, operators SHOULD limit to access their 540 service nodes. Especially, in case that a border node is deployed, 541 operators SHOULD limit to access a specific instance. Furthermore, 542 operators SHOULD limit to be able to issue some commands. 544 8. IANA Considerations 546 This requirement document makes no requests for IANA action. 548 9. Normative References 550 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 551 (GMPLS) Architecture", RFC3945, October 2004. 553 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 554 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 556 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 557 (GMPLS) Signaling Functional Description", RFC3471, January 558 2003. 560 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 561 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 562 Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. 564 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support 565 of Generalized Multi-Protocol Label Switching (GMPLS)", 566 RFC4202, October 2005. 568 10.Informative References 570 [LSP-PING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane 571 Failures", Work in Progress, January 2006. 573 11.Acknowledgments 575 The author would like to express the thanks to Raymond Zhang for his 576 helpful and useful comments and feedbacks. 578 12.Author's Addresses 580 Kenji Kumaki 581 KDDI Corporation 582 Garden Air Tower 583 Iidabashi, Chiyoda-ku, 584 Tokyo 102-8460, JAPAN 585 deployment February 2006 587 Email: ke-kumaki@kddi.com 589 Tomohiro Otani 590 KDDI R&D Laboratories, Inc. 591 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 592 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 594 Shuichi Okamoto 595 NICT JGN II Tsukuba Reserach Center 596 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117 597 Tokyo, 100-0004, Japan E-mail :okamot-s@nict.go.jp 599 Kazuhiro Fujihara 600 NTT Communications Corporation 601 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 602 Tokyo 163-1421, Japan 603 EMail: kazuhiro.fujihara@ntt.com 605 Yuichi Ikejiri 606 NTT Communications Corporation 607 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 608 Tokyo 163-1421, Japan 609 EMail: y.ikejiri@ntt.com 611 13.Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed 615 to pertain to the implementation or use of the technology described 616 in this document or the extent to which any license under such 617 rights might or might not be available; nor does it represent that 618 it has made any independent effort to identify any such rights. 619 Information on the procedures with respect to rights in RFC 620 documents can be found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use 625 of such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository 627 at http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 deployment February 2006 637 Disclaimer of Validity 639 This document and the information contained herein are provided on 640 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 641 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 642 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 643 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Copyright Statement 649 Copyright (C) The Internet Society (2006). This document is subject 650 to the rights, licenses and restrictions contained in BCP 78, and 651 except as set forth therein, the authors retain all their rights. 653 Acknowledgement 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society.