[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]