idnits 2.17.1 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. ** 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 2 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 (June 26, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 325, but no explicit reference was found in the text 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: December 27, 2006 Tomohiro Otani 6 KDDI R&D Labs 7 Shuichi Okamoto 8 NICT 9 Kazuhiro Fujihara 10 Yuichi Ikejiri 11 NTT 12 Communications 13 June 26, 2006 15 Requirements for MPLS-TE/GMPLS interworking 17 draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 27, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 This document describes Service Provider requirements for MPLS- 49 TE/GMPLS interworking. 51 The main objective is to allow the operation of an MPLS-TE network as 52 a client network over a GMPLS network. The GMPLS network may be a 53 packet or non-packet network. 55 Specification of solutions is out of scope for this document. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119. 63 Table of Contents 65 1. Introduction...................................................2 66 2. Terminology....................................................3 67 3. Problem Statement..............................................3 68 4. Reference model................................................4 69 5. Detailed Requirements..........................................4 70 5.1 Use of GMPLS optical network resources in MPLS-TE networks.5 71 5.2 Mapping signaling information between MPLS-TE and GMPLS....5 72 5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE 73 LSPs signaling.................................................5 74 5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths 75 over GMPLS optical network.....................................5 76 5.5 Advertisement of TE information via GMPLS optical domain...5 77 5.6 Selective advertisement of TE information via a border node6 78 5.7 Interworking of MPLS-TE and GMPLS protection...............6 79 5.8 Failure recovery...........................................6 80 5.9 Complexity and Risks.......................................6 81 5.10 Scalability consideration.................................6 82 5.11 Performance consideration.................................7 83 5.12 Management consideration..................................7 84 6. Security Considerations........................................7 85 7. IANA Considerations............................................7 86 8. Normative References...........................................7 87 9 .Acknowledgments................................................8 88 10.Author's Addresses.............................................8 89 11.Intellectual Property Statement................................8 91 1. Introduction 93 Recently, the deployment of a GMPLS network is planned or under 94 investigation among many service providers, and some of very advanced 95 research networks have already been operated based on GMPLS 96 technology. GMPLS is developed as an extension of MPLS-TE and allows 97 control a transport network consisting of TDM cross-connect, 98 optical/lambda switches, and fibers. By introducing GMPLS technology, 99 some service providers expect that MPLS-TE network connectivity is 100 effectively and reliably established over the GMPLS network. If MPLS- 101 TE and GMPLS protocols can interwork with each other, the 102 introduction of GMPLS would be more beneficial for service providers, 103 because this is expected to improve the resource utilization, network 104 resiliency and manageability all over the network, less impacting the 105 existing MPLS-TE networks. 107 Currently, there is no clear definition and standardization work to 108 interwork between MPLS-TE routers and GMPLS routers or switches, i.e. 109 , between MPLS-TE networks and GMPLS networks. In order to accelerate 110 the deployment of GMPLS technology, MPLS-TE/GMPLS interworking is a 111 key. 113 In order to create the definition of MPLS-TE/GMPLS interworking 114 technology, the concrete requirement is preferably defined from the 115 point of operational experience of MPLS-TE/GMPLS networks and future 116 view on these technologies by collecting the input and requirements 117 from various service providers. 119 Considering such environment, this document focuses on the 120 requirement of MPLS-TE/GMPLS interworking especially in support of 121 GMPLS deployment. 123 2. Terminology 125 LSP: Label Switched Path 127 MPLS-TE LSP: Multi Protocol Label Switching Traffic Engineering LSP 129 PSC: Packet Switch Capable 131 LSC: Lambda Switch Capable 133 Head-end LSR: ingress LSR 135 Tail-end LSR: egress LSR 137 LSR: Label Switching Router 139 3. Problem Statement 141 GMPLS technology is deployed or will be deployed in various forms to 142 provide a highly efficient transport for existing MPLS-TE networks, 143 depending on the deployment choices of each service provider. A GMPLS 144 network may provide connectivity in terms of LSPs that are used as TE 145 links by the MPLS-TE network to support MPLS-TE LSPs. 147 In terms of MPLS-TE/GMPLS signaling, although GMPLS LSPs may be set 148 up triggered by the signaling of MPLS-TE LSPs, the clear mechanism of 149 how to interwork has not yet been defined. Feature richness of MPLS- 150 TE and GMPLS technology allows service providers to use a set of 151 options on how GMPLS services can be used by MPLS-TE networks. In 152 this document, the requirement for MPLS-TE/GMPLS interworking is 153 presented with some operations considerations associated with use of 154 GMPLS services by MPLS-TE networks. 156 4. Reference model 158 The reference model used in this document is shown in Figure 1. As 159 indicated in [RFC3945], the optical transport network consists of, 160 for example, GMPLS controlled OXCs and GMPLS-enabled MPLS-TE routers. 162 Interworking point Interworking point 163 ^ ^ 164 | | 165 GMPLS LSPs 166 |MPLS-TE LSPs |------------------------------|MPLS-TE LSPs | 167 |-----------------|------------------------------|-----------------| 168 | |------------------------------| | 169 MPLS-TE network | Optical Transport |MPLS-TE network 170 | (GMPLS) Network | 171 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 172 | | | | | | | | | | | | 173 | MPLS-TE +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ MPLS-TE | 174 | Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service | 175 | Network +--+ router | | +--+ | | router +--+ Network | 176 | | | | | | | | | | | | 177 +---------+ +--------+ +------+ +------+ +--------+ +---------+ 179 Figure 1. Reference model of MPLS-TE/GMPLS interworking 181 MPLS-TE network connectivity is provided through a GMPLS LSP which is 182 created between GMPLS routers. This document defines the requirements 183 for how the MPLS-TE network and the GMPLS network are interworked in 184 order to effectively operate the entire network and smoothly deploy 185 the GMPLS network. 187 5. Detailed Requirements 189 This section describes detailed requirements for MPLS-TE/GMPLS 190 interworking in support of GMPLS deployment. 192 5.1 Use of GMPLS optical network resources in MPLS-TE networks 194 The solution SHOULD provide the ability to make effective use of 195 GMPLS optical network resources (e.g. bandwidth, protection & 196 recovery) by the MPLS-TE service networks. 198 The GMPLS network MUST be able to support more than one MPLS-TE 199 network. Most of service providers have different networks for 200 various services; their GMPLS deployment plans are to have these 201 service networks use a common GMPLS controlled optical network as a 202 core network of various services. 204 5.2 Mapping signaling information between MPLS-TE and GMPLS 206 The solution SHOULD provide the ability to map signaling information 207 between MPLS-TE and GMPLS. From an MPLS-TE signaling point of view, 208 the routers in MPLS-TE domain should be able to signal over GMPLS 209 optical domain. In this case, an interworking between MPLS-TE and 210 GMPLS protocol is required. 212 5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE LSPs 213 signaling 215 The solution SHOULD provide the ability to establish end-to-end MPLS- 216 TE LSPs over a GMPLS optical network. GMPLS LSPs SHOULD be set up 217 triggered by the signaling of MPLS-TE LSP. 219 5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths over 220 GMPLS optical network 222 The solution SHOULD provide the ability to establish end-to-end 223 MPLS-TE LSPs having diverse paths including diverse GMPLS LSPs 224 corresponding to the request of the head-end MPLS LSR for protection 225 of MPLS-TE LSPs. The GMPLS optical network SHOULD assure the 226 diversity of GMPLS LSPs, even if their ingress nodes in GMPLS optical 227 network are different. 229 5.5 Advertisement of TE information via GMPLS optical domain 231 The solution SHOULD provide the ability to control advertisements of 232 TE information belonging to MPLS-TE service networks across the GMPLS 233 optical network. 234 The TE information within the same MPLS-TE service networks needs to 235 be exchanged in order that a head end LSR of the MPLS-TE network can 236 compute an LSP to a tail end LSR that is reached over the GMPLS 237 optical network. 238 On the other hand, the TE information belonging to one MPLS-TE 239 service network MUST NOT be advertised to other MPLS-TE service 240 networks to preserve confidentiality and security, and in order to 241 avoid establishing undesirable LSPs. 243 5.6 Selective advertisement of TE information via a border node 245 The solution SHOULD provide the ability to distribute TE reachability 246 information from the GMPLS optical network to MPLS-TE networks 247 selectively, which are useful for the head-end MPLS routers to 248 compute MPLS-TE LSPs. 250 5.7 Interworking of MPLS-TE and GMPLS protection 252 The solution SHOULD provide the ability to select GMPLS protection 253 types for the GMPLS LSPs according to protection options defined for 254 the protected MPLS-TE LSPs. 255 If MPLS-TE LSPs are protected using MPLS FRR [RFC4090], then when an 256 FRR protected packet LSP is signaled, we SHOULD be able to select 257 protected GMPLS LSPs in the GMPLS optical network. In terms of MPLS 258 protection, the MPLS-TE Path message can include some flags in the 259 FAST REROUTE object and SESSION_ATTRIBUTE object. In terms of GMPLS 260 protection, there are both signaling aspects [RFC3471] [RFC3473] and 261 routing aspects [RFC4202]. 263 5.8 Failure recovery 265 The solution SHOULD provide failure recovery in the GMPLS optical 266 domain without impacting MPLS-TE domain and vice versa. 267 In case that failure in the GMPLS optical domain associates with 268 MPLS-TE domain, some kind of notification of the failure may be 269 transmitted to MPLS-TE domain and vice versa. 271 5.9 Complexity and Risks 273 The solution SHOULD NOT introduce unnecessary complexity to the 274 current operating network to such a degree that it would affect the 275 stability and diminish the benefits of deploying such a solution over 276 service provider networks. 278 5.10 Scalability consideration 280 The solution MUST have a minimum impact on network scalability for 281 deploying GMPLS technology in the existing MPLS-TE networks. 282 Scalability of GMPLS deployment in the existing MPLS-TE networks MUST 283 address the following consideration. 285 - the number of GMPLS capable nodes (e.g. the number of non-PSC GMPLS 286 capable nodes) 287 - the number of MPLS-TE capable nodes 288 - the number of GMPLS LSPs 289 - the number of MPLS-TE LSPs 291 5.11 Performance consideration 293 The solution SHOULD be evaluated with regard to the following 294 criteria. 296 - Failure and restoration time 297 - Impact and scalability of the control plane due to added 298 overheads and so on 299 - Impact and scalability of the data/forwarding plane due to added 300 overheads and so on 302 5.12 Management consideration 304 Manageability of MPLS-TE/GMPLS interworking MUST addresses the 305 following consideration. 307 - need for a MIB module for control plane and monitoring 308 - need for diagnostic tools 310 MIB for an interworking between MPLS-TE and GMPLS protocol SHOULD be 311 implemented. 312 In case that an interworking between MPLS-TE and GMPLS protocol is 313 done, a failure between them MUST be detected. 315 6. Security Considerations 317 We will write security considerations in next version. 319 7. IANA Considerations 321 This requirement document makes no requests for IANA action. 323 8. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 329 (GMPLS) Architecture", RFC3945, October 2004. 331 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 332 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 334 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 335 (GMPLS) Signaling Functional Description", RFC3471, January 336 2003. 338 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 339 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 340 Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. 342 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support 343 of Generalized Multi-Protocol Label Switching (GMPLS)", 344 RFC4202, October 2005. 346 9 .Acknowledgments 348 The author would like to express the thanks to Raymond Zhang, Adrian 349 Farrel for their helpful and useful comments and feedback. 351 10.Author's Addresses 353 Kenji Kumaki 354 KDDI Corporation 355 Garden Air Tower 356 Iidabashi, Chiyoda-ku, 357 Tokyo 102-8460, JAPAN 358 Email: ke-kumaki@kddi.com 360 Tomohiro Otani 361 KDDI R&D Laboratories, Inc. 362 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 363 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 365 Shuichi Okamoto 366 NICT JGN II Tsukuba Reserach Center 367 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117 368 Tokyo, 100-0004, Japan E-mail :okamot-s@nict.go.jp 370 Kazuhiro Fujihara 371 NTT Communications Corporation 372 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 373 Tokyo 163-1421, Japan 374 EMail: kazuhiro.fujihara@ntt.com 376 Yuichi Ikejiri 377 NTT Communications Corporation 378 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 379 Tokyo 163-1421, Japan 380 EMail: y.ikejiri@ntt.com 382 11.Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed 386 to pertain to the implementation or use of the technology described 387 in this document or the extent to which any license under such 388 rights might or might not be available; nor does it represent that 389 it has made any independent effort to identify any such rights. 390 Information on the procedures with respect to rights in RFC 391 documents can be found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use 396 of such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository 398 at http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Disclaimer of Validity 408 This document and the information contained herein are provided on 409 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 410 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 411 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 412 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 413 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Copyright Statement 418 Copyright (C) The Internet Society (2006). This document is subject 419 to the rights, licenses and restrictions contained in BCP 78, and 420 except as set forth therein, the authors retain all their rights. 422 Acknowledgement 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.