PWE3 Y(J) Stein Internet-Draft RAD Data Communications Expires: April 19, 2004 October 20, 2003 Pseudowire Customer Edge to Customer Edge Emulation draft-stein-pwe3-pwce2e-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The PWE3 architecture document places the interworking function solely in the PE, so that the attachment circuit between PE and CE carries the native service. This is appropriate for a service provider that offers the customer a seamless alternative for transporting the native service. An alternative is to place the interworking function in the CE, with ethernet access from CE to PE. We present advantages of this approach and note required changes to the PWE architecture. Stein Expires April 19, 2004 [Page 1] Internet-Draft PWCE2E October 2003 1. Introduction In VPN architectures provider edge routers communicate with customer edge routers, and both types of routers carry essentially the same service (e.g. IP). The PWE model is an extension of this architecture, but while the provider has a IP or MPLS packet switched network, the customer's network is some native service, e.g. ATM, frame-relay, or TDM. In order to transport the customer's traffic over the provider's PSN, an interworking function is required. The PWE architecture as detailed in [PWE-arch] places this interworking function in the PE. The emulation of the native service is thus "edge to edge", meaning provider edge to provider edge. We can call this pseudowire provider edge to provider edge emulation, or PWPE2E. The reasoning behind this placement of the interworking function is clear. The customer is assumed to have had a native service provider, and to have connected to this provider via a native service attachment circuit. Hence the new service provider deploying a PWE network and wishing to provide a seamless migration path, naturally offers to accept the native service attachment circuit. In this way no modification of the customer premises equipment is required, and the customer may even be unaware of the different transport mode of the new provider. However, this is not the only possible placement of the interworking function. For reasons discussed in Section 2 below, it is frequently more sensible to place the interworking function at the CE instead. In that case the CE to PE connection is of the PSN type, rather than of the native service, and the emulation is from CE to CE. With can thus call this variant pseudowire customer edge to customer edge emulation, or PWCE2E. Although the traffic type of the attachment circuit tends to distinguish between PWPE2E and PWCE2E, this differentiation is not sufficient. In a possible scenario the interworking function itself, although located at the customer's site, is under control of the provider. In this case it essentially functions as a user located PE, and participates in provider network signaling. In the true PWCE2E case the interworking function belongs to the customer, and the provider may be unaware of its existence. All provider network signaling is carried out at the remote PE, as in the standard PWE model [PWE-ctrl]. A provider may offer both PWPE2E and PWCE2E connections. A single end to end emulation may be PWPE2E on one side and PWCE2E on the other. Stein Expires April 19, 2004 [Page 2] Internet-Draft PWCE2E October 2003 2. Motivations for PWCE2E Why should the interworking be performed before the attachment circuit? There are various reasons. The first is to take advantage of ethernet access. Ethernet access is becoming widely available and may prove less expensive to the customer than ATM or frame relay access links. Standardization of ethernet in the first mile and metro ethernet networks is being advanced by several forums, and the models being developed in these forums are tbus different from the PWE model. Ethernet access may particularly appeal to customers who did not previously contract with service providers for their non-ethernet services. In the PWPE2E model the interworking function tends to be a large gateway, built to serve large numbers of customers. It may not be viable for a provider to install a large gateway when only a few customers are interested in a particular service. In such cases a small customer located gateway may be desirable. An advantage of the PWCE2E model is that customer edge to customer edge OAM and performance measurement is natural here, while the parallel functionalities for the PWPE2E case cover only the provider network, and not the attachment circuits. Stein Expires April 19, 2004 [Page 3] Internet-Draft PWCE2E October 2003 3. Implications When the PSN is IP, no user protocol enhancements are required for PWCE2E. The IP header, demultiplexing label, control word, and payload are sent from CE to PE as described in the present service specific encapsulation documents. For the MPLS case, IP access is also possible, with the CE converting the native service into IP packets. The PE then prepends MPLS labels and the packet is forwarded as any other MPLS-labeled IP packet. This would result in inefficient transport, and circumvents the PWE mechanisms for MPLS. The ideal way of handling a PWCE2E packet is to have the CE perform the service specific encapsulation and to prepend the (inner) PW label, but no (outer) MPLS transport labels. The PE, which participates in the provider network signaling, then adds the appropriate MPLS labels as required. This capability of accepting non-IP MPLS-like packets is not presently available in MPLS LERs nor in PWE PEs. Its advantage is its universality. Equipped with this feature any edge router can participate in PWE applications without being aware of service specific details. Other than defining this capability, only minor changes to the present PWE documents are needed to add PWCE2E functionality. Figure 2 of the architecture document (PWE3 Network Reference Model) would need to be slightly enhanced, and the term "CE-bound" would need to be changed. Stein Expires April 19, 2004 [Page 4] Internet-Draft PWCE2E October 2003 4. References [PWE-arch] draft-ietf-pwe3-arch-06.txt (2003) PWE3 Architecture, S. Bryant, P. Pate, work in progress [PWE-ctrl] draft-ietf-pwe3-control-protocol-04.txt (2003) Pseudowire Setup and Maintenance using LDP, L. Martini et al, work in progress Author's Address Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL Phone: +972 3 6455389 EMail: yaakov_s@rad.com Stein Expires April 19, 2004 [Page 5] Internet-Draft PWCE2E October 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stein Expires April 19, 2004 [Page 6]