L2VPN service to another SP. One example is when one SP sells L2VPN
service at wholesale to another SP, who then resells that L2VPN
service to his or her customers.
7.9. Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD be
able to use a range of tunneling technologies, such as L2TP, GRE,
IP-in-IP, MPLS, etc.
Every PE MUST support a tunnel setup protocol, if tunneling is used.
A PE MAY support static configuration. If employed, a tunnel
establishment protocol SHOULD be capable of conveying information,
such as the following:
- Relevant identifiers
- QoS/SLS parameters
- Restoration parameters
- Multiplexing identifiers
- Security parameters
There MUST be a means to monitor the following aspects of tunnels:
- Statistics, such as amount of time spent in the up and down state
- Count of transitions between the up and down state
- Events, such as transitions between the up and down states
The tunneling technology used by the VPN SP and its associated
mechanisms for tunnel establishment, multiplexing, and maintenance
MUST meet the requirements on scaling, isolation, security, QoS,
manageability, etc.
Regardless of the tunneling choice, the existence of the tunnels and
their operations MUST be transparent to the customers.
7.10. Support for Access Technologies
The connectivity between PE and CE devices is referred to as an AC.
ACs MAY span networks of other providers or public networks.
There are several choices for implementing ACs. Some popular choices
include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual circuits
etc.
In case of VPLS, the AC MUST use Ethernet frames as the Service
Protocol Data Unit (SPDU).
A CE access connection over an AC MUST be bi-directional.
PE devices MAY support multiple ACs on a single physical interface.
In such cases, PE devices MUST NOT rely on customer controlled
parameters for distinguishing between different access connections.
For example, if VLAN tags were used for that purpose, the provider
would be controlling the assignment of the VLAN tag values and would
strictly enforce compliance by the CEs.
An AC, whether direct or virtual, MUST maintain all committed
characteristics of the customer traffic, such as QoS, priorities etc.
The characteristics of an AC are only applicable to that connection.
7.11. Backbone Networks
Ideally, the backbone interconnecting the SP’s PE and P devices
SHOULD be independent of physical and link-layer technology.
Nevertheless, the characteristics of backbone technology MUST be
taken into account when specifying the QoS aspects of SLSes for VPN
service offerings.
7.12. Network Resource Partitioning and Sharing Between L2VPNs
In case network resources such as memory space, forwarding
information base table, bandwidth, and CPU processing are shared
between L2VPNs, the solution SHOULD guarantee availability of
resources necessary to prevent any specific L2VPN service instance
from taking up available network resources and causing others to
fail. The solution SHOULD be able to limit the resources consumed by
an L2VPN service instance. The solution SHOULD guarantee
availability of resources necessary to fulfill the obligation of
committed SLSes.
7.13. Interoperability
Service providers are interested in interoperability in at least the
following scenarios:
- To facilitate use of PE and managed CE devices within a single SP
network
- To implement L2VPN services across two or more interconnected SP
networks
- To achieve inter-working or interconnection between customer sites
using different L2VPN solutions or different implementations of the
same approach
Each approach MUST describe whether any of the above objectives can
be met. If an objective can be met, the approach MUST describe how
such interoperability could be achieved.
7.14. Testing
The L2VPN solution SHOULD provide the ability to test and verify
operational and maintenance activities on a per L2VPN service basis,
and, in case of VPLS, on a per-VLAN basis if customer VLANs are used
as service delimiters.
The L2VPN solution SHOULD provide mechanisms for connectivity
verification, and for detecting and locating faults.
Examples of testing mechanisms are as follows:
- Checking connectivity between "service-aware" network nodes
- Verifying data plane and control plane integrity
- Verifying service membership
The provided mechanisms MUST satisfy the following: the connectivity
checking for a given customer MUST enable the end-to-end testing of
the data path used by that of customer’s data packets, and the test
packets MUST not propagate beyond the boundary of the SP network.
7.15. Support on Existing PEs
To the extent possible, the IPLS solution SHOULD facilitate support
of IPLS on existing PE devices that may be already deployed by the SP
and MAY have been designed primarily for Layer 3 services.
8. Service Provider Management Requirements
An SP desires to have a means to view the topology, operational
state, and other parameters associated with each customer’s L2VPN.
Furthermore, the SP requires a means to view the underlying logical
and physical topology, operational state, provisioning status, and
other parameters associated with the equipment providing the L2VPN
service(s) to its customers. Therefore, the devices SHOULD provide
standards-based interfaces (e.g., L2VPN MIB Modules), wherever
feasible.
The details of service provider management requirements for a Network
Management System (NMS) in the traditional fault, configuration,
accounting, performance, and security (FCAPS) management categories
can be found in [ITU_Y.1311.1].
9. Engineering Requirements
These requirements are driven by implementation characteristics that
make service and SP requirements achievable.
9.1. Control Plane Requirements
An L2VPN service SHOULD be provisioned with minimum number of steps.
Therefore, the control protocols SHOULD provide methods for signaling
between PEs. The signaling SHOULD inform of membership, tunneling
information, and other relevant parameters.
The infrastructure MAY employ manual configuration methods to provide
this type of information.
The infrastructure SHOULD use policies to scope the membership and
reachability advertisements for a particular L2VPN service. A
mechanism for isolating the distribution of reachability information
to only those sites associated with an L2VPN MUST be provided.
The control plane traffic increases with the growth of L2VPN
membership. Similarly, the control plane traffic increases with the
number of supported L2VPN services. The use of control plane
resources MAY increase as the number of hosts connected to an L2VPN
service grows.
An L2VPN solution SHOULD minimize control plane traffic and the
consumption of control plane resources. The control plane MAY offer
means for enforcing a limit on the number of customer hosts attached
to an L2VPN service.
9.2. Data Plane Requirements
9.2.1. Encapsulation
An L2VPN solution SHOULD utilize the encapsulation techniques defined
by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on
these techniques.
9.2.2. Responsiveness to Congestion
An L2VPN solution SHOULD utilize the congestion avoidance techniques
defined by PWE3 ([RFC3985]).
9.2.3. Broadcast Domain
A separate Broadcast Domain MUST be maintained for each VPLS.
In addition to VPLS Broadcast Domains, an L2VPN service MAY honor
customer VLAN Broadcast Domains, if customer VLANs are used as
service delimiters. In that case, the L2VPN solution SHOULD maintain
a separate VLAN Broadcast Domain for each customer VLAN.
9.2.4. Virtual Switching Instance
L2VPN PE devices MUST maintain a separate VSI per VPLS. Each VSI
MUST have capabilities to forward traffic based on customer’s traffic
parameters, such as MAC addresses, VLAN tags (if supported), etc. as
well as local policies.
L2VPN PE devices MUST have capabilities to classify incoming customer
traffic into the appropriate VSI.
Each VSI MUST have flooding capabilities for its Broadcast Domain to
facilitate proper forwarding of Broadcast, Multicast, and Unknown
Unicast customer traffic.
9.2.5. MAC Address Learning
A VPLS SHOULD derive all topology and forwarding information from
packets originating at customer sites. Typically, MAC address
learning mechanisms are used for this purpose. With IPLS, snooping
of particular packets originating at customer sites and signaling
might also be used.
Dynamic population of the forwarding information base (e.g., via MAC
address learning) MUST take place on a per VSI basis; i.e., in the
context of a VPLS and, if supported, in the context of VLANs therein.
10. Security Considerations
Security considerations occur at several levels and dimensions within
L2VPNs, as detailed within this document.
The requirements based on security concerns and potential security
hazards are detailed in Section 6.5. Further details on security
requirements are given from the customer and service provider
perspectives in Sections 6.5 and 7.6, respectively. In an analogous
manner, further detail on traffic and routing isolation requirements
are given from the customer and service provider perspectives in
Sections 5.4 and 7.5, respectively. Safeguards to protect network
resources such as CPU, memory, and bandwidth are required in Section
7.12.
IPsec can also be applied after tunneling Layer 2 traffic to provide
additional security.
In the case where an L2VPN service is carried over IP [RFC4023],
traverses multiple SP networks and passes through an unsecured SP,
POP, NAP, or IX, then security mechanisms MUST be employed. These
security mechanisms include encryption, authentication, and resource
protection, as described in section 5.5. For example, a provider
should consider using both authentication and encryption for a tunnel
used as part of an L2VPN that traverses another service provider’s
network.
11. Acknowledgements
The authors would like to acknowledge extensive comments and
contributions provided by Loa Andersson, Joel Halpern, Eric Rosen,
Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov
Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le
Faucheur. The authors also wish to extend their appreciation to
their respective employers and various other people who volunteered
to review this work and provided feedback. This work was done in
consultation with the entire Layer 2 PPVPN design team. A lot of the
text was adapted from the Layer 3 VPN requirements document produced
by the Layer 3 VPN requirements design team.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
12.2. Informative References
[VPLS_LDP] Lasserre, M., Kompella, V. "Virtual Private LAN
Services over MPLS", Work in Progress.
[VPLS_BGP] Kompella, K., Rekhter, Y. "Virtual Private LAN
Service", Work in Progress.
[IPLS] Shah, H., et al. "IP-Only LAN Service (IPLS)", Work
in Progress.
[IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area
Networks", 1998
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce,
"Layer Two Tunneling Protocol (L2TP) Differentiated
Services Extension", RFC 3308, November 2002.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for
Layer 3 Provider Provisioned Virtual Private Networks
(PPVPNs)", RFC 4031, April 2005.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
Edition (Revision and redesignation of ISO/IEC
10038:98), "Part 3: Media Access Control (MAC)
Bridges", 1998.
[ITU_Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS
architecture",Y.1311.1 ITU-T Recommendation, May
2001.
[IEEE_802.10] IEEE Std 802.10-1998 Edition (Revision IEEE Std
802.10-1992, incorporating IEEE Std 802.10b-1992,
802.10e-1993, 802.10f-1993, 802.10g-1995, and
802.10h-1997), "Standard for Interoperable LAN/MAN
Security (SILS)", 1998.
[IEEE_802.1AE] IEEE 802.1AE/D5.1, "Draft Standard for Local and
Metropolitan Area Networks - Media Access Control
(MAC) Security", P802.1AE/D5.1, January 19, 2006.
[IEEE_802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area
Networks-Amendment 3: Multiple Spanning Trees", 2002.
Editors’ Addresses
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Yetik Serbest
AT&T Labs
9505 Arboretum Blvd.
Austin, TX 78759
EMail: yetik_serbest@labs.att.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).