idnits 2.17.1 draft-cho-pwe3-mpls-tp-mixed-ms-pw-setup-01.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 date (October 28, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-14 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Cho 2 Internet Draft J. Ryoo 3 Intended status: Standards Track ETRI 4 Expiration Date: April 28, 2012 D. King 5 Old Dog Consulting 6 October 28, 2011 8 Stitching Dynamically and Statically Provisioned Segments 9 To Construct End-To-End Multi-Segment Pseudowires 10 draft-cho-pwe3-mpls-tp-mixed-ms-pw-setup-01.txt 12 Abstract 14 The MPLS Transport Profile (MPLS-TP) transport paths can be 15 statically provisioned via a Network Management System (NMS) or 16 dynamically provisioned via a control plane. The transport paths 17 provided by MPLS-TP are used as a server layer for pseudowires 18 carrying client signals other than IP or MPLS. It may be necessary 19 to support MPLS-TP pseudowires, to extend across multiple domains. 21 This document outlines the requirements and solution for 22 coordinating MPLS-TP transport paths and a multi-segment PWs that 23 will traverse multiple domains, where some domains are statically 24 provisioned, and other domains that are dynamically provisioned. 26 This document is a product of a joint Internet Engineering Task Force 27 (IETF) / International Telecommunication Union Telecommunication 28 Standardization Sector (ITU-T) effort to include an MPLS Transport 29 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 30 (PWE3) architectures to support the capabilities and functionalities 31 of a packet transport network as defined by the ITU-T. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on April 28, 2012. 55 Copyright Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction ...........................................3 73 1.1 Statically Provisioned PWs across MPLS-TP ..........4 74 1.2 Dynamically Provisioned PWs across MPLS-TP .........4 75 1.3 Multi-Segment Pseudowire (MS-PW) ...................4 76 1.4 Multi-segment Pseudowire Path Selection ............4 77 2. Terminology ............................................5 78 2.1 Requirements Language...............................5 79 3. Reference Model ........................................5 80 4. Problem Statement ......................................7 81 4.1 Requirements .......................................8 82 5. Procedures .............................................8 83 6. Protocol Extensions ....................................8 84 7. Security Considerations ................................9 85 8. Operations and Maintenance (OAM) .......................9 86 9. IANA Considerations ....................................9 87 10. References .............................................9 88 10.1 Normative References ..............................9 89 10.2.Informative References ...........................10 90 11. Authors' Addresses ....................................10 92 1. Introduction 94 The MPLS Transport Profile (MPLS-TP) is being defined in a joint 95 effort between the International Telecommunications Union (ITU) and 96 the IETF. The requirements for MPLS-TP are defined in the 97 requirements document [RFC5654]. A general framework for MPLS-TP 98 has been defined in [RFC5921]. 100 An MPLS-TP network can be operated via static provisioning of 101 transport paths, or the elective use of GMPLS control plane to 102 support dynamic provisioning of transport paths. The MPLS-TP 103 LSP control plane is based on GMPLS. The framework for MPLS-TP 104 dynamic provisioning and is described in [MPLS-TP-CP]. 106 The LSPs provided by MPLS-TP are used as a server layer for 107 Pseudowires (PWs). The PWs are essential Communication Service 108 Providers (CSP) as they are used to carry client signals other than 109 IP or MPLS. 111 It may be necessary to extend the reach of an MPLS-TP transport path, 112 and PWs, across multiple domains. A domain can be defined as a 113 separate administrative, geographic, or switching environment within 114 the CSP network. Additionally a domain can also be categorized as a 115 separate AS or IGP area. 117 The MPLS-TP transport path would consist of two or more contiguous 118 MPLS-TP and PW segments, each segment would traverse a single domain. 119 The segments are concatenated so that they behave and function as a 120 single MPLS-TP transport and PW path. 122 For these multi-segment transport and PW paths the intermediate 123 segments, or domains, may be statically or dynamically provisioned. 124 There may be a requirement to automatically set up transport path 125 that will traverse multiple domains that are managed both statically 126 and dynamically. There must therefore be some coordination between 127 domains that are managed statically and dynamically to ensure the 128 end-to-end MPLS-TP transport path and PW are successfully setup. 130 This document outlines the requirements and solution for 131 coordinating MPLS-TP transport paths and PWs and that will traverse 132 multiple domains, where some domains are statically provisioned, and 133 other domains are dynamically provisioned. 135 This document is a product of a joint Internet Engineering Task Force 136 (IETF) / International Telecommunications Union Telecommunications 137 Standardization Sector (ITU-T) effort to include an MPLS Transport 138 Profile within the IETF MPLS and PWE3 architectures to support the 139 capabilities and functions of a packet transport network as defined 140 by the ITU-T. 142 1.1 Statically Provisioned PWs across MPLS-TP 144 A PW is a mechanism that carries a native service over an emulated 145 service from one PE to one or more other PEs over a PSN. [RFC3985], 146 defines the signaling and encapsulation techniques for establishing 147 Single-segment PW (SS-PWs) between a pair of terminating PEs. 149 1.2 Dynamically Provisioned PWs across MPLS-TP 151 [MS-PW-DYN] describes the procedure and extensions to dynamically 152 place the segments of the Multi-segment Pseudowire (MS-PW) among a 153 set of PE routers. The dynamic PW capability is based on the 154 existing PW control plane [RFC4447], and the PW architecture 155 [RFC3985]. 157 1.3 Multi-Segment Pseudowire (MS-PW) 159 A set of two or more contiguous PW segments that behave and function 160 as a single point-to-point PW, can be considered a MS-PW. The 161 architecture for MS-PWs across multi-domain environments is described 162 in [RFC5659]. 164 The switching points (S-PEs), in addition to the terminating (T-PEs), 165 are manually provisioned for each segment. They are configured 166 to direct the MPLS packets from one PW into the other. There is no 167 control protocol involved in this case. 169 Dynamic end-to-end signaling of MS-PWs is achieved by using 170 information present in S-PEs to support the determination of the next 171 PW signaling hop. This selection information is disseminated via 172 inter-domain routing protocols (e.g. BGP). 174 [RFC6073] describes a procedure for connecting multiple pseudowires 175 together where each domain is dynamically provisioned. This procedure 176 requires each S-PE to be manually configured with the information 177 required to terminate and initiate the Single-segment Pseudowire 178 (SS-PW) part of the Multi-segment Pseudowire (MS-PW). 180 The issue exists when an end-to-end PW is requested across domains 181 that are comprised of both statically and dynamically configured. 183 1.4 Multi-segment Pseudowire Path Selection 185 An important feature of the establishment of a multi-domain multi- 186 segment pseudowires is the determination of the path of the 187 pseudowire. That is, the selection of the LSP tunnels and PW 188 switching points that the end-to-end PW will traverse. 190 Selecting this path can be an off-line management task using 191 information gathered from a number of sources or pre-known by the 192 management tools. Alternatively, the path can be selected dynamically 193 using policy-based tools that operate on information gathered from 194 the network in a manner similar to existing MPLS traffic engineering 195 mechanisms, and using routing protocols. 197 However, in multi-domain environments there may be issues of 198 confidentiality of network topology information. For example, one 199 service provider may not wish to fully reveal the extent to which it 200 supports cross-domain LSP tunnels, or where its internal PW stitching 201 points are. These issues significantly complicate the mechanisms 202 available for selecting end-to-end multi-segment pseudowire paths. 204 The Path Computation Element (PCE) [RFC4655] was developed to 205 facilitate inter-domain path computation. The PCE uses topology 206 and resource availability information to compute paths inside a 207 domain. To support inter-domain path computation, PCEs responsible 208 for different coordinate with each other to calculate end-to-end 209 multi-domain paths. 211 Cooperating PCEs could be used to compute end-to-end MPLS-TP 212 transport paths and the stitching points of PW segments. This 213 document concentrates on the issues of signalling and not path 214 determination. The method and procedure of how this may be 215 achieved is not in scope of this document. 217 2. Terminology 219 MS-PW Multi-segment Pseudowire 220 PW Pseudowire 221 S-PE Pseudowire Switching Provider Edge 222 SS-PW Single-segment Pseudowire 223 T-PE Pseudowire Terminating Provider Edge 225 Additional definitions and terminology can be found in [RFC5921] and 226 [ROSETTA]. 228 2.1 Requirements Language 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in RFC 2119 [RFC2119]. 234 3. Reference Model 236 The control plane reference model is based on the general MPLS-TP 237 reference model as defined in the MPLS-TP framework [RFC5921]. Per 238 the MPLS-TP framework [RFC5921], where relevant the MPLS-TP control 239 plane is based on GMPLS with RSVP-TE for LSP signaling and targeted 240 LDP for PW signaling [RFC6073]. 242 PSN1 PSN2 PSN3 PSN4 243 +--------+ +--------+ +--------+ +--------+ 244 | | | | | | | | 245 | | | | | | | | 246 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 247 |A|...|B|====|C|==|D|===|E|===|F|==|G|====|H|...|I| 248 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 249 | | | | | | | | | | | | 250 | | | | | | | | | | | | 251 +--------+ +--------+ +--------+ +--------+ 252 | || |<--PW-->| |<--PW-->| || | 253 | | 254 |<-----Multi-Segment Pseudowire------>| 256 Figure 1: ABRs Acting as Pseudowire Switching Provider Edges 258 PSN1 PSN2 PSN3 259 +-------+ +---------+ +----------+ 260 | | | | | | 261 | | | | | | 262 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 263 |A|....|B|==|C|==|D|==|E|==|F|==|G|=====|H|....|I| 264 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 265 | || | | | | || | 266 | || | | | | || | 267 +-------+ +---------+ +----------+ 268 ||||<--PW--->||<--PW->|| 269 | | 270 |<----Multi-Segment Pseudowire---->| 272 Figure 2: ASBRs Acting as Pseudowire Switching Provider Edges 274 A: Customer Edge 275 B: Pseudowire Terminating Provider Edge 276 C: Pseudowire Switching Provider Edge 277 D: Provider Router 278 E: Pseudowire Switching Provider Edge 279 F: Provider Router 280 G: Pseudowire Switching Provider Edge 281 H: Pseudowire Terminating Provider Edge 282 I: Customer Edge 284 In the reference models described above any of the domains (PSNs) may 285 support static or dynamic PW establishment, for instance: 287 PSN1: Static Provisioning 288 PSN2: Dynamic Provisioning 289 PSN3: Static Provisioning 290 PSN4: Dynamic Provisioning 292 4. Problem Statement 294 The requirements and mechanisms for the establishment of MS-PWs are 295 given in [RFC6073]. This includes all of the signaling extensions to 296 describe PW capabilities, the S-PEs and T-PEs to be navigated (i.e., 297 the PW path), and the identities of the ACs that the PW connects. 299 However, when some of the segments are statically provisioned, there 300 is a requirement to carry this PW information across the statically 301 provisioned domains to make the information available in subsequent 302 dynamically provisioned domains. 304 For example, consider that in Figure 3, domains 1 and 2 are 305 dynamically provisioned, domain 3 is statically provisioned and 306 domain 4 is dynamically provisioned: 308 Dyn Dyn Static Dyn 309 +--------+ +--------+ +--------+ +--------+ 310 | | | | | | | | 311 | | | | | | | | 312 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 313 |A|...|B|====|C|==|D|===|E|===|F|==|G|====|H|...|I| 314 +-+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-+ 315 | | | | | | | | | | | | 316 | | | | | | | | | | | | 317 +--------+ +--------+ +--------+ +--------+ 318 | || |<--PW-->| |<--PW-->| || | 319 | | 320 |<-----Multi-Segment Pseudowire------>| 322 Figure 3: Dynamic and Static Domain Topology 324 The normal techniques of [RFC6073] can be used to request an 325 end-to-end MS-PW from B to H, and this can be signaled from B to E. 327 Furthermore, S-PE E can select a statically pre-provisioned PW 328 segment from E to G to use as the next segment in the MS-PW. Node E 329 can set up the necessary switching mechanisms for this connectivity. 331 However, [RFC6073] does not describe how node G is informed about the 332 end-to-end MS-PW or how G is triggered to resume dynamic signalling 333 toward T-PE H. It is not just a simple trigger that is required, 334 because all of the PW configuration parameters signaled by T-PE B 335 must be conveyed in the signaling from G to H. 337 This simple scenario can be further complicated by the existence of 338 multiple domains (static or dynamic in any sequence) along the path. 340 4.1 Requirements 342 The requirements for setting up end-to-end PWs across MPLS-TP 343 transport paths, across statically and dynamically provisioned 344 domains, are document in [RFC5659], specific attention should be 345 given to: 347 o End-to-end PW setup across the MPLS-TP LSP: the destination and BW 348 requirements MUST be met. 350 o Traffic engineering and QoS consistency: the PW traffic engineering 351 and QoS requirements MUST be met. 353 o Resiliency: when requested, the maintaining of mechanisms to 354 protect a MS-PW when an element on the existing path of a MS-PW 355 fails SHOULD be maintained. 357 PW resiliency is provided using end-to-end protection techniques. 358 That is, two path-diverse PWs are established to serve as working 359 and protected PWs. 361 In a MS-PW environment, these two PWs must be kept path diverse 362 across the whole of their paths. Where the path of the PWs is 363 pre-planned, this can be archived within the scope of the management 364 tool, and where both PWs are fully dynamic they can be established 365 sequentially with the second PW having the awareness of the route 366 of the first PW. 368 However, where there is a mix of static and dynamic segments, care 369 will be required to ensure that the end-to-end working and 370 protection MS-PWs follow diverse paths. 372 5. Procedures 374 The following section describe the procedures to satisfy the 375 problem and requirements specified in the previous section. 377 6. Protocol Extensions 379 Where possible existing control protocol and procedures will be 380 reused. However, to meet the setup and control of PWs over MPLS-TP 381 transport paths, that traverse statically and dynamically 382 provisioned domains, a set of new extensions of the existing control 383 plane mechanisms are required. 385 This section will clarify the areas where PW control plane extensions 386 are required. 388 7. Security Considerations 390 The MPLS-TP data plane does not provide any specific security 391 mechanisms. MS-PW connections that wish to secure data carried over 392 MPLS-TP transport entities are REQUIRED to apply their own 393 security mechanisms. 395 Where control plane protocols are used to dynamically install 396 label switching operations necessary to establish MPLS-TP transport 397 paths, those protocols are equipped with security features that 398 network operators may use to securely create the transport paths. 400 The use of static configuration exposes the CSP to another set of 401 security risks, compared to dynamic configuration. If an MPLS-TP 402 transport path is misconfigured in a statically configured network, 403 it may result traffic looping and lack of end-to-end connectivity. 405 Further details of MPLS and MPLS-TP security can be found in 406 [RFC5921] and [RFC5920]. The PWE3 security considerations are 407 described in [RFC3985]. 409 8. Operations and Maintenance (OAM) 411 To be discussed in future revisions of this document. 413 9. IANA Considerations 415 To be discussed in future revisions of this document. 417 10. References 419 10.1 Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 425 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 426 June 2005. 428 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 429 Sprecher, N., and S. Ueno, "Requirements of an MPLS 430 Transport Profile", RFC 5654, September 2009. 432 10.2 Informative References 434 [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge- 435 to-Edge (PWE3) Architecture", RFC 3985, March 2005. 437 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 438 Computation Element (PCE)-Based Architecture", RFC 4655, 439 August 2006. 441 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 442 Segment Pseudo Wire Emulation Edge-to-Edge", RFC 5659, 443 October 2009. 445 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 446 Networks", RFC 5920, July 2010. 448 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 449 Berger, "A Framework for MPLS in Transport Networks", 450 RFC 5921, July 2010. 452 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 453 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 455 [MS-PW-DYN] Martini, L., Bocci, M., Bitar, N., Shah, H., Aissaoui, 456 M., and F. Balus, et al. "Dynamic Placement of Multi 457 Segment Pseudo Wires", 458 draft-ietf-pwe3-dynamic-ms-pw-14 (work in progress), 459 July 2011. 461 [MPLS-TP-CP] Andersson, L., Berger, L., Fang, L., Bitar, N., 462 Takacs, A., Vigoureux, M., and E. Bellagamba, 463 "MPLS-TP Control Plane Framework", 464 draft-abfb-mpls-tp-control-plane-framework-02 465 (work inprogress), January 2011. 467 [ROSETTA] Van Helvoort, H., Ed., Andersson, L., and N. Sprecher, "A 468 Thesaurus for the Terminology used in Multiprotocol Label 469 Switching Transport Profile (MPLS-TP) drafts/RFCs and 470 ITU-T's Transport Network Recommendations", draft-ietf- 471 mpls-tp-rosetta-stone, Work in Progress. 473 11. Authors' Addresses 475 Hyunwoo Cho 476 ETRI 477 161 Gajeong, Yuseong, Daejeon, 305-700, South Korea. 478 Email: tenace@etri.re.kr 480 Jeong-dong Ryoo 481 ETRI 482 161 Gajeong, Yuseong, Daejeon, 305-700, South Korea. 483 Email: ryoo@etri.re.kr 484 Daniel King 485 Old Dog Consulting 486 UK 487 Email: daniel@olddog.co.uk