Layer 2 Virtual Private Networks (l2vpn) Internet Drafts
| Provisioning,Autodiscovery,and Signaling in L2VPNs | |||||||||||||||||
|
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). | ||||||||||||||||
| IP-Only LAN Service (IPLS) | |||||||||||||||||
|
A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. | ||||||||||||||||
| L2VPN OAM Requirements and Framework | |||||||||||||||||
|
This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PWOAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. | ||||||||||||||||
| ARP Mediation for IP Interworking of Layer 2 VPN | |||||||||||||||||
|
The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. | ||||||||||||||||
| Requirements for Multicast Support in Virtual Private LAN Services | |||||||||||||||||
|
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. | ||||||||||||||||
| Multicast in VPLS | |||||||||||||||||
|
This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSs are also described. | ||||||||||||||||
| VPLS Interoperability with CE Bridges | |||||||||||||||||
|
One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE bridged networks. When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have currently been addressed in the IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible suggests areas to be explored in rectifying these issues. | ||||||||||||||||
| Virtual Private Lan Services (VPLS) Management Information Base | |||||||||||||||||
|
This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pseudo Wire (PW) Management Information Base [PWE3-PW-MIB]. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Layer 2 Virtual Private Networks (l2vpn)
Last Modified: 2008-04-22
Additional information is available at tools.ietf.org/wg/l2vpn
Chair(s):
Internet Area Director(s):
Internet Area Advisor:
Technical Advisor(s):
Mailing Lists:
General Discussion: l2vpn@ietf.orgTo Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn
Archive: http://www.ietf.org/mail-archive/web/l2vpn/index.html
Description of Working Group:
Alex Zinin is the routing advisor.Russ Housley is the security advisor.
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).
The WG is responsible for standardization of the following solutions:
1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
across an IP and an MPLS-enabled IP network, allowing standard
Ethernet devices communicate with each other as if they were
connected to a common LAN segment.
2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
point-to-point Ethernet) across an IP and an MPLS-enabled IP
network.
3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP
network, allowing standard IP devices to communicate with each
other as if they were connected to a common LAN or with some mesh
of point-to-point circuits (not necessarily fully meshed). The WG
will address both of the following cases:
- the customer attachment uses the same L2 protocol at all
attachment points in the L2VPN.
- the customer attachment uses different L2 protocols at the
attachment points in the L2VPN. This case is intended to address
the needs of service providers who may start out with a single L2
protocol at attachment points, but wish to incrementally upgrade
individual attachment points over time to newer technologies. This
is a restricted form of "interworking" that is limited to
providing the facilities necessary to carry IP over the L2VPN;
general L2 interworking is not in scope.
The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)
As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
L2VPN WG will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.
The WG will work on the following items. Adding new work items will
require rechartering.
1. Discovery of PEs participating in L2 service, and topology of
required connectivity
2. Signaling of l2vpn related information for the purpose of
setup and maintenance of l2vpn circuits. As much as possible
PWE3 signaling procedures should be used
3. Solution documents (providing the framework for a specific
solution, should include info on how discovery, signaling,
and encaps work together, include security, AS as a separate
document)
4. MIBs
5. L2VPN-specific OAM extensions--extensions to existing OAM
solutions for VPLS, VPWS, and IP-only L2VPNs.
Where necessary, the WG will coordinate its activities with IEEE 802.1
Goals and Milestones:
| Aug 2003 | Submit an I-D describing MIB for VPLS | |
| Aug 2003 | Submit an I-D describing MIB for VPWS | |
| Aug 2003 | Submit an I-D on OAM for VPLS | |
| Aug 2003 | Submit an I-D on OAM for VPWS | |
| Oct 2003 | Submit L2 requirements to IESG for publication as Informational RFC | |
| Done | Identify VPLS and VPWS solutions for the WG | |
| Done | Submit L2 framework to IESG for publication as Informational RFC | |
| Dec 2003 | Submit VPLS solution documents to IESG | |
| Dec 2003 | Submit VPWS solution documents to IESG | |
| Jan 2004 | Submit IP-only L2VPN solution documents to IESG | |
| Feb 2004 | Submit MIB for VPLS to IESG | |
| Feb 2004 | Submit MIB for VPWS to IESG | |
| Mar 2004 | Submit OAM for VPWS to IESG | |
| Mar 2004 | Submit OAM for VPLS to IESG | |
| Apr 2004 | Submit OAM for IP L2VPN to IESG |
Internet-Drafts:
Provisioning, Autodiscovery, and Signaling in L2VPNs (79994 bytes)IP-Only LAN Service (IPLS) (62338 bytes)
L2VPN OAM Requirements and Framework (85550 bytes)
ARP Mediation for IP Interworking of Layer 2 VPN (59740 bytes)
Requirements for Multicast Support in Virtual Private LAN Services (66726 bytes)
Multicast in VPLS (97659 bytes)
VPLS Interoperability with CE Bridges (53289 bytes)
Virtual Private Lan Services (VPLS) Management Information Base (92198 bytes)
Request For Comments:
Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks (RFC 4665) (68972 bytes)Framework for Layer 2 Virtual Private Networks (L2VPNs) (RFC 4664) (97768 bytes)
Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (RFC 4762) (68070 bytes)
Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling (RFC 4761) (65219 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
