idnits 2.17.1 draft-ietf-pce-gmpls-aps-req-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (July 21, 2013) is 3894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-09 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pcep-mib-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Otani 3 Internet-Draft K. Ogaki 4 Intended status: Informational KDDI 5 Expires: January 22, 2014 D. Caviglia 6 Ericsson 7 F. Zhang 8 Huawei Technologies 9 C. Margaria 10 Coriant R&D GmbH 11 July 21, 2013 13 Requirements for GMPLS applications of PCE 14 draft-ietf-pce-gmpls-aps-req-09.txt 16 Abstract 18 The initial effort of the PCE (Path computation element) WG was 19 mainly focused on MPLS. As a next step, this draft describes 20 functional requirements for GMPLS application of PCE. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 22, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. GMPLS applications of PCE . . . . . . . . . . . . . . . . . . 3 58 2.1. Path computation in GMPLS network . . . . . . . . . . . . 3 59 2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . 5 60 2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 5 61 3. Requirements for GMPLS application of PCE . . . . . . . . . . 5 62 3.1. Requirements on Path Computation Request . . . . . . . . 5 63 3.2. Requirements on Path Computation Reply . . . . . . . . . 6 64 3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The initial effort of the PCE (Path computation element) WG was 76 mainly focused on solving the path computation problem within a 77 domain or over different domains in MPLS networks. As the same case 78 with MPLS, service providers (SPs) have also come up with 79 requirements for path computation in GMPLS-controlled networks 80 [RFC3945] such as wavelength, TDM-based or Ethernet-based networks as 81 well. 83 [RFC4655] and [RFC4657] discuss the framework and requirements for 84 PCE on both packet MPLS networks and GMPLS-controlled networks. This 85 document complements these RFCs by providing some considerations of 86 GMPLS applications in the intra-domain and inter-domain networking 87 environments and indicating a set of requirements for the extended 88 definition of PCE-related protocols. 90 Note that the requirements for inter-layer and inter-area traffic 91 engineering described in [RFC6457] and [RFC4927] are outside of the 92 scope of this document. 94 Constraint-based shortest path first (CSPF) computation within a 95 domain or over domains for signaling GMPLS Label Switched Paths 96 (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], 97 because the additional constraints, e.g., interface switching 98 capability, link encoding, link protection capability, SRLG (Shared 99 risk link group) [RFC4202] and so forth need to be considered to 100 establish GMPLS LSPs. GMPLS signaling protocol [RFC3473] is designed 101 taking into account bi-directionality, switching type, encoding type 102 and protection attributes of the TE links spanned by the path, as 103 well as LSP encoding and switching type of the end points, 104 appropriately. 106 This document provides requirements for GMPLS applications of PCE in 107 support of GMPLS path computation, included are requirements for both 108 intra-domain and inter-domain environments. 110 2. GMPLS applications of PCE 112 2.1. Path computation in GMPLS network 114 Figure 1 depicts a model GMPLS network, consisting of an ingress 115 link, a transit link as well as an egress link. We will use this 116 model to investigate consistent guidelines for GMPLS path 117 computation. Each link at each interface has its own switching 118 capability, encoding type and bandwidth. 120 Ingress Transit Egress 121 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 122 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 123 | |<------------| |<------------| |<------------| | 124 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 126 Figure 1: Path computation in GMPLS networks 128 For the simplicity in consideration, the below basic assumptions are 129 made when the LSP is created. 131 (1) Switching capabilities of outgoing links from the ingress and 132 egress nodes (link1-2 and link4-3 in Figure 1) are consistent with 133 each other. 135 (2) Switching capabilities of all transit links including incoming 136 links to the ingress and egress nodes (link2-1 and link3-4) are 137 consistent with switching type of a LSP to be created. 139 (3) Encoding-types of all transit links are consistent with encoding 140 type of a LSP to be created. 142 GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are 143 usually responsible for transmitting data for the client layer. 145 These GMPLS-controlled networks can provide different types of 146 connections for customer services based on different service 147 bandwidth requests. 149 The applications and the corresponding additional requirements for 150 applying PCE to, for example, GMPLS-based TDM networks, are described 151 in Figure 2. In order to simplify the description, this document 152 just discusses the scenario in SDH networks as an example. The 153 scenarios in SONET or OTN are similar to this scenario. 155 N1 N2 156 +-----+ +------+ +------+ 157 | |-------| |--------------| | +-------+ 158 +-----+ | |---| | | | | 159 A1 +------+ | +------+ | | 160 | | | +-------+ 161 | | | PCE 162 | | | 163 | +------+ | 164 | | | | 165 | | |-----| | 166 | +------+ | | 167 | N5 | | 168 | | | 169 +------+ +------+ 170 | | | | +-----+ 171 | |--------------| |--------| | 172 +------+ +------+ +-----+ 173 N3 N4 A2 175 Figure 2: A simple TDM (SDH) network 177 Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, 178 N4 and N5 are all SDH switches. Assume that one Ethernet service 179 with 100M bandwidth is required from A1 to A2 over this network. The 180 client Ethernet service could be provided by a VC4 container from N1 181 to N4, and it could also be provided by three concatenated VC3 182 containers (Contiguous or Virtual concatenation) from N1 to N4. 184 In this scenario, when the ingress node (e.g., N1) receives a client 185 service transmitting request, the type of containers (one VC4 or 186 three concatenated VC3) could be determined by PCC (Path computation 187 client) (e.g., N1 or NMS), but could also be determined by PCE 188 automatically based on policy [RFC5394]. If it is determined by PCC, 189 PCC should be capable of specifying the ingress node and egress node, 190 signal type, the type of the concatenation and the number of the 191 concatenation in a PCReq (Path computation request) message. PCE 192 should consider those parameters during path computation. The route 193 information (co-route or separated-route) should be specified in a 194 PCRep (Path computation reply) message if path computation is 195 performed successfully. 197 As described above, PCC should be capable of specifying TE attributes 198 defined in the next section and PCE should compute a path 199 accordingly. 201 Where a GMPLS network is consisting of inter-domain (e.g., inter-AS 202 or inter-area) GMPLS-controlled networks, requirements on the path 203 computation follows [RFC5376] and [RFC4726]. 205 2.2. Unnumbered Interface 207 GMPLS supports unnumbered interface ID that is defined in [RFC3477], 208 which means that the endpoints of the path may be unnumbered. It 209 should also be possible to request a path consisting of the mixture 210 of numbered links and unnumbered links, or a P2MP (Point-to- 211 multipoint) path with different types of endpoints. Therefore, the 212 PCC should be capable of indicating the unnumbered interface ID of 213 the endpoints in the PCReq message. 215 2.3. Asymmetric Bandwidth Path Computation 217 As per [RFC6387], GMPLS signaling can be used for setting up an 218 asymmetric bandwidth bidirectional LSP. If a PCE is responsible for 219 the path computation, the PCE should be capable of computing a path 220 for the bidirectional LSP with asymmetric bandwidth. It means that 221 the PCC should be able to indicate the asymmetric bandwidth 222 requirements in forward and reverse directions in the PCReq message. 224 3. Requirements for GMPLS application of PCE 226 3.1. Requirements on Path Computation Request 228 As for path computation in GMPLS-controlled networks as discussed in 229 section 2, the PCE should appropriately consider the GMPLS TE 230 attributes listed below once a PCC or another PCE requests a path 231 computation. The path calculation request message from the PCC or 232 the PCE must contain the information specifying appropriate 233 attributes. According to [RFC5440], [PCE-WSON-REQ] and to RSVP 234 procedures like explicit label control(ELC),the additional attributes 235 introduced are as follows: 237 (1) Switching capability/type: as defined in [RFC3471], [RFC4203] 238 and, all current and future values. 240 (2) Encoding type: as defined in [RFC3471], [RFC4203] and, all 241 current and future values. 243 (3) Signal Type: as defined in [RFC4606] and, all current and future 244 values. 246 (4) Concatenation Type: In SDH/SONET and OTN, two kinds of 247 concatenation modes are defined: contiguous concatenation which 248 requires co-route for each member signal and requires all the 249 interfaces along the path to support this capability, and virtual 250 concatenation which allows diverse routes for the member signals and 251 only requires the ingress and egress interfaces to support this 252 capability. Note that for the virtual concatenation, it also may 253 specify co-routed or separated-routed. See [RFC4606] and [RFC4328] 254 about concatenation information. 256 (5) Concatenation Number: Indicates the number of signals that are 257 requested to be contiguously or virtually concatenated. Also see 258 [RFC4606] and [RFC4328]. 260 (6) Technology-specific label(s) such as defined in [RFC4606], 261 [RFC6060], [RFC6002] or [RFC6205]. 263 (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 264 protection, 1:1 protection, (pre-planned) rerouting, etc. 266 (8) Administrative group: as defined in [RFC3630] 268 (9) Link Protection type: as defined in [RFC4203] 270 (10)Support for unnumbered interfaces: as defined in [RFC3477] 272 (11)Support for asymmetric bandwidth request: as defined in [RFC6387] 274 (12)Support for explicit label control during the path computation. 276 (13)Support of label restrictions in the requests/responses, 277 similarly to RSVP-TE ERO (Explicit route object) and XRO (Exclude 278 route object) as defined in [RFC3473] and [RFC4874]. 280 3.2. Requirements on Path Computation Reply 281 As described above, a PCE should compute the path that satisfies the 282 constraints which are specified in the PCReq message. Then the PCE 283 should send a PCRep message including the computation result to the 284 PCC. For Path Computation Reply message (PCRep) in GMPLS networks, 285 there are some additional requirements. The PCEP (PCE communication 286 protocol) PCRep message must be extended to meet the following 287 requirements. 289 (1) Path computation with concatenation 291 In the case of path computation involving concatenation, when a PCE 292 receives the PCReq message specifying the concatenation constraints 293 described in section 3.1, the PCE should compute a path accordingly. 295 For path computation involving contiguous concatenation, a single 296 route is required and all the interfaces along the route should 297 support contiguous concatenation capability. Therefore, the PCE 298 should compute a path based on the contiguous concatenation 299 capability of each interface and only one ERO which should carry the 300 route information for the response. 302 For path computation involving virtual concatenation, only the 303 ingress/egress interfaces need to support virtual concatenation 304 capability and there may be diverse routes for the different member 305 signals. Therefore, multiple EROs may be needed for the response. 306 Each ERO may represent the route of one or multiple member signals. 307 In the case where one ERO represents several member signals among the 308 total member signals, the number of member signals along the route of 309 the ERO must be specified. 311 (2) Label constraint 313 In the case that a PCC does not specify the exact label(s) when 314 requesting a label-restricted path and the PCE is capable of 315 performing the route computation and label assignment computation 316 procedure, the PCE needs to be able to specify the label of the path 317 in a PCRep message. 319 Wavelength restriction is a typical case of label restriction. More 320 generally in GMPLS-controlled networks label switching and selection 321 constraints may apply and a PCC may request a PCE to take label 322 constraint into account and return an ERO containing the label or set 323 of label that fulfil the PCC request. 325 (3) Roles of the routes 327 When a PCC specifies the protection type of an LSP, the PCE should 328 compute the working route and the corresponding protection route(s). 330 Therefore, the PCRep should allow to distinguish the working 331 (nominal) and the protection routes. According to these routes, 332 RSVP-TE procedure appropriately creates both the working and the 333 protection LSPs for example with ASSOCIATION object [RFC6689]. 335 3.3. GMPLS PCE Management 337 This document does not change any of the management or operational 338 details for networks that utilise PCE. Please refer to [RFC4655] for 339 an overview of this scenery. However, this document proposes the 340 introduction of several PCEP objects and data for the better 341 integration of PCE with GMPLS networks. Those protocol elements will 342 need to be visible in any management tools that apply to the PCE, 343 PCC, and PCEP. That includes, but is not limited to, adding 344 appropriate objects to existing PCE MIB modules that are used for 345 modelling and monitoring PCEP deployments [PCEP-MIB]. Ideas for what 346 objects are needed may be guided by the relevant GMPLS extensions in 347 GMPLS-TE-STD-MIB [RFC4802]." 349 4. Security Considerations 351 PCEP extensions to support GMPLS should be considered under the same 352 security as current PCE work and this extension will not change the 353 underlying security issues. Sec. 10 of [RFC5440] describes the list 354 of security considerations in PCEP. At the time [RFC5440] was 355 published, TCP Authentication Option (TCP-AO) had not been fully 356 specified for securing the TCP connections that underlie PCEP 357 sessions. TCP-AO [RFC5925] has now been published and PCEP 358 implementations should fully support TCP-AO according to [RFC6952]. 360 5. IANA Considerations 362 This document has no actions for IANA. 364 6. Acknowledgement 366 The author would like to express the thanks to Ramon Casellas, Julien 367 Meuric, Adrian Farrel, Yaron Sheffer and Shuichi Okamoto for their 368 comments. 370 7. References 372 7.1. Normative References 374 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 375 (GMPLS) Signaling Functional Description", RFC 3471, 376 January 2003. 378 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 379 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 380 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 382 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 383 in Resource ReSerVation Protocol - Traffic Engineering 384 (RSVP-TE)", RFC 3477, January 2003. 386 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 387 (TE) Extensions to OSPF Version 2", RFC 3630, September 388 2003. 390 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 391 (GMPLS) Architecture", RFC 3945, October 2004. 393 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 394 Support of Generalized Multi-Protocol Label Switching 395 (GMPLS)", RFC 4202, October 2005. 397 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 398 of Generalized Multi-Protocol Label Switching (GMPLS)", 399 RFC 4203, October 2005. 401 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 402 Switching (GMPLS) Signaling Extensions for G.709 Optical 403 Transport Networks Control", RFC 4328, January 2006. 405 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 406 Protocol Label Switching (GMPLS) Extensions for 407 Synchronous Optical Network (SONET) and Synchronous 408 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 410 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 411 Switching (GMPLS) Traffic Engineering Management 412 Information Base", RFC 4802, February 2007. 414 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 415 Extensions in Support of End-to-End Generalized Multi- 416 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 417 2007. 419 [RFC4927] Le Roux, J., "Path Computation Element Communication 420 Protocol (PCECP) Specific Requirements for Inter-Area MPLS 421 and GMPLS Traffic Engineering", RFC 4927, June 2007. 423 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 424 Requirements for the Path Computation Element 425 Communication Protocol (PCECP)", RFC 5376, November 2008. 427 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 428 (PCE) Communication Protocol (PCEP)", RFC 5440, March 429 2009. 431 [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data 432 Channel Switching Capable (DCSC) and Channel Set Label 433 Extensions", RFC 6002, October 2010. 435 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 436 "Generalized Multiprotocol Label Switching (GMPLS) Control 437 of Ethernet Provider Backbone Traffic Engineering (PBB- 438 TE)", RFC 6060, March 2011. 440 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 441 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 442 March 2011. 444 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 445 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 446 Switched Paths (LSPs)", RFC 6387, September 2011. 448 [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 449 6689, July 2012. 451 7.2. Informative References 453 [PCE-WSON-REQ] 454 Lee, Y., Bernstein, G., Martensson, J., Takeda, T., 455 Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON 456 Routing and Wavelength Assignment", draft-ietf-pce-wson- 457 routing-wavelength-09 (work in progress), June 2013. 459 [PCEP-MIB] 460 Koushik, A., Emile, S., Zhao, Q., King, D., and J. 461 Hardwick, "PCE communication protocol (PCEP) Management 462 Information Base", draft-ietf-pce-pcep-mib-05 (work in 463 progress), July 2013. 465 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 466 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 467 November 2005. 469 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 470 Element (PCE)-Based Architecture", RFC 4655, August 2006. 472 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 473 Communication Protocol Generic Requirements", RFC 4657, 474 September 2006. 476 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 477 Inter-Domain Multiprotocol Label Switching Traffic 478 Engineering", RFC 4726, November 2006. 480 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 481 Extension to Resource ReserVation Protocol-Traffic 482 Engineering (RSVP-TE)", RFC 4874, April 2007. 484 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 485 "Policy-Enabled Path Computation Framework", RFC 5394, 486 December 2008. 488 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 489 Authentication Option", RFC 5925, June 2010. 491 [RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE 492 Discovery Requirements for Inter-Layer Traffic 493 Engineering", RFC 6457, December 2011. 495 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 496 BGP, LDP, PCEP, and MSDP Issues According to the Keying 497 and Authentication for Routing Protocols (KARP) Design 498 Guide", RFC 6952, May 2013. 500 Authors' Addresses 502 Tomohiro Otani 503 KDDI Corporation 504 2-3-2 Nishi-shinjuku 505 Shinjuku-ku, Tokyo 506 Japan 508 Phone: +81-(3) 3347-6006 509 Email: tm-otani@kddi.com 511 Kenichi Ogaki 512 KDDI Corporation 513 3-10-10 Iidabashi 514 Chiyoda-ku, Tokyo 515 Japan 517 Phone: +81-(3) 6678-0284 518 Email: ke-oogaki@kddi.com 519 Diego Caviglia 520 Ericsson 521 16153 Genova Cornigliano 522 Italy 524 Phone: +390106003736 525 Email: diego.caviglia@ericsson.com 527 Fatai Zhang 528 Huawei Technologies Co., Ltd. 529 F3-5-B R&D Center, Huawei Base 530 Bantian, Longgang District, Shenzhen 518129 531 P.R.China 533 Phone: +86-755-28972912 534 Email: zhangfatai@huawei.com 536 Cyril Margaria 537 Coriant R&D GmbH 538 St Martin Strasse 76 539 Munich, 81541 540 Germany 542 Phone: +49 89 5159 16934 543 Email: cyril.margaria@coriant.com