- VPLS allows the PE to use addressing information in a frame’s L2
header to determine how to forward the frame; and
- VPLS allows a single CE/PE connection to be used for
transmitting frames to multiple remote CEs; in this particular
respect, VPLS resembles L3VPN more than VPWS.
Requirements for this type of L2VPN are specified in [RFC4665].
3.1.3. IP-Only LAN-Like Service (IPLS)
An IPLS is very like a VPLS, except that:
- it is assumed that the CE devices are hosts or routers, not
switches; and
- it is assumed that the service will only carry IP packets and
supporting packets such as ICMP and ARP (in the case of IPv4) or
Neighbor Discovery (in the case of IPv6); Layer 2 packets that
do not contain IP are not supported.
While this service is a functional subset of the VPLS service, it is
considered separately because it may be possible to provide it using
different mechanisms, which may allow it to run on certain hardware
platforms that cannot support the full VPLS functionality.
3.2. Generic L2VPN Transport Functional Components
All L2VPN types must transport "frames" across the core network
connecting the PEs. In all L2VPN types, a PE (PE1) receives a frame
from a CE (CE1), and then transports the frame to a PE (PE2), which
then transports the frame to a CE (CE2). In this section, we discuss
the functional components that are necessary to transport L2 frames
in any type of L2VPN service.
3.2.1. Attachment Circuits
In any type of L2VPN, a CE device attaches to a PE device via some
sort of circuit or virtual circuit. We will call this an "Attachment
Circuit" (AC). We use this term very generally; an Attachment
Circuit may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port,
a VLAN, a PPP connection on a physical interface, a PPP session from
an L2TP tunnel, an MPLS LSP, etc. The CE device may be a router, a
switch, a host, or just about anything, which the customer needs
hooked up to the VPN. An AC carries a frame between CE and PE, or
vice versa.
Procedures for setting up and maintaining the ACs are out of scope of
this architecture.
These procedures are generally specified as part of the specification
of the particular Attachment Circuit technology.
Any given frame will traverse an AC from a CE to a PE, and then on
another AC from a PE to a CE.
We refer to the former AC as the frame’s "ingress AC" and to the
latter AC as the frame’s "egress AC". Note that this notion of
"ingress AC" and "egress AC" is relative to a specific frame and
denotes nothing more than the frame’s direction of travel while it is
on that AC.
3.2.2. Pseudowires
A "Pseudowire" (PW) is a relation between two PE devices. Whereas an
AC is used to carry a frame from CE to PE, a PW is used to carry a
frame between two PEs. We use the term "pseudowire" in the sense of
[RFC3985].
Setting up and maintaining the PWs is the job of the PEs. State
information for a particular PW is maintained at the two PEs that are
its endpoints, but not at other PEs, and not in the backbone routers
(P routers).
Pseudowires may be point-to-point, multipoint-to-point, or point-to-
multipoint. In this framework, point-to-point PWs are always
considered bidirectional; multipoint-to-point and point-to-multipoint
PWs are always considered unidirectional. Multipoint-to-point PWs
can be used only when the PE receiving a frame does not need to
infer, from the PW on which the frame was received, the identity of
the frame’s ingress AC. Point-to-multipoint PWs may be useful when
frames need to be multicast.
Procedures for setting up and maintaining point-to-multipoint PWs are
not considered in this version of this framework.
Any given frame travels first on its ingress AC, then on a PW, and
then on its egress AC.
Multicast frames may be replicated by a PE, so of course the
information carried in multicast frames may travel on more than one
PW and more than one egress AC.
Thus with respect to a given frame, a PW may be said to associate a
number of ACs. If these ACs are of the same technology (e.g., both
ATM, both Ethernet, both Frame Relay), the PW is said to provide
"homogeneous transport"; otherwise it is said to provide
"heterogeneous transport". Heterogeneous transport requires that
some sort of interworking function be applied. There are at least
three different approaches to interworking:
1. One of the CEs may perform the interworking locally. For
example, if CE1 attaches to PE1 via ATM, but CE2 attaches to
PE2 via Ethernet, then CE1 may decide to send/receive
Ethernet frames over ATM, using the RFC 2684, "LLC
Encapsulation for Bridged Protocols". In such a case, PE1
would need to know that it is to terminate the ATM VC
locally, and only to send/receive Ethernet frames over the
PW.
2. One of the PEs may perform the interworking. For example, if
CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via
Frame Relay, PE1 may provide the "ATM/FR Service
Interworking" function. This would be transparent to the
CEs, and the PW would carry only Frame Relay frames.
3. IPLS could be used. In this case, the "frames" carried by
the PW are IP datagrams, and the two PEs need to cooperate in
order to spoof various L2-specific procedures used by IP (see
Section 3.5).
If heterogeneous PWs are used, the setup protocol must ensure that
each endpoint knows the MTU of the remote AC. If the two ACs do not
have the same MTU, one of the following three procedures must be
carried out:
- The PW is not allowed to come up.
- The endpoint at the AC with the larger MTU must reduce the AC’s
MTU so that it is the same as the MTU of the remote AC.
- The two endpoints must agree to use a specified
fragmentation/reassembly procedure.
3.2.3. Forwarders
In all types of L2VPN, a PE (say, PE1) receives a frame over an AC
and forwards it over a PW to another PE (say, PE2). PE2 then
forwards the frame out on another AC.
The case in which PE1 and PE2 are the same device is an important
case to handle correctly, in order to provide the L2VPN service
properly. However, as this case does not require any protocol, we do
not address it further in this document.
When PE1 receives a frame on a particular AC, it must determine the
PW on which the frame must be forwarded. In general, this is done by
considering:
- the incoming AC;
- possibly the contents of the frame’s Layer2 header; and
- possibly some forwarding information that may be statically or
dynamically maintained.
If dynamic or static forwarding information is considered, the
information is specific to a particular L2VPN instance (i.e., to a
particular VPN).
Similarly, when PE2 receives a frame on a particular PW, it must
determine the AC on which the frame must be forwarded. This is done
by considering:
- the incoming PW;
- possibly the contents of the frame’s Layer2 header; and
- possibly some forwarding information that may be statically or
dynamically maintained.
If dynamic or static forwarding information is considered, the
information is specific to a particular L2VPN instance (i.e., to a
particular VPN).
The procedures used to make the forwarding decision are known as a
"forwarder". We may think of a PW as being "bound", at each of its
endpoints, to a forwarder. The forwarder in turn "binds" the PWs to
ACs. Different types of L2VPN have different types of forwarders.
For instance, a forwarder may bind a single AC to a single PW,
ignoring all frame contents and using no other forwarding
information. Or a forwarder may bind an AC to a set of PWs and ACs,
moving individual frames from AC to PW, from a PW to an AC or from AC
to AC by comparing information from the frame’s Layer2 header to
information in a forwarding database. This is discussed in more
detail below, as we consider the different L2VPN types.
3.2.4. Tunnels
A PW is carried in a "tunnel" from PE1 to PE2. We assume that an
arbitrary number of PWs may be carried in a single tunnel; the only
requirement is that the PWs all terminate at PE2.
We do not even require that all the PWs in the tunnel originate at
PE1; the tunnels may be multipoint-to-point tunnels. Nor do we
require that all PWs between the same pair of PEs travel in the same
tunnel. All we require is that when a frame traveling through such a
tunnel arrives at PE2, PE2 will be able to associate it with a
particular PW.
(While one can imagine tunneling techniques that only allow one PW
per tunnel, they have evident scalability problems, and we do not
consider them further.)
A variety of different tunneling technologies may be used for the
PE-PE tunnels. All that is really required is that the tunneling
technologies allow the proper demultiplexing of the contained PWs.
The tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS-
in-IP tunnels, etc. Generally the tunneling technology will require
the use of an encapsulation that contains a demultiplexor field,
where the demultiplexor field is used to identify a particular PW.
Procedures for setting up and maintaining the tunnels are not within
the scope of this framework. (But see Section 3.2.6, "Pseudowire
Signaling".)
If there are multiple tunnels from PE1 to PE2, it may be desirable to
assign a particular PE1-PE2 PW to a particular tunnel based on some
particular characteristics of the PW and/or the tunnel. For example,
perhaps different tunnels are associated with different QoS
characteristics, and different PWs require different QoS. Procedures
for specifying how to assign PWs to tunnels are out of scope of the
current framework.
Though point-to-point PWs are bidirectional, the tunnels in which
they travel need not be either bidirectional or point-to-point. For
example, a point-to-point PW may travel within a unidirectional
multipoint-to-point MPLS LSP.
3.2.5. Encapsulation
As L2VPN packets are carried in pseudowires, standard pseudowire
encapsulation formats and techniques (as specified by the IETF’s PWE3
WG) should be used wherever applicable.
Generally the PW encapsulations will themselves be encapsulated
within a tunnel encapsulation, as determined by the specification of
the tunneling protocol.
It may be necessary to define additional PW encapsulations to cover
areas that are of importance for L2VPN, but that may not be within
the scope of PWE3. Heterogeneous transport may be an instance of
this.
3.2.6. Pseudowire Signaling
Procedures for setting up and maintaining the PWs themselves are
within the scope of this framework. This includes procedures for
distributing demultiplexor field values, even though the
demultiplexor field, strictly speaking, belongs to the tunneling
protocol and not to the PW.
The signaling for a point-to-point pseudowire must perform the
following functions:
- Distribution of the demultiplexor.
Since many PWs may be carried in a single tunnel, the tunneling
protocol must assign a demultiplexor value to each PW. These
demultiplexors must be unique with respect to a given tunnel
(or, with some tunneling technologies, unique at the egress PE).
Generally, the PE that is the egress of the tunnel will select
the demultiplexor values and will distribute them to the PE(s)
which is (are) the ingress(es) of the tunnel. This is the
essential part of the PW setup procedure.
Note that, as is usually the case in tunneling architectures,
the demultiplexor field belongs to the tunneling protocol, not
to the protocol being tunneled. For this reason, the PW setup
protocols may be extensions of the control protocols for setting
up the tunnels.
- Selection of the Forwarder at the remote PE.
The signaling protocol must contain enough information to enable
the remote PE to select the proper forwarder to which the PW is
to be bound. We can call this information the "Remote Forwarder
Selector". The information that is required will depend on the
type of L2VPN being provided and on the provisioning model being
used (see Sections 3.3.1 and 3.4.2). The Remote Forwarder
Selector may uniquely identify a particular Forwarder, or it may
identify an attribute of Forwarders. In the latter case, it
would select whichever Forwarder has been provisioned with that
attribute.
- Supporting pseudowire emulations.
To the extent that a particular PW must emulate the signaling of
a particular Layer2 technology, the PW signaling must provide
the necessary functions.
- Distribution of state changes.
Changes in the state of an AC may need to be reflected in
changes to the state of the PW to which the AC is bound, and
vice versa. The specification as to which changes need to be
reflected in what way would generally be within the province of
the PWE3 WG.
- Establishing pseudowire characteristics.
To the extent that one or more characteristics of a PW must be
known to and/or agreed upon by both endpoints, the signaling
must allow for the necessary interaction.
As specified above, signaling for point-to-point PWs must pass enough
information to allow a remote PE to properly bind a PW to a
Forwarder, and to associate a particular demultiplexor value with
that PW. Once the two PEs have done the proper PW/Forwarder
bindings, and have agreed on the demultiplexor values, the PW may be
considered set up. If it is necessary to negotiate further
characteristics or parameters of a particular PW, or to pass status
information for a particular PW, the PW may be identified by the
demultiplexor value.
Signaling procedures for point-to-point pseudowires are most commonly
point-to-point procedures that are executed by the two PW endpoints.
There are, however, proposals to use point-to-multipoint signaling
for setting up point-to-point pseudowires, so this is included in the
framework. When PWs are themselves point-to-multipoint, it is also
possible to use either point-to-point signaling or point-to-
multipoint signaling to set them up. This is discussed in the
remainder of this section.
3.2.6.1. Point-to-Point Signaling
There are several ways to do the necessary point-to-point signaling.
Among them are:
- LDP
LDP [RFC3036] extensions can be defined for pseudowire
signaling. This form of signaling can be used for pseudowires
that are to be carried in MPLS "tunnels", or in MPLS-in-
something-else tunnels.
- L2TP
L2TP [RFC2661] can be used for pseudowire signaling, resulting
in pseudowires that are carried as "sessions" within L2TP
tunnels. Pseudowire-specific extensions to L2TP may also be
needed.
Other methods may be possible as well.
It is possible to have one control connection between a pair of PEs,
which is used to control many PWs.
The use of point-to-point signaling for setting up point-to-point PWs
is straightforward. Multipoint-to-point PWs can also be set up by
point-to-point signaling, as the remote PEs do not necessarily need
to know whether the PWs are multipoint-to-point or point-to-point.
In some signaling procedures, the same demultiplexor value may be
assigned to all the remote PEs.
3.2.6.2. Point-to-Multipoint Signaling
Consider the following conditions:
- It is necessary to set up a set of PWs, all of which have the
same characteristics.
- It is not necessary to use the PW signaling protocol to pass PW
state changes.
- For each PW in the set, the same value of the Remote Forwarder
Selector can be used.
Call these the "Environmental Conditions".
Suppose also that there is some mechanism by which, given a range of
demultiplexor values, each of a set of PEs can make a unique and
deterministic selection of a single value from within that range.
Call this the "Demultiplexor Condition". Alternatively, suppose that
one is trying to set up a multipoint-to-point PW rather than to set
up a point-to-point PW. Call this the "Multipoint Condition".
If:
- The Environmental Conditions hold; and
- Either
* the Demultiplexor Condition holds, or
* the Multipoint Condition holds,
then for a given set of PWs that terminate at egress PE1, the
information that PE1 needs to send to the ingress PE(s) of each
pseudowire in the set is exactly the same. All the ingress PE(s)
receive the same Forwarder Selector value. They all receive the same
set of PW parameters (if any). And either they all receive the same
demultiplexor value (if the PW is multipoint-to-point) or they all
receive a range of demultiplexor values from which each can choose a
unique demultiplexor value for itself.
Rather than connect to each ingress PE and replicate the same
information, it may make sense either to multicast the information,
or to send the information once to a "reflector", which will then
take responsibility for distributing the information to the other
PEs.
We refer to this sort of technique as "point-to-multipoint"
signaling. It would, for example, be possible to use BGP [RFC1771]
to do the signaling, with PEs that are BGP peers not of each other,
but of one or more BGP route reflectors [RFC2796].
3.2.6.3. Inter-AS Considerations
Pseudowires may need to run from a PE in one Service Provider’s
network to a PE in another Service Provider’s network. This has the
following implications:
- The signaling protocol that sets up the PWs must be able to
cross network boundaries. Of course, all IP-based protocols
have this capability.
- The two PEs at the PW endpoints must be addressable and routable
from each other.
- The signaling protocol needs to allow each PW endpoint to
authenticate the other. To make use of the authentication
capability, there would also need to be some method of key
distribution that is acceptable to both administrations.
3.2.7. Service Quality
Service Quality refers to the ability for the network to deliver a
Service level Specification (SLS) for service attributes such as
protection, security, and Quality of Service (QoS). The service
quality provided depends on the subscriber’s requirements and can be
characterized by a number of performance metrics.
The necessary Service Quality must be provided on the ACs, as well as
on the PWs. Mechanisms for providing Service Quality on the PWs may
be PW-specific or tunnel-specific; in the latter case, the assignment
of a PW to a tunnel may depend on the Service Quality.
3.2.7.1. Quality of Service (QoS)
QoS describes the queuing behavior applied to a particular "flow", in
order to achieve particular goals of precedence, throughput, delay,
jitter, etc.
Based on the customer Service Level Agreement (SLA), traffic from a
customer can be prioritized, policed, and shaped for QoS
requirements. The queuing and forwarding policies can preserve the
packet order and QoS parameters of customer traffic. The class of
services can be mapped from information in the customer frames, or it
can be independent of the frame content.
QoS functions can be listed as follows:
- Customer Traffic Prioritization: L2VPN services could be best
effort or QoS guaranteed. Traffic from one customer might need
to be prioritized over others when sharing same network
resources. This requires capabilities within the L2VPN solution
to classify and mark priority to QoS guaranteed customer
traffic.
- Proper queuing behavior would be needed at the egress AC, and
possibly within the backbone network as well. If queuing
behavior must be controlled within the backbone network, the
control might be based on CoS information in the MPLS or IP
header, or it might be achieved by nesting particular tunnels
within particular traffic engineering tunnels.
- Policing: This ensures that a user of L2VPN services uses
network resources within the limits of the agreed SLA. Any
excess L2VPN traffic can be rejected or handled differently
based on provider policy.
- Policing would generally be applied at the ingress AC.
- Shaping: Under some cases, the random nature of L2VPN traffic
might lead to sub-optimal utilization of network resources.
Through queuing and forwarding mechanisms, the traffic can be
shaped without altering the packet order.
- Shaping would generally be applied at the ingress AC.
3.2.7.2. Resiliency
Resiliency describes the ability of the L2VPN infrastructure to
protect a flow from network outage, so that service remains available
in the presence of failures.
L2VPN, like any other service, is subject to failures such as link,
trunk, and node failures, both in the SP’s core network
infrastructure and on the ACs.
It is desirable that the failure be detected "immediately" and that
protection mechanisms allow fast restoration times to make L2VPN
service almost transparent to these failures to the extent possible,
based on the level of resiliency. Restoration should take place
before the CEs can react to the failure. Essential aspects of
providing resiliency are:
- Link/Node failure detection: Mechanisms within the L2VPN service
should allow for link or node failures that impact the service,
and that should be detected immediately.
- Resiliency policy: The way in which a detected failure is
handled will depend on the restoration policy of the SLA
associated with the L2VPN service specification. It may need to
be handled immediately, or it may need to be handled only if no
other critical failure needs protection resources, or it may be
completely ignored if it is within the bounds of the "acceptable
downtime" allowed by the L2VPN service.
- Restoration Mechanisms: The L2VPN solutions could allow for
physical level protection, logical level protection, or both.
For example, by connecting customers over redundant and
physically separate ACs to different provider customer-facing
devices, one AC can be maintained as active, and the other could
be marked as a backup; upon the failure detection across the
primary AC, the backup could become active.
To a great extent, resiliency is a matter of having appropriate