Pseudowire Customer Edge to Customer Edge Emulation
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv
69719
ISRAEL
+972 3 6455389
yaakov_s@rad.com
Transport
PWE3
Customer Edge
ethernet access
pseudowire
Internet-Draft
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.
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
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.
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.
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.
[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