failure and recovery mechanisms in the network core, including
"ordinary" adaptive routing as well as "fast reroute" capabilities.
The ability to support redundant ACs between CEs and PEs also plays a
role.
3.2.8. Management
An L2VPN solution can provide mechanisms to manage and monitor
different L2VPN components. From a Service Level Agreement (SLA)
perspective, L2VPN solutions could allow monitoring of L2VPN service
characteristics and offer mechanisms used by Service Providers to
report such monitored statistical data. Trouble-shooting and
verification of operational and maintenance activities of L2VPN
services are essential requirements for Service Providers.
3.3. VPWS
A VPWS is an L2VPN service in which each forwarder binds exactly one
AC to exactly one PW. Frames received on the AC are transmitted on
the PW; frames received on the PW are transmitted on the AC. The
content of a frame’s Layer2 header plays no role in the forwarding
decision, except insofar as the Layer2 header contents are used to
associate the frame with a particular AC (e.g., the DLCI field of a
Frame Relay frame identifies the AC).
A particular combination of <AC, PW, AC> forms a "virtual circuit"
between two CE devices.
A particular VPN (VPWS instance) may be thought of as a collection of
such virtual circuits, or as an "overlay" of PWs on the MPLS or IP
backbone. This creates an overlay topology that is in effect the
"virtual backbone" of a particular VPN.
Whether two virtual circuits are said to belong to the same VPN or
not is an administrative matter based on the agreements between the
SPs and their customers. This may impact the provisioning model
(discussed below). It may also affect how particular PWs are
assigned to tunnels, the way QoS is assigned to particular ACs and
PWs, etc.
Note that VPWS makes use of point-to-point PWs exclusively.
3.3.1. Provisioning and Auto-Discovery
Provisioning a VPWS is a matter of:
1. Provisioning the ACs;
2. Providing the PEs with the necessary information to enable
them to set up PWs between ACs to result in the desired
overlay topology; and
3. Configuring the PWs with any necessary characteristics.
3.3.1.1. Attachment Circuit Provisioning
In many cases, the ACs must be individually provisioned on the PE
and/or CE. This will certainly be the case if the CE/PE attachment
technology is a switched network, such as ATM or FR, and the VCs are
PVCs rather than SVCs. It is also the case whenever the individual
Attachment Circuits need to be given specific parameters (e.g., QoS
parameters, guaranteed bandwidth parameters) that differ from circuit
to circuit.
There are also cases in which ACs might not have to be individually
provisioned. For example, if an AC is just an MPLS LSP running
between a CE and a PE, it could be set up as the RESULT of setting up
a PW rather than having to be provisioned BEFORE the PW can be set
up. The same may apply whenever the AC is a Switched Virtual Circuit
of any sort, though in this case, various policy controls might need
to be provisioned; e.g., limiting the number of ACs that can be set
up between a given CE and a given PE.
Issues such as whether the Attachment Circuits need to be
individually provisioned or not, whether they are Switched VCs or
Permanent VCs, and what sorts of policy controls may be applied are
implementation and deployment issues and are considered to be out of
scope of this framework.
3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies
In order to support arbitrary overlay topologies, it is necessary to
allow the provisioning of individual PWs. In this model, when a PW
is provisioned on a PE device, it is locally bound to a specific AC.
It is also provisioned with information that identifies a specific AC
at a remote PE.
There are basically two variations of this provisioning model:
- Two-sided provisioning
With two-sided provisioning, each PE that is at the end of a PW
is provisioned with the following information:
* Identifier of the Local AC to which the PW is to be bound
* PW type and parameters
* IP address of the remote PE (i.e., the PE that is to be at
the remote end of the PW)
* Identifier that is meaningful to the remote PE, and that can
be passed in the PW signaling protocol to enable the remote
PE to bind the PW to the proper AC. This can be an
identifier of the PW or an identifier of the remote AC. If
a PW identifier is used, it must be unique at each of the
two PEs. If an AC identifier is used, it need only be
unique at the remote PE.
This identifier is then used as the Remote Forwarder Selector
when signaling is done (see 3.2.6.1).
- Single-sided provisioning
With single-sided provisioning, a PE at one end of a PW is
provisioned with the following information:
* Identifier of the Local AC to which the PW is to be bound
* PW type and parameters
* Globally unique identifier of remote AC
This identifier is then used as the Forwarder Selector when
signaling is done (see section 3.2.6.1).
In this provisioning model, the IP address of the remote PE is
not provisioned. Rather, the assumption is that an auto-
discovery scheme will be used to map the globally unique
identifier to the IP address of the remote PE, along with an
identifier (perhaps unique only at the latter PE) for an AC at
that PE. The PW signaling protocol can then make a connection
to the remote PE, passing the AC identifier, so that the remote
PE binds the PW to the proper AC.
This scheme requires provisioning of the PW at only one PE, but
it does not eliminate the need (if there is a need) to provision
the ACs at both PEs.
These provisioning models fit well with the use of point-to-point
signaling. When each PW is individually provisioned, as the
conditions necessary for the use of point-to-multipoint signaling do
not hold.
3.3.1.3. Colored Pools PW Provisioning Model
Suppose that at each PE, sets of ACs are gathered together into
"pools", and that each such pool is assigned a "color". (For
example, a pool might contain all and only the ACs from this PE to a
particular CE.) Now suppose that we impose the following rule:
whenever PE1 and PE2 have a pool of the same color, there will be a
PW between PE1 and PE2 that is bound at PE1 to an arbitrarily chosen
AC from that pool, and at PE2 to an arbitrarily chosen AC from that
pool. (We do not rule out the case where a single PE has multiple
pools of a given color.)
For example, each pool in a particular PE might represent a
particular CE device, for which the ACs in the pool are the ACs
connecting that CE to that PE. The color might be a VPN-id.
Application of this provisioning model would then lead to a full CE-
to-CE mesh within the VPN, where every CE in the VPN has a virtual
circuit to every other CE within the VPN.
More specifically, to provision VPWS according to this model, one
provisions a set of pools and configures each pool with the following
information:
- The set of ACs that belong to the pool (with no AC belonging to
more than one pool)
- The color
- A pool identifier that is unique at least relative to the color.
An auto-discovery procedure is then used to map each color into
a list of ordered pairs <IP address of PE, pool id>. The
occurrence of a pair <X, Y> on this list means that the PE at IP
address X has a pool with pool id Y, which is of the specified
color.
This information can be used to support several different
signaling techniques. One possible technique proceeds as
follows:
- A PE finds that it has a pool of color C.
- Using auto-discovery, it obtains the set of ordered pairs <X,Y>
for color C.
- For each such pair <X,Y>, it:
* removes an AC from the pool;
* binds the AC to a particular PW; and
* signals PE X via point-to-point signaling that the PW is to be
bound to an AC from pool Y.
Another possible signaling technique is the following:
- A PE finds that it has a pool of color C, containing n ACs.
- It binds each AC to a PW, creating a set of PWs. This set of
PWs is then organized into a sequence. (For instance, each PW
may be associated with a demultiplexor field value, and the PWs
may then be sequenced according to the numerical value of their
respective demultiplexors.)
- Using auto-discovery, it obtains the list of PE routers that
have one or more pools of color C.
- It signals each such PE router, specifying the sequence Q of
PWs.
- If PE X receives such a signal and PE X has a pool Y of the
specified color, it:
* removes an AC from the pool; and
* binds the AC to the PW that is the "Yth" PW in the sequence Q.
This presumes, of course, that the pool identifiers are or can be
uniquely mapped into small ordinal numbers; assigning the pool
identifiers in this way becomes a requirement of the provisioning
system.
Note that since this technique signals the same information to all
the remote PEs, it can be supported via point-to-multipoint
signaling.
This provisioning model can be applied as long as the following
conditions hold:
- There is no need to provision different characteristics for the
different PWs;
- It makes no difference which pairs of ACs are bound together by
PWs, as long as both ACs in the pair come from like-colored
pools; and
- It is possible to construct the desired overlay topology simply
by assigning colors to the pools. (This is certainly simple if
a full mesh is desired, or if a hub and spoke configuration is
desired; creating arbitrary topologies is less simple, and is
perhaps not always possible.)
3.3.2. Requirements on Auto-Discovery Procedures
Some of the requirements for auto-discovery procedures can be deduced
from the above.
To support the single-sided provisioning model, auto-discovery must
be able to map a globally unique identifier (of a PW or of an
Attachment Circuit) to an IP address of a PE.
To support the colored pools provisioning model, auto-discovery must
enable a PE to determine the set of other PEs that contain pools of
the same color.
These requirements enable the auto-discovery scheme to provide the
information, which the PEs need to set up the PWs.
There are additional requirements on the auto-discovery procedures
that cannot simply be deduced from the provisioning model:
- Particular signaling schemes may require additional information
before they can proceed and hence may impose additional
requirements on the auto-discovery procedures.
- A given Service Provider may support several different types of
signaling procedures, and thus the PEs may need to learn, via
auto-discovery, which signaling procedures to use.
- Changes in the configuration of a PE should be reflected by the
auto-discovery procedures, within a timely manner, and without
the need to explicitly reconfigure any other PE.
- The auto-configuration procedures must work across service
provider boundaries. This rules out, e.g., use of schemes that
piggyback the auto-discovery information on the backbone’s IGP.
3.3.3. Heterogeneous Pseudowires
Under certain circumstances, it may be desirable to have a PW that
binds two ACs that use different technologies (e.g., one is ATM, one
is Ethernet). There are a number of different ways, depending on the
AC types, in which this can be done. For example:
- If one AC is ATM and one is FR, then standard ATM/FR Network
Interworking can be used. In this case, the PW might be
signaled for ATM, where the Interworking function occurs between
the PW and the FR AC.
- A common encapsulation can be used on both ACs, if for example,
one AC is Ethernet and one is FR, an "Ethernet over FR"
encapsulation can be used on the latter. In this case, the PW
could be signaled for Ethernet, with processing of the Ethernet
over FR encapsulation local to the PE with the FR AC.
- If it is known that the two ACs attach to IP routers or hosts
and carry only IP traffic, then one could use a PW that carries
the IP packets, and the respective Layer2 encapsulations would
be local matters for the two PEs. However, if one of the ACs is
a LAN and one is a point-to-point link, care would have to be
taken to ensure that procedures such as ARP and Inverse ARP are
properly handled; this might require some signaling, and some
proxy functions. Further, if the CEs use a routing algorithm
that has different procedures for LAN interfaces than those for
point-to-point interfaces, additional mechanisms may be required
to ensure proper interworking.
3.4. VPLS Emulated LANs
A VPLS is an L2VPN service in which:
- the ACs attach CE devices to PE bridge modules; and
- each PE bridge module is attached via an "emulated LAN
interface" to an "emulated LAN".
This is shown in Figure 3.
In this section, we examine the functional decomposition of the VPLS
Emulated LAN. An Emulated LAN’s ACs are the "emulated LAN
interfaces" attaching PE bridge modules to the "VPLS Forwarder"
modules (see Figure 3). The payload on the ACs consists of ethernet
frames, with or without VLAN headers.
A given VPLS Forwarder in a given PE will have multiple ACs only if
there are multiple bridge modules in that PE that attach to that
Forwarder. This scenario is included in the Framework, though
discussion of its utility is out of scope.
The set of VPLS Forwarders within a single VPLS are connected via
PWs. Two VPLS Forwarders will have a PW between them only if those
two Forwarders are part of the same VPLS. (There may be a further
restriction that two VPLS Forwarders have a PW between them only if
those two Forwarders belong to the same VLAN in the same VPN.) A
particular set of interconnected VPLS Forwarders is what constitutes
a VPLS Emulated LAN.
On a real LAN, any frame transmitted by one entity is received by all
the others. A VPLS Emulated LAN, however, behaves somewhat
differently. When a VPLS Forwarder receives a unicast frame over one
of its Emulated LAN interfaces, the Forwarder does not necessarily
send the frame to all the other Forwarders on that Emulated LAN. A
unicast frame needs to be sent to only one other Forwarder in order
to be properly delivered to its destination MAC address. If the
transmitting Forwarder knows which other Forwarder needs to receive a
particular unicast frame, it will send the frame to just that one
Forwarder. This forwarding optimization is an important part of any
attempt to provide a VPLS service over a wide-area or metropolitan
area network.
In effect, then, each Forwarder behaves as a "Virtual Switch
Instance" (VSI), maintaining a forwarding table that maps MAC
addresses to PWs. The VSI is populated in much the same way that a
standard bridge populates its forwarding table. The VPLS Forwarders
do MAC Source Address (SA) learning on frames received on PWs from
other Forwarders and must also do the related set of procedures, such
as aging out address entries. Frames with unknown DAs or multicast
DAs must be "broadcast" by one Forwarder to all the others (on the
same emulated LAN). There are, however, a few important differences
between the VPLS Forwarder VSI and the standard bridge forwarding
function:
- A VPLS Forwarder never learns the MAC SAs of frames that it
receives on its ACs; it only learns the MAC SAs of frames that
are received on PWs from other VPLS Forwarders; and
- The VPLS Forwarders of a particular emulated LAN do not
participate in a spanning tree protocol with each other. A
"split horizon" technique is used to prevent forwarding loops.
These points are discussed further in the next section.
Note that the PE bridge modules that are on a given Emulated LAN may
or may not run a spanning tree protocol with each other over the
Emulated LAN; whether they do so or not is outside the scope of the
VPLS specifications. The PE bridge modules will do MAC address
learning on the ACs. The PE bridge modules also do MAC address
learning on the Emulated LAN interfaces, but do not do MAC address
learning on the PWs, as the PWs are "hidden" behind the Emulated LAN
interface. Conceptually, the PE bridge module’s forwarding table and
the VPLS Forwarder’s VSI are distinct entities. (Of course,
particular implementations might combine these into a single table,
but that is beyond the scope of this document.)
A further issue arises if the PE bridges run bridge control protocols
with each other over the Emulated LAN. Bridge control protocols are
generally designed to run in over a real LAN and may presume, for
their proper functioning, certain characteristics of the LAN, such as
low latency and sequential delivery. If the Emulated LAN does not
provide these characteristics, the control protocols may not perform
as expected unless special mechanisms are provided for carrying the
control frames.
It should be noted that changes in the spanning tree (if any) of a
customer network, or in the spanning tree (if any) of the PE bridges,
may cause certain MAC addresses to change their location from one PE
to another. These changes may not be visible to the VPLS Forwarders,
which means that those MAC addresses might become unreachable until
they are aged out of the first PE’s VSI. If this is not acceptable,
some mechanism for communicating such changes to the VPLS Forwarders
must be provided.
3.4.1. VPLS Overlay Topologies and Forwarding
Within a single VPLS, the VPLS Forwarders are interconnected by PWs.
The set of PWs thus forms an "overlay topology".
The VPLS Forwarder VSIs are populated by means of MAC address
learning. That is, the VSI keeps track of which MAC SAs have been
received over which PWs. The presumption, of course, is that if a
particular MAC address appears as the SA of a frame received over a
particular PW, then frames that carry that MAC address in the DA
field should be sent to the VSI that is at the remote end of the PW.
In order for this presumption to be true, there must be a unique VSI
at the remote end of the PW, which means that VSIs cannot be
interconnected by means of multipoint-to-point PWs. The PWs are
necessarily either point-to-point or, possibly, point-to-multipoint.
MAC learning over a point-to-point PW is done via the standard
techniques as specified by IEEE, where the PW is treated by the VPLS
Forwarder as a "bridge port". Of course, if a MAC address is learned
from a point-to-multipoint PW, the VSI must indicate that packets to
that address are to be sent over a point-to-point PW that leads to
the root of that point-to-multipoint PW.
The VSI forwarding decisions must be coordinated so that loop-free
forwarding over the overlay topology is ensured.
There are several possible types of overlay topologies:
- Full mesh
In a full mesh, every VSI in a given VPLS has exactly one
point-to-point PW to every other VSI in that same VPLS.
In this topology, loop free forwarding of frames is ensured by
the following rule: if a VSI receives a frame, over a PW, from
another VSI, it MUST NOT forward that frame over ANY other PW to
any other VSI. This ensures that once a frame traverses the
Emulated LAN, it must be sent off the Emulated LAN.
If a VSI receives, on one of its Emulated LAN interfaces, a
unicast frame with a known DA, the frame is sent on exactly one
point-to-point PW.
If a VSI receives, on one of its Emulated LAN interfaces, a
multicast frame or a unicast frame with an unknown DA, it sends
a copy of the frame to each other VSI in the same Emulated LAN.
This can be done by replicating the frame and sending a copy
over each point-to-point PW. Alternatively, the full mesh of
point-to-point PWs may be augmented with point-to-multipoint
PWs, where each VSI in a VPLS is the transmitter on a single
point-to-multipoint PW, and the receivers on that PW are all the
other VSIs in that VPLS.
- Tree structured
In a tree structured topology, every VSI in a particular VPLS is
provisioned to be at a particular level in the tree. A given
VSI has at most one pseudowire leading to a higher level. The
root of the tree is considered the highest level.
In this topology, loop free forwarding of frames is ensured by
the following rule: if a frame is received over a pseudowire
from a higher level, it may not be sent over a pseudowire that
leads to a higher level.
- Tree with Meshed Highest Level
In this variant of the tree-structured topology, there may be
more than one VSI at the highest level, but the set of VSIs that
are at the highest level must be fully meshed. To ensure loop
free forwarding, we need to impose the rule that a frame can be
sent on a pseudowire to the same or higher level only if it
arrived over a pseudowire from a lower level, and that frames
arriving over PWs from the same level cannot be sent on PWs to
the same level.
Other overlay topologies are also possible; e.g., an arbitrary
partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could
then be assured by, for example, running a spanning tree on the
overlay. These topologies are not further considered in this
framework.
Note that loop freedom in the overlay topology does not necessarily
ensure loop freedom in the overall customer LAN that contains the