PPVPN Working Group Loa Andersson
Internet-Draft Utfors AB
Design team editor
Expiration Date: Sep 2002
March 2002
PPVPN L2 Framework
<draft-andersson-ppvpn-l2-framework-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 [1].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
See the reference section. For this document this not just "an easy way
out", we actually intend to list all the documents that we are aware of
and that has an impact on this framework.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is intended for the PPVPN WG.
WHY IS IT TARGETED AT THIS WG(s)
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 2]
PPVPN deals with provider provisioned VPNs. This document provides and
a framework and architecture for Layer 2 Provider Provisioned Virtual
Private Network services, a class of Provider Provisioned Virtual
Private Networks services.
JUSTIFICATION
This document is a framework for Layer 2 VPNs, one of the main topics on
the PPVPN WG charter, and is considered instrumental in progressing the
standards work within the PPVPN group.
Abstract
This document provides a framework for Layer 2 Provider Provisioned
Virtual Private Networks (PPVPNs). This framework is intended to aid in
standardizing protocols and mechanisms to support interoperable layer 2
PPVPNs.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Contents
1. Introduction...................................................... 5
1.1 Objectives and Scope of the Document.......................... 5
1.2 Layer 2 Virtual Private Networks.............................. 6
1.3 Terminology................................................... 6
2. Models............................................................ 7
2.1 Reference Model for VPWS...................................... 7
2.1.1 Entities in the VPWS reference model................ 7
2.2 Reference Model for VPLS...................................... 7
2.2.1 Entities in the VPLS reference model................ 8
2.3 Reference Model for de-coupled VPLS........................... 8
2.3.1 Entities in the de-coupled VPLS reference model..... 8
3. Functional Components of L2 VPN................................... 8
3.1 Attachment Circuits........................................... 8
3.2 VPN Forwarding and Switching (VFS)............................ 9
3.3 Point-to-Point Pseudowires (PWs).............................. 9
3.4 Multipoint Pseudowires....................................... 10
3.5 Tunnels...................................................... 11
3.6 Provisioning and Discovery................................... 12
3.6.1 Attachment Circuit Provisioning.................... 12
3.6.2 Provisioning of VPWS Arbitrary Overlay Topologies.. 12
3.6.3 Provisioning of VPWS via "Colored Pools"........... 13
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 3]
3.6.4 Provisioning of VPLS................................... 14
3.6.5 Requirements on Discovery Procedures................... 15
3.6.6 Inter-AS Considerations................................ 16
3.7 Pseudowire Signaling......................................... 16
3.7.1 Point-to-Point Signaling............................... 17
3.7.2 Point-to-Multipoint Signaling.......................... 18
3.7.3 Comparison of P2P and P2MP Signaling................... 19
3.7.4 Inter-AS Considerations................................ 21
3.8 Encapsulation................................................ 21
3.9 Special Cases................................................ 21
3.9.1 VPWS: Like-to-like vs. Any-to-Any...................... 21
3.9.2 VPLS: IP Interworking Only............................. 22
3.9.3 VPLS: Decoupling....................................... 23
3.10 Quality of Service.......................................... 24
3.11 Redundancy.................................................. 24
3.12 Multihoming................................................. 24
4. Customer facing Interfaces....................................... 25
4.1 VPN Establishment at the Customer Interface.................. 25
4.1.1 VPWS................................................... 25
4.1.2 VPLS................................................... 25
4.1.3 Decoupled VPLS......................................... 25
4.2 Data Forwarding at the Customer Interface.................... 26
4.2.1 VPWS................................................... 26
4.2.2 VPLS................................................... 26
4.2.3 Decoupled VPLS......................................... 26
5. Core Network facing Interface.................................... 26
5.1 Network Management of L2 VPNs................................ 26
5.1.1 VPWS................................................... 26
5.1.2 VPLS................................................... 26
5.1.3 De-coupled VPLS........................................ 27
6. Security Considerations.......................................... 27
6.1 System security.............................................. 27
6.2 Access Control............................................... 27
6.3 Endpoint authentication...................................... 27
6.4 Data Integrity............................................... 27
6.5 Confidentiality.............................................. 27
6.6 User data and Control data................................... 27
7. List of Layer 2 VPN drafts....................................... 27
8. Summary and recommendations...................................... 32
8.1 Documents for VPLS type of services.......................... 32
8.2 Document for VPWS type of services:.......................... 32
8.3 Protocol extensions.......................................... 32
8.4 Architecture and Framework................................... 32
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 4]
9. References....................................................... 32
10. Acknowledgements................................................ 36
11. Authors Contact................................................. 36
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 5]
1. Introduction
1.1 Objectives and Scope of the Document
This document provides a framework for Layer 2 Provider Provisioned
Virtual Private Networks (PPVPNs). This framework is intended to aid in
standardizing protocols and mechanisms to support interoperable layer 2
PPVPNs.
The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. A
framework for L3 VPNs is found in [19]. This document provides the same
type of framework for Layer 2 PPVPNs as the Layer 3 framework does for
Layer 3 PPVPNs.
The term "provider provisioned VPNs" refers to Virtual Private Networks
(VPNs) for which the Service Provider (SP) participates in management
and provisioning of the VPN.
There are multiple ways in which a provider can participate in a VPN,
and there are therefore multiple different types of PPVPNs. The
framework document discusses layer 2 VPNs (as defined in section 1.2).
It also describes technical issues related to VPNs in which the provider
participates in provisioning for provider edge and customer edge
devices.
First, this document discusses reference models for Layer 2 PPVPNs. Then
technical aspects of layer 2 PPVPN operations from the customer's point
of view are discussed. Next, technical aspects of Layer 2 PPVPNs from
the providers point of view are discussed.
Specifically, this includes discussion of the technical issues, which
are important in the design of standards and mechanisms for support of
Layer 2 PPVPNs. Furthermore, technical aspects of layer 2 PPVPNs
interworking are clarified. Finally, security issues as they apply to
layer 2 PPVPNs are addressed.
Requirements for Layer 3 VPNs are found in [24] and for Layer 2 VPNs
(currently only for VPLS, but plan is to extend it to VPWS also) in
[21].
This document has "inherited" a substantial content from "An
Architecture for L2VPNs" [42].
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 6]
This document does not make choices, and does not select any particular
approach to support VPNs.
1.2 Layer 2 Virtual Private Networks
As Layer 2 provider provisioned VPN solutions has attracted more and
more interest, several solutions has been proposed to the PPVPN WG. This
document addresses the generic components relevant for every L2 but will
not make any recommendations on the relative merits of how the different
components are implemented.
In [23] parameters and metrics that could be used to compare different
Layer 2 VPN solutions and how they could be evaluated when a L2 VPN has
to meet different set of requirements is discussed. The parameters to be
considered in evaluating L2 VPN implementations in different
environments are e.g. scaling, cost, inter-domain reachability,
provisioning, flexibility, integration and migration from existing
infrastructure and services, value-add services, cost, etc.
Currently we see two kinds of services that a service provider could
offer to a customer by means of Layer 2 VPNs. Virtual Private Wire
Service(VPWS)and a Virtual Private LAN Service (VPLS).
A VPWS is a VPN service that supplies a L2 point-to-point service. Being
a point-to-point service where there are very few scaling issues with
the service as such. Scaling issues might arise from the number of end-
points that can be supported on a particular PE.
A VPLS is an L2 service that in all respects emulates LAN across a Wide
Area Network (WAN). Thus it also has all the scaling characteristics of
a LAN. Other scaling issues might arise from the number of end-points
that can be supported on a particular PE.
1.3 Terminology
This document list some terms and concepts that are specific to the L2
VPN framework, terms and concepts generally applicable to the PPVPN area
will be found in [18].
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 7]
2. Models
2.1 Reference Model for VPWS
Attachment PSN Attachment
Circuits tunnel Circuits
+
+-----+ pseudo +-----+
| | wire | |
| CE1 |--+ +--| CE2 |
| | | +-----+ +-----+ +-----+ | | |
+-----+ +----|---- | | P | | ----+----+ +-----+
|VPWS\|---|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\ |
+-----+ +----|---- | | | | ----|----+ +-----+
| | | +-----+ +-----+ +-----+ | | |
| CE3 |--+ +--| CE4 |
| | | |
+-----+ +-----+
2.1.1 Entities in the VPWS reference model
The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in
[18]. Attachment circuit and pseudo wire as discussed in section 3. The
PE does a simple mapping between the PW and attachment circuit based on
local information, i.e. the PW de-multiplexor and incoming/outgoing
logical/physical port.
2.2 Reference Model for VPLS
The following diagram shows a VPLS reference model where PE devices that
are VPLS-capable provide a logical interconnect such that CE devices
belonging to a specific VPLS appear to be connected by a single logical
Ethernet bridge. A VPLS can contain a single VLAN or multiple, tagged
VLANs.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 8]
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ................... | +-----+
VPLS A | +----+ +----+ | VPLS A
| |VPLS| |VPLS| |
+--| PE |--Service--| PE |-+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
VPLS B .....|VPLS|........ \ / VPLS B
| PE | ^ -------
+----+ |
| |
+-----+ |
| CE3 | +-- Logical bridge
+-----+
VPLS A
This reference model is adapted from [21] only difference is that the
VPLS-PE is explicitly named.
2.2.1 Entities in the VPLS reference model
The PE (VPLS-PE) and CE devices are defined in [18].
2.3 Reference Model for de-coupled VPLS
This is for a future version of this document.
2.3.1 Entities in the de-coupled VPLS reference model
This is for a future version of this document.
3. Functional Components of L2 VPN
3.1 Attachment Circuits
A Customer Edge (CE) device attaches to a Provider Edge (PE) device via
some sort of circuit or virtual circuit. We will call this an
"Attachment Circuit". 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
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 9]
L2TP tunnel, an MPLS LSP, etc. In general, the CE device may be a
router, a switch, a host, or just about anything which the customer
needs hooked up to the VPN.
Procedures for setting up and maintaining the Attachment Circuits are
out of scope of this architecture. These procedures are generally
specified as part of the specification of the particular Attachment
Circuit technology.
3.2 VPN Forwarding and Switching (VFS)
When a PE provides a VPLS, it must have one VFS for each VPL (Virtual
Private LAN) that it is supporting. A VFS may be thought of as a sort
of virtual LAN switch that performs the LAN switching functions for a
particular VPL. For a VPLS service, an Attachment Circuit can be
thought of as connecting a CE to a VFS. Multiple CEs may be connected to
a single VFS. The payload on these Attachment Circuits must be Ethernet
frames, with or without VLAN headers.
The Attachment Circuit may run over any medium, which can carry Ethernet
frames, either natively or in some encapsulation.
The VFS does MAC address learning as well as switching of Ethernet
frames.
The VFS construct does not appear in the VPWS, but only in the VPLS.
3.3 Point-to-Point Pseudowires (PWs)
To provide VPWS connectivity between CE1 and CE2, where CE1 attaches to
PE1 and CE2 attaches to PE2, and where PE1 is another device than PE2, a
point-to-point "Pseudowire" ("PW")[9] must be carried across the IP
backbone from PE1 to PE2. At each of PE1 and PE2, the PW is associated
with an Attachment Circuit. In effect, the ordered triple <CE1-PE1
Attachment Circuit, PE1-PE2 PW, PE2-CE2 Attachment Circuit> functions as
a virtual circuit between CE1 and CE2, thus providing layer 2
connectivity between the CEs. The mapping between a PW and a pair of
Attachment Circuits is one-to-one. In a VPWS, once a packet arrives on a
particular Attachment Circuit, the PW over which it is sent is
determined, and vice versa.
To provide VPLS connectivity among a set of CEs, each CE in the set must
be connected via Attachment Circuit to a VFS, which is part of that
VPLS. The VPLS is created by creating an overlay topology of PWs
connecting the set of VFSs that belong to that VPLS. That is, each
point-to-point PW binds together two VFS, rather than two Attachment
Circuits.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 10]
In a VPLS, once a packet arrives on a particular Attachment Circuit, the
VFS must determine the PW (or Attachment Circuit) to send the packet on.
Similarly, once a packet arrives on a particular PW, the VFS must
determine the Attachment Circuit (or PW) to send the packet on.
A VPLS emulates a LAN, in that all frame forwarding decisions are based
on the frames MAC Destination Address (DA) and its "incoming port". For
this purpose, both PWs and Attachment Circuits are considered to be
ports. The VFS forwarding decision maps a MAC DA and incoming port to
an outgoing port.
The VFS forwarding will be populated using MAC address learning as
specified by IEEE 802.something.
It is important to understand that in order to support the "MAC address
learning" functionality of IEEE 802.something, the VFSs must be
connected by point-to-point pseudowires. Although a VPLS provides a
LAN-like service to the CEs, the VFSs themselves are connected via
point-to-point PWs, NOT the multipoint PWs of section 3.4.
The VFS forwarding decisions must be coordinated so that loop-free
forwarding over the overlay topology is ensured. It is assumed that
frames are never sent back over their incoming ports.
Setting up and maintaining the PWs is the job of the PEs. State
information for a particular PW is maintained at the two PEs which are
its endpoints, but not at other PEs, and not in the backbone routers (P
routers).
Procedures for setting up and maintaining the PWs are within the scope
of the architecture.
Point-to-point PWs are considered to be bidirectional. This does not
rule out their being implemented as pairs of unidirectional entities.
When a PW relates two Attachment Circuits of like kind, it is necessary
to specify the relation between Attachment Circuit state and PW state,
as well as the relation between various Attachment Circuit events and
various PW events. However, this specification is outside the scope of
the current architecture. This is deferred, where applicable, to the
PWE3 Working Group.
3.4 Multipoint Pseudowires
It is useful to have the notion of a unidirectional multipoint
pseudowire. In a p2p PW, anything which is put in either end comes out
the other. In a unidirectional multipoint PW, there is a single egress
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 11]
point, but multiple ingress points. Anything put in at one of the
ingress points will come out the egress point.
Multipoint PWs may be used to support an "IP Connectivity VPLS", see
section 3.9.2.
3.5 Tunnels
A PW is carried in a "tunnel" from PE1 to PE2. In general, the number
of PWs that may be carried in a single tunnel is arbitrary; the only
requirement is that the PWs all terminate at PE2. It is not required
that all the PWs in the tunnel originate at the same PE; the tunnels may
be multipoint-to-point tunnels. Nor is it required that all PWs between
the same pair of PEs travel in the same tunnel.
It is required that when a frame traveling through such a tunnel arrives
at PE2, PE2 will be able to associate it with a particular PW. In a
VPWS, this determines the Attachment Circuit on which the frame will be
transmitted from PE2 to the appropriate CE; in a VPLS this determines
the VFS to which the packet must be delivered.
It is desired to allow a variety of different tunneling technologies to
be used for the PE-PE Tunnels, and it is a goal of the architecture to
accommodate any tunneling protocol, which allows 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, which
contains a Demultiplexor field, where the Demultiplexor field is used to
identify a particular PW.
It is very important not to confuse the PWs with the tunnels through
which they travel.
Procedures for setting up and maintaining the tunnels are out of scope
of this architecture.
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 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 architecture.
Although point-to-point PWs are inherently bidirectional, there is no
need for the tunnels through which they travel to be bidirectional.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 12]
3.6 Provisioning and Discovery
Provisioning a VPWS is a matter of:
1. Provisioning the Attachment Circuits
2. Telling the PEs which Attachment Circuits (in the case of VPWS) or
which VFSs (in the case of VPLS) need to be connected via which
kinds of PWs
3. Configuring the PWs with any necessary characteristics
The set of PWs creates an "overlay topology", which is in effect the
"virtual backbone" of the layer 2 VPN.
3.6.1 Attachment Circuit Provisioning
In many cases, the CE-PE Attachment Circuits 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 Attachment Circuits might not have to be
individually provisioned. E.g., if an Attachment Circuit is just an
MPLS LSP running between a CE and a PE, it could be set up as the RESULT
of a PW being set up, rather than having to be provisioned BEFORE the PW
can be set up. The same may apply whenever the CE-PE Attachment is an
SVC of any sort, though in this case, various policy controls might need
to be provisioned, e.g., limiting the number of Attachment Circuits that
can be set up between a given CE and a given PE.
Whether the Attachment Circuits need to be individually provisioned or
not, whether an SVC or a PVC model is used, and what sorts of policy
controls may be applied, are implementation and deployment issues, and
are not further discussed here.
3.6.2 Provisioning of VPWS Arbitrary Overlay Topologies
In order to support arbitrary overlay topologies, it is necessary to
allow the provisioning of individual PWs. There are basically two
variations of this:
- Two-sided provisioning.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 13]
With two-sided provisioning, each PE which is at the end of a PW is
provisioned with the following information:
* Local Attachment Circuit
* Pseudowire type and parameters
* IP address of PE at remote end of pseudowire
* Identifier which is meaningful to PE at remote end of wire,
and can be used by that PE to bind the PW to the proper
Attachment Circuit. This can be an identifier of the pseudowire
(as in [7]), or an identifier of the remote Attachment Circuit
(as in [10]). The identifier needs to be unique relative to the
pair of PEs.
This provisioning method does not use a discovery scheme.
- Single-Sided Manual Provisioning.
With single sided provisioning, a PE at one end of a PW is provisioned
with the following information:
* Local Attachment Circuit
* Pseudowire type and parameters
* Globally unique identifier of remote Attachment Circuit.
This provisioning method requires the use of a discovery scheme, which
maps the globally unique identifier of the remote Attachment Circuit to
the IP address of the remote PE, along with an identifier (unique only
at the latter PE) for an Attachment Circuit at that PE. (See, for
example, [10].)
This provisioning method requires provisioning of the pseudowire at only
one PE, but does not eliminate the need (if there is a need) to
provision the Attachment Circuits at both PEs.
3.6.3 Provisioning of VPWS via "Colored Pools"
Suppose that at each PE, sets of Attachment Circuits are gathered
together into "pools", and that each such pool is assigned a color.
(For example, a pool might contain all and only the Attachment Circuits
from this PE to a particular CE.) Now suppose 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 which is bound at PE1 to an arbitrarily chosen
Attachment Circuit from that pool, and at PE2 to an arbitrarily chosen
Attachment Circuit from that pool.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 14]
(We do not rule out the case where a single PE has multiple pools of a
given color.)
As long as:
- There is no need to provision different characteristics for the
different PWs, and
- It makes no difference which pairs of Attachment Circuits are
bound together by PWs, as long as both Attachment Circuits in
the pair come from like-colored pools, and
- It is possible to construct the necessary overlay topology
simply by setting up the colored pools,
then this technique provides a very simple and scalable way to provision
the L2VPN overlay topology. Certainly it is more scalable (in terms of
the amount of provisioning data that must be entered) than provisioning
theindividual pseudowires, even if the single-sided model is used.
(Note, however, that much or all of this advantage is lost if it is
necessary to provision the individual Attachment Circuits.)
This provisioning method requires the use of a discovery scheme which
maps a color into the set of PE which have pools of that color.
This technique is first described in [5], and also discussed in [10].
The colored pools technique may be useful if one wants a VPWS overlay
topology which is a full CE-CE mesh of virtual circuits. Then at each
PE, one creates one such pool per CE, containing all and only the
Attachment Circuits which connect to that CE. Across the network, the
set of pools that correspond to a particular VPN are given the same
color. In this case, the "color" really corresponds to a "VPN-id".
More generally, one might want to control the topology of a VPN by
giving it pools of several different colors, and even by allowing single
pools to have multiple colors.
So in general there might be multiple colors corresponding to a single
VPN-id. The colors of course are really globally unique values.
The colored pools technique also works well for "hub and spoke" overlay
topologies. However, in that topology it does not provide a scaling
advantage over the single-sided provisioning model.
3.6.4 Provisioning of VPLS
Each VPLS must be assigned a globally unique identifier. Each VFS must
be provisioned with the identifier of the VPLS to which it belongs. A
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 15]
discovery scheme is used to map from a VPLS identifier to the set of PEs
containing VFSs in that VPLS.
If there is no need to provision different characteristics for different
PWS, then this is all that is needed to provision a VPLS, other than the
provisioning of the Attachment Circuits. If there is a need to
provision different characteristics for different PWs, then the
individual pseudowire provisioning of section 3.6.2 may be used; single-
sided provisioning with a globally unique identifier that identifies a
particular VPLS should be used.
3.6.5 Requirements on Discovery Procedures
To support the single-sided provisioning model, the discovery procedure
must be able to map a globally unique identifier (of a PW or of an
Attachment Circuit) to a PE IP address.
To support the colored pools provisioning model, the discovery procedure
must enable a PE to determine the set of other PEs which contain pools
of the same color.
To support the VPLS provisioning model, the discovery procedure must
enable a PE supporting a particular VPLS to determine the set of other
PEs which contain VFSs in the same VPLS.
Examples of suitable auto-discovery procedures can be found in [5], [3],
and [12].
There are additional requirements on the auto-discovery procedures which
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 automatically
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., the use of schemes,
which piggyback the auto-discovery information on the
backbone's IGP.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 16]
3.6.6 Inter-AS Considerations
Within a single L2VPN, some PEs may attach to one Service Provider's
network, while other PEs attach to another Service Provider's network.
Discovery procedures must enable a PE to discovery other PEs in the same
L2VPN, even when those other PEs are attach to a different Provider's
network.
The DNS-based and BGP-based discovery procedures both have this
property, though in both cases some additional complexity is introduced.
3.7 Pseudowire Signaling
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 Demultplexor 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 which 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
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.
- Binding of PW to Attachment Circuit or VFS. The signaling
protocol must contain enough information to enable the remote
PE to determine proper Attachment Circuit or VFS to which the
PW must be bound.
- In some cases, this will require that a specific individual
Attachment Circuit be identified by the signaling protocol. In
other cases, one may not care which Attachment Circuit a PW is
bound to, as long as that Attachment Circuit has some specific
property. In this case, that property needs to be identified
by the signaling protocol. An example of such a property is
"an Attachment Circuit that comes from a particular colored
pool." To identify a particular VFS, the VPLS dentifier should
be used.
- Distribution of State Changes. Changes in the state of an
Attachment Circuit may need to be reflected in changes to the
state of the PW to which the Attachment Circuit is bound, and
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 17]
vice versa. These changes must then be distributed to the
remote endpoint of the PW.
- Establish pseudowire characteristics. To the extent that one or
more characteristics of a PW must be agreed upon by both
endpoints, the signaling must allow for the necessary
interaction.
- Support pseudowire emulations. To the extent that a particular
PW must emulate the signaling of a particular layer 2
technology, the PW signaling must provide the necessary
functions.
Specification of the use of existing protocols for pseudowire signalling
needs to be done by the PPVPN WG. To the extent that the protocols need
to be extended to support the necessary signaling, the extensions must
be done by the WG responsible for the signaling protocol, and the PPVPN
WG must set the requirements. (Extensions which can be made merely by
assigning new parameter values, where IANA has been instructed to assign
values for those parameters on a first come, first served, basis, can be
specified entirely by th PPVPN WG without need for the approval of
another WG.
Pseudowire signaling procedures tend to fall into two classes:
point-to-point signaling and point-to-multipoint signaling, which are
discussed in the remainder of this section.
It is important to understand that point-to-multipoint signaling may be
used for setting up point-to-point pseudowires. The distinction is
whether the signaling is point-to-point or point-to-multipoint, not
whether the resulting pseudowires are point-to-point or multipoint.
3.7.1 Point-to-Point Signaling
There are several ways to do the necessary point-to-point signaling:
- LDP. LDP extensions can be defined for pseudowire signaling.
This form of signaling can be used for pseudowires which are to
be carried in MPLS "tunnels", or in MPLS-in-something-else
tunnels. See [7] and [10].
- L2TP. L2TP extensions can be defined for pseudowire signaling.
This form of signaling can be used for pseudowires that are to
be carried a sessions in L2TP tunnels. See [4].
- If it is desired to tunnel pseudowires through IPsec, one may
use the MPLS-in-IPsec technique defined in [35], or one may use
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 18]
the L2TP-in-IPsec defined in [???]. No IPsec extensions are
required.
3.7.2 Point-to-Multipoint Signaling
Consider the case where we want to set up a set of PWs, but rather than
binding them to specific Attachment Circuits, we only want to ensure
that they get bound to Attachment Circuits with a specific property.
Suppose further that all the PWs in the set are to have uniform
characteristics, and that we do not desire to reflect changes in
Attachment Circuit state as changes in pseudowire state. Suppose
further that all the Attachment Circuits are alike (i.e., of the same
technology), so that no special interworking or header translation needs
to be done. 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. Then
an egress PE would not necessarily need to assign a particular
Demultiplexor to each pseudowire, it could merely specify the range that
is to be associated with a particular set of PWs, and allow each ingress
PE to choose, from the range, the demultiplexor that belongs to it.
Call this the DEMULTIPLEXOR CONDITION.
Suppose alternatively that there is no need for point-to-point PWs, but
that multipoint-to-point PWs would be satisfactory. 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 which terminate at egress PE1, the
information which PE1 needs to send to the ingress PE of each pseudowire
in the set is exactly the same. Rather than connecting to each ingress
PE and replicating the same information, it may make sense to send the
information once to a "reflector", which will then take responsibility
for distributing the information to the other PEs.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 19]
We refer to this sort of technique as "point-to-multipoint" signaling.
One could, for example, use BGP to do the signaling, with the PEs being
BGP peers not of each other, but of one or more BGP route reflectors.
Such a scheme is proposed in [5].
When BGP-based signaling is proposed, it is usually assumed that it will
be used for point-to-multipoint signaling, with route reflectors. A
full mesh of individual PE-to-PE BGP connections could of course be
used, but in that case using BGP is little different than using LDP or
L2TP, and BGP has no particular advantages. (Note that this is very
different than the more usual case in which BGP is used for distributing
routing information. One could not use LDP or L2TP to distribute
routing information, as they have no routing decision process, and no
procedures for preventing the formation of routing loops. But pseudowire
signaling is a very different application than the distribution of
routing information, and BGP has no particular advantage for it, other
that the possibility of using a route reflector to improve scalability
(see next section)).
3.7.3 Comparison of P2P and P2MP Signaling
1. Scaling of control connections
In point-to-multipoint signaling using a reflector, each PE only
needs one control connection; all signaling, for all PWs, is done
via this single connection.
In point-to-point signaling, a given PE needs one control
connection for each remote PE that is that the other end of one of
the given PE's PWs. Thus there is a savings in terms of control
connection state.
2. Scaling of control information
If the appropriate conditions hold (as described in the previous
section), then point-to-multipoint signaling results in a PE
sending less signaling information than it would have to send with
point-to-point signaling. Information that the PE would have to
send multiple times with point-to-point signaling just gets sent
once, to the reflector. The reflector duplicates this information
and sends it to all the PEs that need to see it.
Note however that there is no reduction on the amount of
information received, only in the amount sent. This differs
considerably from the more usual use of BGP route reflectors for
distributing routing information. In that case, the route
reflector does not simply pass on all the information it receives,
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 20]
it winnows the information down by running its decision process.
In the case of point-to-multipoint signaling, there is no such
"winnowing down" process. Hence the use of BGP route reflectors
does not have quite the same advantage as it does when used for
distributing routing information.
3. The Demultiplexor Condition
The Demultiplexor Condition is not something that holds naturally,
it is something that must be made to hold by means of
provisioning. It requires that each PE be provisioned with a
Demultiplexor Range that is assigned to a particular set of
Attachment Circuits. (This provisioning can be eliminated if it
is desired to make the range equal to the number of Attachment
Circuits in the set, but then the Demultiplexor Condition will
likely fail if additional Attachment Circuits are later
provisioned.)
It also requires that at each PE, each set of PWs needs to be
assigned a unique identifier (unique relative to the set of PEs
supporting that set of PWs) which it can use, together with the
Demultiplexor Range, to deterministically select a unique
Demultiplexor value. This means that the identifiers must be (or
be algorithmically mappable to) a sequence of numbers beginning
with 1. See [5] for the details of one particular mechanism for
this.
4. The Multipoint Condition
In general, this condition does not hold in L2VPNs. But see
section 3.9.2 for a discussion of when it does.
5. The Environmental Conditions
In general, it is not clear that the environmental conditions
hold. In traditional L2VPNs built over Frame Relay or ATM VCs,
the individual VCs may have different characteristics with respect
to, e.g., QoS, and they are really expected to provide a
particular set of signals at the User/Network interface, as
defined by the FR or ATM specifications. The use of point-to-
multipoint signaling is awkward for passing information that
applies to only a single point-to-point pseudowire, as it tends to
pass the information to many more entities than need to know it.
6. Relation to Auto-Discovery
If a BGP-based autodiscovery scheme is used, then the use of BGP-
based point-to-multipoint signaling allows the signaling phase and
the auto-discovery phase to take place simultaneously; if BGP-
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 21]
based autodiscovery is used together with point-to-point signaling
(as suggested in [10], then two separate phases are then required.
The combination of DNS-based discovery with point-to-multipoint
signaling does not appear feasible.
3.7.4 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 means that the
signaling to set up the PEs must be able to cross network boundaries.
All known proposals for signaling are able to do this.
3.8 Encapsulation
As L2VPN packets are sent on pseudowires, the encapsulations of draft-
so-pwe3-ethernet-00.txt, draft-kamapabhava-fr-pwe3-00.txt, or draft-
brayley-pwe3-atm-service-01.txt should be used, depending on the L2
technology being emulated by the PW. See also sections 3.9.1 and 3.9.2.
3.9 Special Cases
3.9.1 VPWS: Like-to-like vs. Any-to-Any
In VPWS, a PW connects two Attachment Circuits. If these two circuits
are of like type, then the necessary emulation procedures from PWE3
should be used.
If the two circuits are of unlike type, and there is a defined
interworking procedure (such as the ATM/FR service interworking
procedure), then we model this as, e.g., an ATM-to-ATM pseudowire, with
the FR interworking function logically between the pseudowire endpoint
and the FR Attachment Circuit.
The interworking function is therefore transparent to the pseudowire
signaling.
If the two Attachment Circuits are of unlike type, and it is known that
the circuits are part of a VPN which only supports IP traffic, then one
can use "IP interworking", as suggested in [5]. An IP interworking
pseudowire is a special type of pseudowire which can be bound at its
endpoints to two different types of point-to- point Attachment Circuits.
Only the IP payload is carried across the network in the pseudowire; a
PWE3 encapsulation is not used. This method of interworking is
transparent to the CE devices.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 22]
This is discussed more fully in [26].
Yet another way to do any-to-any interworking is by requiring the CE
devices to transmit Ethernet frames on their point-to-point Attachment
Circuits, using the "bridged frame" encapsulation. This also enables
interworking with CE devices that attach via Ethernet interfaces to PE
devices, as long as the Attachment Circuit is treated by the CE as a
point-to-point Attachment Circuit, rather than as a shared LAN.
3.9.2 VPLS: IP Interworking Only
If, instead of providing a general VPLS service, one wishes to provide a
VPLS that is used only to connect IP routers or hosts (i.e., the CE
devices are all assumed to be IP routers or hosts), then it is possible
to makecertain simplifications.
In this environment, all Ethernet frames sent from a particular CE to a
particular PE on a particular Attachment Circuit will have the same MAC
Source Address. Thus rather than using standard IEEE 802.something
address learning in the data plane to learn the MAC addresses, the PE
can use the control plane to learn the MAC address. (See [26] for a
discussion of this.)
To eliminate the need for MAC address learning on the PWs as well as on
the Attachment Circuits, the pseudowire signaling protocol would have to
carry the MAC address from one pseudowire endpoint to the other. Each
PE would perform proxy ARP to its directly attached CEs.
By eliminating the need to do MAC address learning on the PWs, we
eliminate the need for the PWs to be point-to-point. Instead,
multipoint PWs can be used. Hence the multipoint condition of section
3.7.2 holds. The environmental conditions of section 3.7.2 are also like
to hold in this case, since the service being provided is IP
connectivity, rather than Ethernet emulation. Hence this situation is a
good match for point-to-multipoint signaling. Since the PWs being
signaled are multipoint-to-point, there is no need for provisioning
label ranges or unique identifiers.
The advantage of an IP Connectivity VPLS is that it allows one to use PE
devices that cannot do MAC address learning in the data plane. However,
these devices would still need to be able to do packet replication onto
multiple PWs in order to support layer 2 broadcast frames such as IGP
Hellos. As there are no unknown DAs, multicast data would only need to
be supported if IP multicast is supported.
A fuller discussion of the advantages and disadvantages may be found in
[26].
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 23]
3.9.3 VPLS: Decoupling
In VPLS, a PE device must perform functions, which are traditionally
associated with Ethernet bridges (MAC address learning, multicast
replication), as well as functions, which are usually associated with
routers (e.g., routing, LDP or L2TP or BGP signaling, BGP for
autodiscovery perhaps). It is worth asking whether a VPLS service can
be implemented more efficiently by splitting the PE into two pieces: a
user-facing piece mainly doing data plane forwarding (Forwarding-PE, F-
PE) and a network-facing piece that apart form data plane forwarding
also is the control part of the PE (Control-PE, C-PE). Then one could
use as the C-PE a router, which doesn't have bridging capability (can't
do SA learning, isn't very good at multicast replication), and use as a
F-PE a switch, which does the bridging but doesn't participate in the
backbone routing at all.
Since multicast replication is to be done by the F-PE, if a F-PE is in a
given VPLS, it must maintain state for every other F-PE, which is in the
same VPLS. That is, the F-PE must have a unique pseudowire for each of
the other F-PEs in the same VPLS. Hence the amount of state maintained
by the F-PE is proportional to the number of F-PEs in the VPLS.
Different proposals for the decoupled VPLS differ in the way they
approach auto-discovery and signaling.
3.9.3.1 Auto-discovery
If the auto-discovery technique is simple to implement, then there is
little reason why the F-PE should not do the auto-discovery itself.
E.g., if DNS-based auto-discovery is used, the F-PE can do the necessary
DNS lookups, there is no reason for the C-PE to get involved in this at
all.
On the other hand, if BGP-based auto-discovery is used, perhaps the F-PE
devices don't have BGP, and hence the C-PEs need to get involved. In
this model, the F-PE needs to somehow share its configuration with its
C-PE, the C-PEs do the distributed auto- discovery, and then share the
discovered information somehow with the F-PE devices. This sort of
model is discussed (though in a different context) in [8]. It requires
that some protocol be used between F-PE and C-PE to pass the necessary
configuration and discovery information.
3.9.3.2 Signaling
There are two different signaling models for decoupled VPLS. In Model
1, the F-PE devices signal each to set up the necessary PWs among
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 24]
themselves, using whatever pseudowire signaling protocol is appropriate.
The F-PEs also create tunnels among themselves. In this model, the C-
PEs have no per-VPLS state whatsoever, no pseudowire state, no tunnel
state, etc.
In Model 2, a C-PE figures out (most likely via a discovery procedure)
which of its attached F-PE devices needs a pseudowire to which other F-
PE devices. The C-PE devices then set up all the necessary PWs, by C-PE-
to-C-PE signaling.
In this model, when a F-PE sends a packet to an C-PE, the F-PE must tell
the C-PE which pseudowire the packet needs to traverse. This requires
an additional protocol between the F-PE and C-PE. The F-PE must still
maintain state for each other F-PE in the same VPLS. The C-PE also
maintains state for each remote F-PE, as it participates in the
pseudowire and tunnel setup.
Thus Model 2 reduces the number of control connections that the F-PE
needs to support, at the cost of increasing the state maintained by the
C-PE. Model 2 does not however eliminate the need for per-pseudowire
state at the F-PE.
3.10 Quality of Service
QoS parameters used in the customer network has to be transported by the
PSN transparently between CEs and honoured in the PSN.
3.11 Redundancy
The service infrastructure typically provides redundant paths to assure
high availability. In case of L2 network service built with the help of
IP or MPLS infrastructure, care is taken to provide fast recovery times
approximating typical recovery times of l2 networks.
In cases where the provider knows a priori about impending changes in
network topology, the infrastructure is typically capable of
reconfiguring the service operations without the loss of customer
packets.
3.12 Multihoming
In many configurations, a CE has only one link to the provider. However,
high availability configurations provide for multiple accesses from the
same CE to the service provider though different physical paths. In
effect, the Layer 2 service becomes multihomed.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 25]
4. Customer facing Interfaces
This is for a future version of this document.
4.1 VPN Establishment at the Customer Interface
This is for a future version of this document.
4.1.1 VPWS
This is for a future version of this document.
4.1.1.1 Static binding
This is for a future version of this document.
4.1.1.2 Dynamic binding
This is for a future version of this document.
4.1.2 VPLS
An attachment circuit, or a set of attachment circuits from the same
customer, needs to be bound to a VSF. Such mapping can be user
provisioned or can be dynamically performed as described in [32].
In the case where a single attachment circuit is provided, there is no
need to perform any specific bridging function on the attachment
circuit. However, in the case where multiple attachment circuits from
different locations terminate within a single PE, such circuits have to
be treated as virtual ports. In this latter case, typical learning and
filtering functions are required on such attachment circuits. In the
case of dual homing, one of the attachment circuits has to be disabled.
This can be achieved either dynamically or administratively.
4.1.3 Decoupled VPLS
This is for a future version of this document.
4.1.3.1 Static binding
This is for a future version of this document.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 26]
4.1.3.2 Dynamic binding
This is for a future version of this document.
4.2 Data Forwarding at the Customer Interface
This is for a future version of this document.
4.2.1 VPWS
This is for a future version of this document.
4.2.2 VPLS
This is for a future version of this document.
4.2.3 Decoupled VPLS
This is for a future version of this document.
5. Core Network facing Interface
This is for a future version of this document.
5.1 Network Management of L2 VPNs
This is for a future version of this document.
5.1.1 VPWS
This is for a future version of this document.
5.1.2 VPLS
The management of a VPLS imposes specific requirements on top of the
VPWS. In addition to the ability to be able monitor and administer each
individual pseudo wires that constitute a VPLS instance, it is necessary
to be able to monitor the VPLS service as a whole. When connectivity to
a specific site is broken, an alarm may have to be generated and
depending upon the user configuration or pseudo-wire attributes, the
whole VPLS service might be brought down or might be preserved between
the other sites.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 27]
5.1.3 De-coupled VPLS
This is for a future version of this document.
6. Security Considerations
Security considerations will be addressed in a future version of this
document.
6.1 System security
This is for a future version of this document.
6.2 Access Control
This is for a future version of this document.
6.3 Endpoint authentication
This is for a future version of this document.
6.4 Data Integrity
This is for a future version of this document.
6.5 Confidentiality
This is for a future version of this document.
6.6 User data and Control data
This is for a future version of this document.
7. List of Layer 2 VPN drafts
draft-ietf-ppvpn-bgpvpn-auto-02.txt
This draft defines a BGP based auto-discovery mechanism for both
layer-2 VPNs and and layer-3 VPNs. This mechanism is based on the
approach used by RFC2547-bis for distributing VPN routing
information within the service provider(s). Each VPN scheme uses
the mechanism to automatically discover the information needed by
that particular scheme.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 28]
draft-ietf-ppvpn-l2vpn-00.txt
This document discusses the signaling, encapsulation, and
configuration issues that arise. Its purpose is to provide an
architecture which allows different kinds of point-to-point
virtual circuits to be provided through different kinds of IP
tunnels.
draft-augustyn-vpls-arch-00.txt
This document describes the architecture and model for Virtual
Private LAN Services (VPLS) and discusses the signaling,
encapsulation, and configuration issues that arise.
draft-augustyn-vpls-bw-00.txt
This document describes a method for controlling customer traffic
for L2 VPN services which support broadcast, multicast or implied
broadcast such as e.g. VPLS.
draft-augustyn-vpls-requirements-02.txt
This document specifies requirements for a VPLS, the intention is
to extend it to comprise all types of Layer 2 VPNs.
draft-cai-ppvpn-vc-rsvp-te-00.txt
This draft discusses the use of RSVP-TE as a VC setup mechanism.
draft-chen-ppvpn-dvpls-compare-00.txt
This draft compares different solutions for decouple PE
functionality in a VPLS. It advocates a merging of existing
drafts.
draft-elwin-l2tpext-ppvpn-00.txt
PPVPNs need a tunneling mechanism and a means to automatically
discover VPN membership and signal these tunnels. This draft
elaborates the use of L2TP as the tunneling mechanism, and defines
extensions to L2TP to handle VPN membership discovery to leverage
PPVPNs.
draft-elwin-ppvpn-l2tp-arch-00.txt
This document discusses the use of L2TP for establishing PPVPNs.
It proposes to use L2TP for VPN membership, topology discovery,
and as a tunneling mechanism.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 29]
draft-heinanen-dirldp-uni-vc-vpns-01.txt
This document describes how provider based unidirectional Virtual
Circuit VPNs can be implemented using a directory (such as DNS)
and LDP for PE discovery and label distribution.
draft-heinanen-dns-ldp-vpls-00.txt
This document describes how provider provisioned Virtual Private
LAN Service (VPLS) can be implemented using DNS and LDP for PE
discovery and label distribution.
draft-heinanen-inarp-uni-01.txt
This document describes operation of an Inverse Address Resolution
Protocol (InARP) over unidirectional virtual circuits such as MPLS
LSPs.
draft-khandekar-ppvpn-hvpls-mpls-00.txt
This document proposes extensions to draft-lasserre-vkompella-
ppvpn-tls-00.txt, by introducing hierarchical connectivity. This
document also describes support for participation of non-bridging
PE devices in a VPLS solution.
draft-knight-l2vpn-lpe-ad-00.txt
This document describes a lightweight protocol for VPLS
information exchange between Logical PE components, consisting of
the PE-Edge (i.e. in the terminology of [18]the Forwarding-PE) and
PE-Core (i.e. in the terminology [18] of the Control-PE).
draft-kompella-ppvpn-dtls-01.txt
In a VPLS a common scenario is when Service Provider in a metro
area places a simple, low-cost box (MTU, i.e. in the terminology
of [18] the Forwarding-PE)) in each building; these MTUs have
uplinks to some box (PE, i.e. in the terminology of [18] the
Control-PE) in one or more Offices. This document describes
decoupling the functions needed to offer the VPLS across the MTU
and PE.
draft-kompella-ppvpn-l2vpn-01.txt
This document present a Layer 2 VPN solution where from the
customer's point of view, the VPN is based on Layer 2 circuits,
but the Service Provider maintains and manages a single network
for IP, IP VPNs, and Layer 2 VPNs.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 30]
draft-kompella-ppvpn-vpls-00.txt
In the case of a VPLS, a point to multipoint network connects the
customers in the VPN. This document describes the functions needed
to offer a VPLS, and propose a mechanism for signaling a VPLS, and
a mechanism for transport of VPLS frames over tunnels across a
packet switched network.
draft-lasserre-vkompella-ppvpn-tls-00.txt
This document describes a VPLS solution over MPLS. VPLS simulates
an Ethernet virtual 802.1d bridge for a given set of users. It
deliver a layer 2 broadcast domain that is fully capable of
learning and forwarding on Ethernet MAC addresses that is closed
to a given set of users.
draft-lau-ppvpn-qos-tls-mpls-00.txt
draft-lasserre-vkompella-ppvpn-vpls-00.txt describes a solution to
support point-to-multipoint VPLSs over MPLS. This document
describes two extensions to facilitate the provisioning and
support of QoS in VPLS over MPLS. The use of the VCID field in the
VC-FEC is extended to identify a VPN endpoint. One VC-label per
source/destination VPN endpoint pair is used.
draft-luciani-ppvpn-vpn-discovery-01.txt
This document describes the use of DNS to discovery VPN endpoints.
draft-martini-l2circuit-encap-mpls-04.txt
This document describes methods for encapsulating the Protocol
Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM,
or Ethernet for transport across an MPLS or IP network.
draft-martini-l2circuit-trans-mpls-08.txt
This document describes methods for transporting the Protocol Data
Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,
Ethernet, and providing a SONET circuit emulation service across
an MPLS network.
draft-menezes-inter-city-man-mpls-00.txt
This document describes a network service model for high-speed
Metropolitan Area Network (MAN) service providers to services
between cities. It simplifies MAN operation and improves the
scalability of a traditional standard overlay model by allowing
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 31]
the MAN provider to peer to the NSP for both Internet transit and
inter-city MAN services (e.g. a VPLS).
draft-ouldbrahim-bgpgmpls-ovpn-02.txt
This document describes a method for how a service provider
network that offers Optical/TDM Virtual Private Network service.
draft-ouldbrahim-l2vpn-lpe-01.txt
In a VPLS a common scenario is when Service Provider in a metro
area places a simple, low-cost box Edge-PE (i.e. in the
terminology of [18] the Forwarding-PE) in each building; these
Edge-PEs have uplinks to some box Core-PE (i.e. in the terminology
of [18] the Control-PE) in one or more Offices. This document
describes decoupling the functions needed to offer the VPLS across
the Edge-PEs and Core-PE.
draft-rosen-ppvpn-l2-signaling-01.txt
This draft describes a signaling technique that eliminates the
requirement for a priori knowledge of a common VC identifier, and
to eliminate the requirement that each endpoint be known to the
other.
draft-sajassi-vpls-architectures-00.txt
In this document a reference architecture for VPLS systems is
defined. It describes possible VPLS architectures based on this
reference architecture and the logical components of each.
draft-senevirathne-vmi-frame-02.txt
This document we present framework for a VPLS and a point-to-point
Layer 2 VPN service.
draft-shah-ppvpn-arp-mediation-00.txt
This draft specifies the procedures, which the Provider Edge
routers should perform in order to allow correct operation of
address resolution across heterogeneous point-to-point links.
draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt
draft-kompella-ppvpn-dtls-01.txt identifies the need for an
information exchange mechanism between a PE device (i.e. in the
terminology of [18] the Control-PE) and its adjunct L2PE devices
(i.e. in the terminology of [18] the Forwarding-PE) in the
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 32]
decoupled VPLS. This draft proposes an LDP based approach for such
exchange mechanisms.
draft-tsenevir-gre-vpls-00.txt
In this document a VPLS solution that use GRE and IP tunnels is
described.
8. Summary and recommendations
>From the number of Internet draft on requirements, architectures and
solutions seen in the Layer 2 VPN area it is possible to draw the
conclusion that there is a high degree on commonalties and a great
interest in this area.
Within the PPVPN WG it is a common understanding that the existing set
of solutions need to be limited to a more manageable set of unified
solutions.
8.1 Documents for VPLS type of services
This for a future version of this document.
8.2 Document for VPWS type of services:
This for a future version of this document.
8.3 Protocol extensions
To the extent extensions are needed for protocol that originates from
other working groups than PPVPN they should be handled in separate
documents.
8.4 Architecture and Framework
Architecture and framework issues on a general level for L2 PPVPNs
should be consolidated and incorporated in this document.
9. References
[1] Bradner, S. "The Internet Standards Process -- Revision 3", RFC
2026, October 1996.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 33]
[2] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Hamid Ould-Brahim et al, "Using BGP as an Auto-Discovery
Mechanism for Network- based VPNs", draft-ietf-ppvpn-bgpvpn-
auto-02.txt Work in Progress, Internet Draft, Nov 2001
[4] Elwin Stelzer et al, "L2TP Extensions for PPVPN", 11/01, draft-
elwin-l2tpext-ppvpn-00.txt
[5] Kompella, K et.al. "Layer 2 VPNs Over Tunnels", draft-kompella-
ppvpn-l2vpn-01.txt1, Work in Progress, Internet Draft Nov 2001
[6] Martini, L et.al. "Encapsulation Methods for Transport of Layer
2Frames Over IP and MPLS Networks", draft-martini-l2circuit-
encap-mpls-04.txt, Work in Progress, Internet Draft, Nov 2001
[7] Martini, L. et.al. "Transport of Layer 2 Frames Over MPLS",
draft-martini-l2circuit-trans-mpls-08.txt, Work in Progress,
Internet Draft, 2001
[8] Ould-Brahim, H et.al. "BGP/GMPLS Optical/TDM VPNs", draft-
ouldbrahim-bgpgmpls-ovpn-02.txt, Work in progress, Internet
Draft Nov 2001,
[9] Pate, P, editor, "Framework for Pseudo Wire Emulation Edge-to-
Edge", draft-ietf-pwe3-framework-00.txt, Work in Progress,
Internet draft Feb 2002
[10] Rosen, E "Single-Sided Signaling for L2VPNs", draft-rosen-ppvpn-
l2-signaling-01.txt, Work in Progress, Internet Draft Feb 2002.
[11] Rosen, E et.al. "Use of PE-PE IPsec in RFC2547 VPNs", draft-
rosen-ppvpn-ipsec-2547-00.txt, Work in Progress, Internet Draft
Jun 2001.
[12] Heinanen, J "DNS/LDP Based VPLS", draft-heinanen-dns-ldp-vpls-
00.txt, Work in Progress, Internet Draft Jan 2002.
[13] Kompella, K. et.al. "Virtual Private LAN Service", draft-
kompella-ppvpn-vpls-00.txt, Work in Progress, Internet Draft
Nov 2001.
[14] Kompella, K. et.al. "Decoupled Virtual Private LAN Services"
draft-kompella-ppvpn-dtls-01.txt, Work in Progress, Internet
Draft Nov 2001.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 34]
[15] Khandekar, S. et.al. "Hierarchical Virtual Private LAN Service"
draft-khandekar-ppvpn-hvpls-mpls-00.txt, Work in Progress,
Internet Draft Nov 2001.
[16] Lasserre, M. et.al. "Transparent VLAN Services over MPLS",
draft-lasserre-vkompella-ppvpn-tls-00.txt, Work in Progress,
Internet Draft Nov 2001.
[17] Menezes, P. et.al. "Inter-City MAN Services Using MPLS", draft-
menezes-inter-city-man-mpls-00.txt, Work in Progress, Internet
Draft Nov 2001.
[18] Andersson, L. and Madsen T. "VPN Terminology", draft-andersson-
ppvpn-terminology-00.txt", Work in Progress, Internet Draft,
February 2002.
[19] Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-framework-04.txt,
Work in Progress, Internet Draft, February 2002.
[20] Ould-Brahim, H et.al "VPLS/LPE L2VPNs: Virtual Private LAN
Services using Logical PE Architecture" draft-ouldbrahim-l2vpn-
lpe-01.txt, Work in Progress, Internet Draft, November 2001.
[21] Augustyn, W. et al. "Requirements for Virtual Private LAN
Services (VPLS)", draft-augustyn-vpls-requirements-02.txt, Work
in progress, Internet Draft, February 2002.
This reference will be changed when a combined VPWS and VPLS
requirement draft is available.
[22] Sumimoto, J. et al "draft-sumimoto-ppvpn-applicability-
guidelines-02.txt" Work in progress, Internet Draft, February
2002.
[23] Andersson, L. "Parameters and related metrics to compare PPVPN
Layer 2 solutions", draft-andersson-ppvpn-metrics-00.txt, Work
in Progrss, Internet Draft, Feb 2002.
[24] Carugi, M. et.al. "Service requirements for Layer 3 Provider
Provisioned Virtual Private Networks" draft-ietf-ppvpn-
requirements-04.txt, Work in Progress, Internet Draft, Feb
2002.
[25] Rosen, E. "An Architecture for L2VPNs", draft-ietf-ppvpn-l2vpn-
00.txt, Work in Progress, Internet Draft July 2001.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 35]
[26] Shah, H. et.al. "ARP Mediation for IP interworking of Layer 2
VPN", draft-shah-ppvpn-arp-mediation-00.txt, Work in Progress,
Internet Draft, Feb 2002.
[27] Heinanen, J. "Inverse ARP over Unidirectional Virtual Circuits",
draft-heinanen-inarp-uni-01.txt, Work in Progress, Internet
Draft, March 2001.
[28] Heinanen, J. "Directory/LDP Based Unidirectional Virtual Circuit
VPNs", draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in
Progress, Internet Draft, Nov 2001.
[29] Sajassi, A. "VPLS Architectures", draft-sajassi-vpls-
architectures-00.txt, Work in Progress, Internet Draft, Feb
2002.
[30] Augustyn, W et.al. "Architecture and Model for Virtual Private
LAN Services (VPLS)", draft-augustyn-vpls-arch-00.txt, Work in
Progress, Internet Draft, Nov 2001.
[31] Augustyn, W. "Bandwidth Management in VPLS Networks", draft-
augustyn-vpls-bw-00.txt, Work in Progress, Internet Draft, Nov
2001.
[32] Shah, H. et.al. "Signaling between PE and L2PE/MTU for Decoupled
VPLS and Hierarchical VPLS", draft-shah-ppvpn-vpls-pe-mtu-
signaling-00.txt, Work in Progress, Internet Draft, Feb 2002.
[33] Chen, M et.al. "Decoupled/Hierarchical VPLS: Commonalities and
Differences", draft-chen-ppvpn-dvpls-compare-00.txt, Work in
Progressm Internet Draft, Feb 2002.
[34] Luciani, J. et.al. "Using DNS for VPN Discovery", draft-luciani-
ppvpn-vpn-discovery-01.txt, Work in Progress, Internet Draft,
Sep 2001.
[35] Rosen. E. et.al. "Use of PE-PE IPsec in RFC2547 VPNs", draft-
ietf-ppvpn-ipsec-2547-01.txt, Work in Progress, Internet Draft
February 2002.
[36] Senevirathne, T. et.al. "A Framework for Virtual Metropolitan
Internetworks (VMI)", draft-senevirathne-vmi-frame-02.txt, Work
in Progress, Internet Draft Feb 2002.
[37] Knight, P. et.al. "Logical PE Auto-Discovery Mechanism", draft-
knight-l2vpn-lpe-ad-00.txt, Work in Progress, Internet Draft
Nov 2001.
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002
Andersson Expires Sep 2002 [Page 36]
[38] Eliazer, E. et.al. "PPVPN Architecture using L2TP", draft-elwin-
ppvpn-l2tp-arch-00.txt, Work in Progress, Internet Draft Feb
2002.
[39] Lau, WC. Et.al. "Extensions of for QoS Support in Transparent
VLAN Services over MPLS", draft-lau-ppvpn-qos-tls-mpls-00.txt,
Work in Progress, Internet Draft Mar 2001.
[40] Senevirathne, T. "Virtual Private LAN Service (VPLS) Solution
Using GRE Based IP Tunnels", draft-tsenevir-gre-vpls-00.txt,
Work in Progress, Internet Draft Feb 2002.
[41] Cai, T. et.al. "Signaling Virtual Circuit Label Using RSVP-TE",
draft-cai-ppvpn-vc-rsvp-te-00.txt, Work in Progress, Internet
Draft Nov 2001.
[42] Rosen, E. et.al. "An Architecture for L2VPNs", draft-ietf-ppvpn-
l2vpn-00.txt, Work in Progress, Internet Draft Jul 2001.
10. Acknowledgements
This document is the outcome of discussions within the PPVPN Layer 2 VPN
design team. The members of the design team are Eric Rosen, Hamid Ould-
Brahim, Juha Heinanen, Kireeti Kompella, Loa Andersson, Marc Lasserre,
Marty Borden, Pascal Menezes, Vach Kompella and Waldemar Augustyn.
The team would like to thank Marco Carugi for cooperation in setting up
context and working directions in this space.
11. Authors Contact
Loa Andersson (editor)
Utfors AB
P.O Box 525
SE-169 29 Solna
tel: +46 8 52 70 50 38
email: loa.andersson@utfors.se
INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002