idnits 2.17.1 draft-ietf-pwe3-mpls-transport-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2009) is 5415 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-02 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-05 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft M. Morrow 4 Intended status: Informational G. Swallow 5 Expires: December 31, 2009 Cisco Systems 6 R. Cherukuri 7 Juniper Networks, 8 T. Nadeau 9 N. Harrison 10 B. Niven-Jenkins 11 BT 12 June 29, 2009 14 Application of Ethernet Pseudowires to MPLS Transport Networks 15 draft-ietf-pwe3-mpls-transport-04 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on December 31, 2009. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 A requirement has been identified by the operator community for the 64 transparent carriage of the MPLS(-TP) network of one party over the 65 MPLS(-TP) network of another party. This document describes a method 66 of satisfying this need using the existing PWE3 Ethernet pseudowire 67 standard RFC4448. 69 Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC2119 [RFC2119]. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. PWE3 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 79 3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1. VCCV profile 1: BFD without IP/UDP Headers . . . . . . . . 6 81 3.2. VCCV profile 2: BFD with IP/UDP Headers . . . . . . . . . 7 82 4. MPLS Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. External Configuration . . . . . . . . . . . . . . . . . . 7 84 4.2. Control Plane Configuration . . . . . . . . . . . . . . . 8 85 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 9 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 The operator community has identified the need for the transparent 97 carriage of the MPLS(-TP) network of one party over the MPLS(-TP) 98 network of another party [I-D.ietf-mpls-tp-requirements]. This 99 document describes one mechanism to satisfy this requirement using 100 existing IETF standards such as PWE3 Ethernet pseudowire standard 101 [RFC4448] . The mechanism described here fulfills the MPLS-TP 102 requirements for transparent carriage (MPLS-TP requirements 30 & 31) 103 of the Ethernet data plane. 105 The key purpose of this document is to demonstrate that there is an 106 existing IETF mechanism with known implementations that satisfies the 107 requirements posed by the operator community. It is recognised that 108 it is possible to design a more efficient method of satisfying the 109 requirements, and the IETF anticipates that improved solutions will 110 be proposed in the future. 112 Much of the notation used in this document is defined in [RFC3985] to 113 which the reader is referred for definitions. 115 The architecture required for this mechanism is illustrated in Figure 116 1 below. 118 +----------------------------------------------------------------+ 119 | | 120 | IP/MPLS PSN (PHP may be enabled) | 121 | (client) | 122 | | 123 | +---------------------------+ | 124 | | | | 125 | | MPLS PSN (No PHP) | | 126 | | (server) | | 127 | | | | 128 | CE1 |PE1 PE2| CE2 | 129 | +-----+ +-----+ +-----+ +-----+ | 130 | | | | | | | | | | | | | | | | | | 131 | | | | +------+ | | | | | | +------+ | | | | 132 | | | | | 802.3| | | | | | | | 802.3| | | | | 133 | +-----+ +-----+ +-----+ +-----+ | 134 | | | | | | | | | | 135 | | | +-- ---------------------- -+ | | | 136 +----- --- -------- -- ---------------------- - -------- --- ----+ 137 | | | |<--MPLS LSP (no PHP)->| | | | 138 | | | | (server) | | | | 139 | | | | | | 140 | | |<------------PW----------->| | | 141 | | | (server) | | | 142 | | | | 143 | |<-------------802.3 (Ethernet)-------------->| | 144 | | (client) | | 145 | | 146 |<---------IP/MPLS LSP (PHP may be supported)-------->| 147 | (client) | 149 Figure 1: Application Ethernet over MPLS PW to MPLS Transport 150 Networks 152 An 802.3 (Ethernet) circuit is established between CE1 and CE2. This 153 circuit may be used for the concurrent transport of MPLS packets as 154 well as IPv4 and IPv6 packets. The MPLS packets may carry IPv4, 155 IPV6, or Pseudowire payloads, and Penultimate-Hop-Popping (PHP) may 156 be used. For clarity these paths are labeled as the client in Figure 157 1. 159 An Ethernet pseudowire (PW) is provisioned between PE1 and PE2 and 160 used to carry the Ethernet from PE1 to PE2. The Ethernet PW is 161 carried over an MPLS packet switched Network (PSN), but this PSN MUST 162 NOT be configured with PHP. For clarity this Ethernet PW and the 163 MPLS PSN are labeled as the server in Figure 1. In the remainder of 164 this draft call the server network a transport network. 166 2. PWE3 Configuration 168 The PWE3 encapsulation used by this specification to satisfy the 169 transport requirement is Ethernet [RFC4448]. This is used in "raw" 170 mode. 172 The Control Word MUST be used. The Sequence number MUST be zero. 174 The use of the Pseudowire Setup and Maintenance Label Distribution 175 Protocol [RFC4447] is not required by the profile of the PWE3 176 Ethernet pseudowire functionality defined in this document. 178 The Pseudowire Label is statically provisioned. 180 3. OAM 182 Within a connection, traffic units sent from the single source are 183 constrained to stay within the connection under defect-free 184 conditions. During misconnected defects, a connection can no longer 185 be assumed to be constrained and traffic units (and by implication 186 also OAM packets) can 'leak' unidirectionally outside a connection. 187 Therefore during a misconnected state, it is not possible to rely on 188 OAM which relies on a request/response mechanism ; and, for this 189 reason such OAM should be treated with caution if used for diagnostic 190 purposes. 192 Further, when implementing an Equal Cost Multi-path (ECMP) function 193 with MPLS, use of the label stack as the path selector such that the 194 OAM and data are not in a co-path SHOULD be avoided, as any failure 195 in the data path will note be reflected in the OAM path. Therefore, 196 an OAM that is carried within the data-path below the PW label such 197 as Virtual Circuit Connectivity Verification (VCCV) is NOT vulnerable 198 to the above failure mode. For these reasons the OAM mechanism is 199 [RFC5085], using Bidirectional Forwarding Detection (BFD) 200 [I-D.ietf-bfd-base] for connection verification (CV). The method of 201 using Bidirectional Forwarding Detection (BFD) as a CV method in VCCV 202 is described in [I-D.ietf-pwe3-vccv-bfd]. One of the VCCV profiles 203 described in Section 3.1 or Section 3.2 MUST be used. Once a VCCV 204 control channel is provisioned, and the operational status of the PW 205 is UP, no other profile should be used until such time as the PW's 206 operational status is set to DOWN. 208 3.1. VCCV profile 1: BFD without IP/UDP Headers 210 When PE1 and PE1 are not IP capable or have not been configured with 211 IP addresses, the following VCCV mechanism SHOULD be used. 213 The connection verification method used by VCCV is BFD with 214 diagnostics as defined in [I-D.ietf-pwe3-vccv-bfd]. 216 [RFC5085] specifies that the first nibble is set to 0x1 to indicate a 217 channel associated with a pseudowire [RFC4385]. 219 The Version and the Reserved fields are set to zero, and the Channel 220 Type is set to 0x7 to indicate that the payload carried is BFD 221 without IP/UDP headers, as is defined in [I-D.ietf-pwe3-vccv-bfd]. 223 3.2. VCCV profile 2: BFD with IP/UDP Headers 225 When PE1 and PE1 are IP capable and have been configured with IP 226 addresses, the following VCCV mechanism may be used. 228 The connection verification method used by VCCV is BFD with 229 diagnostics as defined in [I-D.ietf-pwe3-vccv-bfd]. 231 [RFC5085] specifies that the first nibble is set to 0x1 to indicate a 232 channel associated with a pseudowire [RFC4385]. 234 The Version and the Reserved fields are set to 0, and the Channel 235 Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads [RFC4446]. 237 4. MPLS Layer 239 The architecture of MPLS enabled networks is described in [RFC3031]. 240 This section describes a subset of the functionality of the MPLS 241 enabled PSN. There are two cases that need to be considered: 243 1. The case where external configuration is used. 245 2. The case where a control plane is available. 247 Where the use of a control plane is desired this may be based on 248 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] 250 4.1. External Configuration 252 The use of external provisioning is not precluded from being 253 supported by the current MPLS specifications. It is however 254 explicitly described in this specification to address the 255 requirements specified by the ITU [I-D.ietf-mpls-tp-requirements] to 256 address the needs in a transport environment. 258 The MPLS encapsulation is specified in [RFC3032]. All MPLS labels 259 used in the server layer (Figure 1) MUST be statically provisioned. 261 Labels may be selected from either the per-platform or the per- 262 interface label space. 264 All transport Label Switched Paths (LSPs) utilized by the PWs 265 described in section 2 MUST support both unidirectional and bi- 266 directional point-to-point connections. 268 The transport LSPs SHOULD support unidirectional point-to-multipoint 269 connections. 271 The forward and backward directions of a bi-directional connection 272 SHOULD follow a symmetrically routed (reciprocal) LSP in the server 273 network. 275 Equal cost multi-path (ECMP) load balancing MUST NOT be configured on 276 the transport LSPs utilized by the PWs described in sections 2. 278 The merging of label switched paths is prohibited and MUST NOT be 279 configured for the transport LSPs utilized by the PWs described in 280 section 2. 282 Penultimate hop popping by the transport label switched routers 283 (LSRs) MUST be disabled on transport LSPs. 285 Both EXP-Inferred-PSC LSPs (E-LSP) and Label-Only-Inferred-PSC LSPs 286 (L-LSP) MUST be supported as defined in [RFC3270]. 288 For the MPLS EXP field [RFC3270] [RFC5462] only the pipe and short- 289 pipe models are supported. 291 4.2. Control Plane Configuration 293 In this section we describe the control plane configuration 294 when[RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels" or the 295 bi-directional support in GMPLS [RFC3471] "Generalized Multi-Protocol 296 Label Switching (GMPLS) Signaling Functional Description" 297 and[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 298 Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) 299 Extensions" are used to configure the transport MPLS PSN. When these 300 protocols are used to provide the control plane the following are 301 automatically provided: 303 1. There is no label merging unless it is deliberately enabled to 304 support Fast Re-route (FRR) [RFC3209]. 306 2. A single path is provided end-to-end (there is no ECMP). 308 3. Label switched paths may be unidirectional or bidirectional as 309 required. 311 Additionally the following configuration restrictions required to 312 support external configuration MUST be applied: 314 o Penultimate hop popping by the LSRs MUST be disabled on LSPs 315 providing PWE3 transport network functionality 316 [I-D.ietf-mpls-rsvp-te-no-php-oob-mapping]. 318 o Both E-LSP and L-LSP MUST be supported as defined in [RFC3270]. 320 o The MPLS EXP [RFC5462] field is supported according to [RFC3270] 321 for only when the pipe and short-pipe models are utilized. 323 5. Congestion Considerations 325 This draft describes a method of using the existing PWE3 Ethernet 326 pseudowire [RFC4448] to solve a particular network application. The 327 congestion considerations associated with that pseudowire and all 328 subsequent work on congestion considerations regarding Ethernet 329 pseudowires are applicable to this draft. 331 6. Security Considerations 333 This draft is a description of the use of existing IETF proposed 334 standards to solve a network problem, and raises no new security 335 issues. 337 The PWE3 security considerations are described in [RFC3985] and the 338 Ethernet pseudowire security considerations of[RFC4448]. 340 The Ethernet pseudowire is transported on an MPLS PSN; therefore, the 341 security of the pseudowire itself will only be as good as the 342 security of the MPLS PSN. The server MPLS PSN can be secured by 343 various methods, as described in[RFC3031]. 345 The use of static configuration exposes an MPLS PSN to a different 346 set of security risks to those found in a PSN using dynamic routing. 347 If a path is misconfigured in a statically configured network the 348 result can be a persistent black hole, or much worst, a persistent 349 forwarding loop. On the other hand most of the distributed 350 components are less complex. This is however offset by the need to 351 provide fail-over and redundancy in the management and configuration 352 system and the communications paths between those central systems and 353 the LSRs. 355 Security achieved by access control of media access control (MAC) 356 addresses , and the security of the client layers is out of the scope 357 of this document. 359 7. IANA Considerations 361 There are no IANA actions required by this draft. 363 8. Acknowledgements 365 The authors wish to thank Matthew Bocci, John Drake, Adrian Farrel, 366 Andy Malis, and Yaakov Stein for their review and proposed 367 enhancements to the text. 369 9. References 371 9.1. Normative References 373 [I-D.ietf-bfd-base] 374 Katz, D. and D. Ward, "Bidirectional Forwarding 375 Detection", draft-ietf-bfd-base-09 (work in progress), 376 February 2009. 378 [I-D.ietf-mpls-rsvp-te-no-php-oob-mapping] 379 Ali, Z. and G. Swallow, "Non PHP Behavior and out-of-band 380 mapping for RSVP-TE LSPs", 381 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-02 (work in 382 progress), March 2009. 384 [I-D.ietf-pwe3-vccv-bfd] 385 Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 386 Detection (BFD) for the Pseudowire Virtual Circuit 387 Connectivity Verification (VCCV)", 388 draft-ietf-pwe3-vccv-bfd-05 (work in progress), June 2009. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 394 Label Switching Architecture", RFC 3031, January 2001. 396 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 397 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 398 Encoding", RFC 3032, January 2001. 400 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 401 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 402 Tunnels", RFC 3209, December 2001. 404 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 405 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 406 Protocol Label Switching (MPLS) Support of Differentiated 407 Services", RFC 3270, May 2002. 409 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 410 (GMPLS) Signaling Functional Description", RFC 3471, 411 January 2003. 413 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 414 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 415 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 417 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 418 (GMPLS) Architecture", RFC 3945, October 2004. 420 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 421 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 422 Use over an MPLS PSN", RFC 4385, February 2006. 424 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 425 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 427 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 428 Heron, "Pseudowire Setup and Maintenance Using the Label 429 Distribution Protocol (LDP)", RFC 4447, April 2006. 431 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 432 "Encapsulation Methods for Transport of Ethernet over MPLS 433 Networks", RFC 4448, April 2006. 435 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 436 Connectivity Verification (VCCV): A Control Channel for 437 Pseudowires", RFC 5085, December 2007. 439 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 440 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 441 Class" Field", RFC 5462, February 2009. 443 9.2. Informative References 445 [I-D.ietf-mpls-tp-requirements] 446 Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 447 and S. Ueno, "MPLS-TP Requirements", 448 draft-ietf-mpls-tp-requirements-09 (work in progress), 449 June 2009. 451 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 452 Edge (PWE3) Architecture", RFC 3985, March 2005. 454 Authors' Addresses 456 Stewart Bryant (editor) 457 Cisco Systems 458 250, Longwater, Green Park, 459 Reading RG2 6GB, UK 460 UK 462 Email: stbryant@cisco.com 464 Monique Morrow 465 Cisco Systems 466 Glatt-com 467 CH-8301 Glattzentrum 468 Switzerland 470 Email: mmorrow@cisco.com 472 George Swallow 473 Cisco Systems 474 1414 Massachusetts Ave 475 Boxborough, MA 01719 477 Email: swallow@cisco.com 479 Rao Cherukuri 480 Juniper Networks, 481 1194 N. Mathilda Ave 482 Sunnyvale CA 94089 484 Thomas D. Nadeau 485 BT 487 Email: tom.nadeau@bt.com 488 Neil Harrison 489 BT 491 Email: neil.2.harrison@bt.com 493 Ben Niven-Jenkins 494 BT 495 208 Callisto House, Adastral Park 496 Ipswich, Suffolk IP5 3RE 497 UK 499 Phone: 500 Fax: 501 Email: benjamin.niven-jenkins@bt.com 502 URI: