idnits 2.17.1 draft-bryant-pwe3-mpls-transport-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 490. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 13, 2006) is 6398 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) == Missing Reference: 'RFC 3985' is mentioned on line 78, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-11 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bryant 2 Editor 3 Internet Draft Cisco Systems 4 Expires: April 2007 October 13, 2006 6 Application of PWE3 to MPLS Transport Networks 7 draft-bryant-pwe3-mpls-transport-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 13, 2007. 35 Abstract 37 A need has been identified to identify a strict subset of the PWE3 38 over MPLS pseudowire functionality suitable for the construction of 39 transport networks. This draft describes the IETF recommended profile 40 for such cases. This document describes the IETF-recommended profile 41 for such a configuration. In particular the profile of an RFC4448 42 PWE3 Ethernet pseudowire that can be used to address these 43 requirements is described. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [RFC2119]. 51 Table of Contents 53 1. Introduction...................................................2 54 2. PWE3 Configuration.............................................3 55 3. OAM............................................................4 56 3.1. VCCV profile 1: BFD without IP/UDP Headers................4 57 3.2. VCCV profile 2: BFD with IP/UDP Headers...................4 58 4. MPLS Layer.....................................................4 59 4.1. External Configuration....................................5 60 4.2. Control Plane Configuration...............................5 61 5. Congestion Considerations......................................6 62 6. Security Considerations........................................6 63 7. IANA Considerations............................................6 64 8. Acknowledgments................................................6 65 APPENDIX A: Requirements..........................................7 66 9. References.....................................................9 67 9.1. Normative References......................................9 68 9.2. Informative References...................................10 69 Author's Addresses...............................................10 70 Intellectual Property Statement..................................12 71 Disclaimer of Validity...........................................12 72 Copyright Statement..............................................12 73 Acknowledgment...................................................13 75 1. Introduction 77 A requirement has been identified to identify a restricted subset of 78 the Pseudowire Emulation Edge-to-Edge (PWE3) [RFC 3985] over Multi- 79 Protocol Label Switching (MPLS) [RFC3031] pseudowire functionality 80 suitable for the construction of transport networks. This document 81 describes the IETF-recommended profile for such a configuration. In 82 particular, it describes a profile of an RFC4448 PWE3 Ethernet 83 pseudowire [RFC4448] that can be used to address these requirements. 84 The scope of the initial version of this profile is restricted to 85 transporting client Ethernet over an MPLS Packet Switched Network 86 (PSN). 88 The architecture required for this configuration is illustrated in 89 Figure 1 below. It is based on requirements described in the 90 Requirements below. 92 +----------------------------------------------------------------+ 93 | | 94 | IP/MPLS PSN (PHP may be enabled) | 95 | | 96 | +---------------------------+ | 97 | | | | 98 | | MPLS PSN (No PHP) | | 99 | | | | 100 | CE1 |PE1 PE2| CE2 | 101 | +-----+ +-----+ +-----+ +-----+ | 102 | | | | | | | | | | | | | | | | | | 103 | | | | +------+ | | | | | | +------+ | | | | 104 | | | | | 802.3| | | | | | | | 802.3| | | | | 105 | +-----+ +-----+ +-----+ +-----+ | 106 | | | | | | | | | | 107 | | | +-- ---------------------- -+ | | | 108 +----- --- -------- -- ---------------------- - -------- --- ----+ 109 | | | |<--MPLS PSN (no PHP)->| | | | 110 | | | | | | 111 | | |<------------PW----------->| | | 112 | | | | 113 | |<-------------802.3 (Ethernet)-------------->| | 114 | | 115 |<---------IP/MPLS LSP (PHP may be supported)-------->| 117 Figure 1: Application PWE3 to MPLS Transport Networks 119 An IP or an MPLS Label Switched Path (LSP) must be established 120 between CE1 and CE2. This MPLS PSN may be utilize Penultimate-Hop 121 Popping (PHP). This LSP is to be carried over Ethernet. An Ethernet 122 PW is provisioned between PE1 and PE2 and used to carry the Ethernet 123 from PE1 to PE2. The Ethernet PW is carried over an MPLS PSN, but 124 this PSN MUST NOT be configured with PHP. 126 2. PWE3 Configuration 128 The only PWE3 encapsulation that is supported in this version of the 129 profile is Ethernet [RFC4448]. This is used in "raw" mode. 131 The Control Word MUST be used. The Sequence number MUST be zero. 133 The use of the Pseudowire Setup and Maintenance Label Distribution 134 Protocol [RFC4447] is not supported in this version of the profile. 135 The Pseudowire Label is statically provisioned. 137 3. OAM 139 The OAM mechanism is VCCV [VCCV]. 141 One of the following VCCV profiles MUST be used. Once one is 142 provisioned and the operational status of the PW is UP, no other 143 profile SHOULD be used until such time as the PW's operational status 144 is set to DOWN. 146 3.1. VCCV profile 1: BFD without IP/UDP Headers 148 As specified in [VCCV], the first nibble is set to 0001b to indicate 149 a channel associated with a pseudowire [RFC4385][RFC4446]. The 150 Version and the Reserved fields are set to 0, the Version is 0, and 151 the Channel Type is set to 0x07 to indicate that the payload carried 152 in BFD without IP/UDP headers, as is defined in section 4.1.1 of 153 [VCCV]. 155 The connection verification method used by VCCV is BFD with 156 diagnostics as defined in 4.1 of [VCCV]. 158 3.2. VCCV profile 2: BFD with IP/UDP Headers 160 When PE1 and PE1 are IP capable and have been configured with IP 161 addresses, the following VCCV mechanism MAY be used. 163 As specified in [VCCV], the first nibble is set to 0001b to indicate 164 a channel associated with a pseudowire [RFC4385][RFC4446]. The 165 Version and the Reserved fields are set to 0, the Version is 0, and 166 the Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads. 168 The connection verification method used by VCCV is BFD with 169 diagnostics as defined in 4.1 of [VCCV]. 171 4. MPLS Layer 173 This section describes the profile of the MPLS PSN [RFC3031]. The 174 requirements are based on the requirements communicated to the IETF 175 and included in Appendix 1. The profile considers two cases: 177 1. The case where external configuration is used 179 2. The case where a control plane is available 181 4.1. External Configuration 183 All MPLS labels [RFC3032] used by the transport LSPs utilized by the 184 PWs described in sections 2 and 3 MUST be statically provisioned. 185 Labels may be selected from the per-platform or per-interface label 186 space. 188 All LSPs for the transport LSPs utilized by the PWs described in 189 sections 2 MUST support both unidirectional and bi-directional point- 190 to-point connections. 192 The transport LSPs SHOULD support unidirectional point-to-multipoint 193 connections. 195 The forward and backward directions of a bi-directional connection 196 should follow the same path along the transport LSP. 198 Equal cost multi-path (ECMP) load balancing MUST NOT be configured on 199 the transport LSPs utilized by the PWs described in sections 2 and 3. 201 The Merging of label switched paths is prohibited and MUST NOT be 202 configured the transport LSPs utilized by the PWs described in 203 sections 2 and 3. 205 Penultimate hop popping by the LSRs MUST be disabled on LSPs 206 providing PWE3 transport network functionality. 208 Both E-LSP and L-LSP MUST be supported as defined in RFC3270 209 [RFC3270]. 211 The MPLS EXP field is supported according to RFC3270 for only 212 when the pipe and short-pipe models are utilized. 214 4.2. Control Plane Configuration 216 In this section we describe the profile when RSVP-TE [] or the bi- 217 directional support in GMPLS [] are used to configure the MPLS PSN 218 used to provide the transport LSPs. When these protocols are used to 219 provide the control plane the following are automatically provided: 221 1. There is no label merging unless it is deliberately enabled to 222 support Fast Re-route (FRR)[]. 224 2. A single path is provided end-to-end (There is no ECMP). 226 3. Paths may be unidirectional or bidirectional as required. 228 Additionally the following configurations restrictions required to 229 support external configuration MUST be applied: 231 Penultimate hop popping by the LSRs MUST be disabled on LSPs 232 providing PWE3 transport network functionality. 234 Both E-LSP and L-LSP MUST be supported as defined in RFC3270 235 [RFC3270]. 237 The MPLS EXP field is supported according to RFC3270 for only 238 when the pipe and short-pipe models are utilized. 240 5. Congestion Considerations 242 This draft is a profile of an RFC4448 PWE3 Ethernet pseudowire. The 243 security considerations associated with that pseudowire and all 244 subsequent work on congestion considerations regarding Ethernet 245 pseudowires is applicable to this draft. 247 6. Security Considerations 249 PWE3 security considerations are described in RFC3985 [RFC3985]. 251 This draft is a profile of existing IETF proposed standards and 252 raises no new security issues. 254 7. IANA Considerations 256 There are no IANA actions required by this draft. 258 8. Acknowledgments 259 APPENDIX A: Requirements 261 This appendix is NOT normative. 263 The following are the requirements for a transport pseudowire and are 264 based on inputs from ITU SG15 [ITU1]. These in turn are the result of 265 ITU studies on Transport MPLS [ITU2]. 267 1. A transport pseudowire shall be based on a connection-oriented 268 packet switched technology. Transport networks can also support 269 circuit switched transport technologies (e.g. SDH, OTH or WDM) 271 2. A transport pseudowire shall operate under a common operation, 272 control and management paradigm with respect to other transport 273 technologies (e.g. SDH, OTN or WDM) 275 3. A transport pseudowire network shall support multiple layer 276 network instances; e.g. a TRANSPORT PSEUDOWIRE transport network 277 "service layer" instance in which the connections carry the 278 customer's (individual or bundled) service, a TRANSPORT 279 PSEUDOWIRE transport network "trunk layer" instance in which the 280 connections carry aggregates of the network "service layer" 281 connections and a transmission media layer instance in which the 282 connections carry the aggregate of network trunk or network 283 service connections. 285 4. The identification of each connection within its aggregate shall 286 be based on labels. Connections can be aggregated into trunks by 287 pushing and de-aggregated by popping labels. TRANSPORT 288 PSEUDOWIRE labels may be swapped within a connection in a layer 289 network instance when the traffic is forwarded from one 290 TRANSPORT PSEUDOWIRE link connection to another TRANSPORT 291 PSEUDOWIRE link connection. TRANSPORT PSEUDOWIRE pop, push, and 292 swap label operations should be performed as defined by the 293 relevant IETF RFCs. 295 5. Labeling shall make use of the MPLS label and label stack entry 296 as defined in RFC3032. 298 6. A transport pseudowire layer network shall support TRANSPORT 299 PSEUDOWIRE and non TRANSPORT PSEUDOWIRE client layer networks 300 and shall be able to be carried over TRANSPORT PSEUDOWIRE and 301 non TRANSPORT PSEUDOWIRE server layer networks. 303 7. A transport pseudowire transport plane shall be able to operate 304 without any IP functionality present. 306 8. A transport pseudowire network shall be able to be operated with 307 a centralized NMS system 309 9. A transport pseudowire network should be able to be operated by 310 a centralized NMS system with the support of a distributed 311 control plane 313 10. A transport pseudowire shall support both unidirectional and 314 bi-directional point-to-point connections 316 11. A transport pseudowire should support unidirectional point-to- 317 multipoint connections 319 12. The forward and backward directions of a bi-directional 320 connection should follow the same path along the TRANSPORT 321 PSEUDOWIRE network. 323 13. The intermediate nodes should be aware about the binding of the 324 forward and the backward directions belonging to the same bi- 325 directional connection. 327 14. A transport pseudowire shall support traffic-engineering 328 capabilities with traffic- and/or resource-oriented performance 329 objectives. 331 15. A transport pseudowire shall support a method to offer packet 332 loss objectives comparable to those in TDM transport networks 333 (only due to bit errors) 335 16. A transport pseudowire should support transport and QoS 336 mechanisms that can deliver statistical multiplexing gain. 337 Packets exceeding the agreed traffic profile are however not 338 allowed to enter into the TRANSPORT PSEUDOWIRE network (i.e. 339 they are discarded by the traffic conditioning at the ingress of 340 the network) 342 17. A transport pseudowire layer network shall operate 343 independently of other layer networks (either TRANSPORT 344 PSEUDOWIRE or non TRANSPORT PSEUDOWIRE). 346 18. A transport pseudowire shall support connections through a 347 single domain 349 19. A transport pseudowire should support connections through 350 multiple domains 352 20. A transport pseudowire shall offer as much commonality as 353 possible with the MPLS user plane as defined by IETF. When MPLS 354 offers multiple options in this respect, TRANSPORT PSEUDOWIRE 355 should select the minimum sub-set (necessary and sufficient 356 subset) applicable to a transport network application. 358 OAM Requirements: 360 21. A transport pseudowire should support transport network 361 connection and performance monitoring mechanisms 363 22. A transport pseudowire OAM shall support fault management, 364 performance management and protection switching mechanisms 366 23. A transport pseudowire OAM shall be able to operate without any 367 IP functionality present. 369 24. Survivability Requirements 371 25. A transport pseudowire should support transport network-style 372 protection switching mechanisms (sub-network connection 373 protection and trail protection) 375 26. A transport pseudowire should support transport network 376 restoration mechanisms 378 27. A transport pseudowire protection switching shall be able to 379 operate without any IP functionality present. 381 Control Plane Requirements: 383 Control plane requirements are for further study. 385 9. References 387 9.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC3031] E. Rosen, A. Viswanathan, R. Callon., "Multiprotocol Label 393 Switching Architecture", RFC 3031,January 2001. 395 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 396 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 397 Encoding", RFC 3032, January 2001. 399 [RFC3270] F. Le Faucheur, Editor "Multi-Protocol Label Switching 400 (MPLS) Support of Differentiated Services", RFC3270, 401 May 2002 403 [RFC4385] S. Bryant, G. Swallow, L. Martini, D. McPherson, "Control 404 Word for Use over an MPLS PSN", RFC 4385, February 2006. 406 [RFC4446] L. Martini, "IANA Allocations for Pseudowire Edge to Edge 407 Emulation (PWE3)" RFC4446, April 2006. 409 [RFC4447] L. Martini, Ed. "Pseudowire Setup and Maintenance 410 Using the Label Distribution Protocol (LDP)", RFC4447, 411 April 2006. 413 [RFC4448] L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron, 414 "Encapsulation Methods for Transport of Ethernet over MPLS 415 Networks", RFC 4448, April 2006 417 [VCCV] T. Nadeau (Ed), "Pseudo Wire Virtual Circuit Connectivity 418 Verification (VCCV)", draft-ietf-pwe3-vccv-11.txt (work in 419 progress), October 2006. 421 9.2. Informative References 423 [ITU1] 424 https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=265 426 [ITU2] 427 http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q12/0609_sophia/wd/wd09r 428 3_editor_g8110.1v1_0909.doc 430 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge 431 (PWE3) Architecture", RFC3985, March 2005. 433 Author's Addresses 435 Stewart Bryant 436 Cisco Systems 437 250, Longwater, 438 Green Park, 439 Reading, RG2 6GB, UK 440 Email: stbryant@cisco.com 442 Monique Morrow 443 Cisco Systems, Inc. 444 Glatt-com 445 CH-8301 Glattzentrum 446 Switzerland 447 Email: mmorrow@cisco.com 449 Rao Cherukuri 450 Juniper Networks 451 1194 N. Mathilda Ave 452 Sunnyvale, CA 94089 454 Thomas D. Nadeau 455 Cisco Systems 456 300 Beaver Brook Drive 457 Boxborough, MA USA 459 Email: tnadeau@cisco.com 461 George Swallow 462 Cisco Systems, Inc. 463 1414 Massachusetts Ave 464 Boxborough, MA 01719 466 Email: swallow@cisco.com 468 Intellectual Property Statement 470 The IETF takes no position regarding the validity or scope of any 471 Intellectual Property Rights or other rights that might be claimed to 472 pertain to the implementation or use of the technology described in 473 this document or the extent to which any license under such rights 474 might or might not be available; nor does it represent that it has 475 made any independent effort to identify any such rights. Information 476 on the procedures with respect to rights in RFC documents can be 477 found in BCP 78 and BCP 79. 479 Copies of IPR disclosures made to the IETF Secretariat and any 480 assurances of licenses to be made available, or the result of an 481 attempt made to obtain a general license or permission for the use of 482 such proprietary rights by implementers or users of this 483 specification can be obtained from the IETF on-line IPR repository at 484 http://www.ietf.org/ipr. 486 The IETF invites any interested party to bring to its attention any 487 copyrights, patents or patent applications, or other proprietary 488 rights that may cover technology that may be required to implement 489 this standard. Please address the information to the IETF at 490 ietf-ipr@ietf.org. 492 Disclaimer of Validity 494 This document and the information contained herein are provided on an 495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 497 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 498 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 499 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Copyright Statement 504 Copyright (C) The Internet Society (2006). 506 This document is subject to the rights, licenses and restrictions 507 contained in BCP 78, and except as set forth therein, the authors 508 retain all their rights. 510 Acknowledgment 512 Funding for the RFC Editor function is currently provided by the 513 Internet Society.