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]