RFC 4665
Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks
RFC 4665: Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks 🎀
Okay bestie, so this is RFC 4665 ✨. It's an Informational doc from September 2006, written by Waldemar Augustyn and Yetik Serbest (both listed as editors, "Ed.") from AT&T 💖. It doesn't obsolete or update any other RFCs, since the header doesn't list any.
Status of This Memo 📜
This memo gives information to the Internet community. It is not an Internet standard of any kind 🙈. Distribution of this memo is unlimited 🦋.
Copyright Notice ⭐
Copyright (C) The Internet Society (2006).
Abstract 🍓
This doc lays out requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs) 🧚. It starts with taxonomy, terminology, and generic and general service requirements. It covers point-to-point VPNs, called Virtual Private Wire Service (VPWS), and multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS) 🌈. The detailed requirements are written from both the customer's and the service provider's perspectives 💅.
Table of Contents 🗂️
1. Introduction ....................................................4
1.1. Scope of This Document .....................................4
1.2. Outline ....................................................5
2. Conventions used in this document ...............................5
3. Contributing Authors ............................................5
4. Definitions and Taxonomy ........................................5
4.1. Definitions ................................................5
4.2. Taxonomy of L2VPN Types ....................................6
4.3. VPWS .......................................................6
4.4. VPLS .......................................................7
5. Service Requirements Common to Customers and Service Providers ..7
5.1. Scope of emulation .........................................8
5.2. Traffic Types ..............................................8
5.3. Topology ...................................................8
5.4. Isolated Exchange of Data and Forwarding Information .......9
5.5. Security ...................................................9
5.5.1. User Data Security .................................10
5.5.2. Access Control .....................................10
5.6. Addressing ................................................11
5.7. Quality of Service ........................................11
5.7.1. QoS Standards ......................................11
5.7.2. Service Models .....................................11
5.8. Service Level Specifications ..............................12
5.9. Protection and Restoration ................................12
5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
5.11. Management ...............................................12
5.12. Interoperability .........................................12
5.13. Inter-working ............................................13
6. Customer Requirements ..........................................13
6.1. Service Provider Independence .............................13
6.2. Layer 3 Support ...........................................13
6.3. Quality of Service and Traffic Parameters .................14
6.4. Service Level Specification ...............................14
6.5. Security ..................................................14
6.5.1. Isolation ..........................................14
6.5.2. Access Control .....................................14
6.5.3. Value-Added Security Services ......................15
6.6. Network Access ............................................15
6.6.1. Physical/Link Layer Technology .....................15
6.6.2. Access Connectivity ................................15
6.7. Customer Traffic ..........................................17
6.7.1. Unicast, Unknown Unicast, Multicast, and
Broadcast forwarding ...............................17
6.7.2. Packet Re-ordering .................................17
6.7.3. Minimum MTU ........................................17
6.7.4. End-point VLAN Tag Translation .....................18
6.7.5. Transparency .......................................18
6.8. Support for Layer 2 Control Protocols .....................18
6.9. CE Provisioning ...........................................19
7. Service Provider Network Requirements ..........................19
7.1. Scalability ...............................................19
7.1.1. Service Provider Capacity Sizing Projections .......19
7.1.2. Solution-Specific Metrics ..........................19
7.2. Identifiers ...............................................19
7.3. Discovering L2VPN Related Information .....................19
7.4. Quality of Service (QoS) ..................................20
7.5. Isolation of Traffic and Forwarding Information ...........20
7.6. Security ..................................................21
7.7. Inter-AS/SP L2VPNs ........................................22
7.7.1. Management .........................................22
7.7.2. Bandwidth and QoS Brokering ........................22
7.8. L2VPN Wholesale ...........................................23
7.9. Tunneling Requirements ....................................23
7.10. Support for Access Technologies ..........................23
7.11. Backbone Networks ........................................24
7.12. Network Resource Partitioning and Sharing Between
L2VPNs ...................................................24
7.13. Interoperability .........................................24
7.14. Testing ..................................................25
7.15. Support on Existing PEs ..................................25
8. Service Provider Management Requirements .......................26
9. Engineering Requirements .......................................26
9.1. Control Plane Requirements ................................26
9.2. Data Plane Requirements ...................................27
9.2.1. Encapsulation ......................................27
9.2.2. Responsiveness to Congestion .......................27
9.2.3. Broadcast Domain ...................................27
9.2.4. Virtual Switching Instance .........................27
9.2.5. MAC Address Learning ...............................27
10. Security Considerations .......................................28
11. Acknowledgements ..............................................28
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................291. Introduction ✨
This section sets the scene: the scope and outline of the document 🌸.
1.1. Scope of This Document
This doc gives requirements for provider-provisioned Layer 2 Virtual Private Networks (L2VPN) 💜. It names requirements that MAY apply to one or more individual approaches a Service Provider (SP) might use to provision a Layer 2 VPN service. It uses the terminology defined in [RFC4026], plus common components for deploying L2VPNs described in [RFC4664] 🦋.
The technical specs for providing L2VPN services are out of scope here 🙈. The framework doc [RFC4664] and several other docs that explain technical approaches to L2VPN services, like [VPLS_LDP], [VPLS_BGP], and [IPLS], cover that part 📚.
This doc describes two types of L2VPNs: (1) Virtual Private Wire Service (VPWS), and (2) Virtual Private LAN Service (VPLS) 🫶. The approach here tells L2VPN types apart by how the connectivity is provided (point-point or multipoint-multipoint), as detailed in [RFC4664] 💅.
This doc is meant to be a "checklist" of requirements 📝. It gives a consistent way to evaluate and document how well each individual approach meets specific requirements. The applicability statement for each individual approach should document the results of that evaluation 🎀.
With provider-provisioned VPNs, two entities are involved: the Provider and the Customer 👑. The Provider makes a binding agreement with the Customer about how the service behaves in normal situations and in exceptional ones. That agreement is the Service Level Specification (SLS), which is part of the Service Level Agreement (SLA) between Provider and Customer 💖.
A well-designed L2VPN makes SLSes easier to write 🧚. It separates the Customer Edge (CE) from the Provider Edge (PE) properly, lets the SLS offer run as intended, and supports a flexible, rich set of capabilities ✨.
This doc states requirements from both the Provider's and the Customer's point of view 🌈. It starts with what customers and service providers have in common, then covers the customer's perspective, and wraps up with specific SP needs. These requirements list the high-level L2VPN features an SP expects when provisioning L2VPNs, including SP requirements for security, privacy, manageability, interoperability, and scalability 🔥.
1.2. Outline
Here's the rest of the doc, roughly 🗺️. Section 4 covers definitions and taxonomy. Section 5 covers common requirements that apply to both customer and SP. Section 6 states requirements from the customer's perspective. Section 7 states network requirements from the SP's perspective. Section 8 covers SP management requirements. Section 9 describes the engineering requirements, especially control and data plane requirements. Section 10 has security considerations. Section 11 lists acknowledgements. Section 12 lists the references cited here 💅.
2. Conventions used in this document 📖
Here's the important bit 🔥: 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 [RFC2119] 🎀.
3. Contributing Authors 🧚
This doc was a team effort from several individuals 🫶. These are the authors who contributed:
- Waldemar Augustyn
- Marco Carugi
- Giles Heron
- Vach Kompella
- Marc Lasserre
- Pascal Menezes
- Hamid Ould-Brahim
- Tissa Senevirathne
- Yetik Serbest
4. Definitions and Taxonomy 🌷
4.1. Definitions
The terminology in this doc is defined in [RFC4026] 📚. The L2VPN framework doc [RFC4664] goes further into these concepts, using a reference model that defines layered service relationships between devices and one or more levels of tunnels 🦋.
4.2. Taxonomy of L2VPN Types ✨
okay so the requirements split L2VPNs into two major models 🎀: a Virtual Private Wire Service (VPWS) and a Virtual Private LAN Service (VPLS). this is the main fork in the road bestie 🛣️💖
here's the L2VPN reference model, it's giving everything 🦋
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN AFigure 1. L2VPN Reference Model
4.3. VPWS
so with VPWS 💅, the PE devices give you a logical interconnect so that a pair of CE devices looks like it's connected by one single logical Layer 2 circuit 🧚. the PEs act as Layer 2 circuit switches, and those Layer 2 circuits then get mapped onto tunnels in the SP network. those tunnels can either be specific to one particular VPWS, or be shared among several services. VPWS works for all services, including Ethernet, ATM, Frame Relay, etc. in Figure 1, L2VPN B is the VPWS case 🌸
each PE device is responsible for allocating customer Layer 2 frames to the appropriate VPWS, and for proper forwarding to the intended destinations 🫶
4.4. VPLS
now VPLS is giving main character energy 👑. the PE devices provide a logical interconnect so that CE devices belonging to a specific VPLS appear to be connected by a single LAN 🌈. end-to-end VPLS is made up of a bridge module and a LAN emulation module ([RFC4664]). a VPLS can contain a single VLAN or multiple VLANs ([IEEE_802.1Q]). there's also a variation called IPLS ([RFC4664]), which is limited to supporting only customer IP traffic 🍓
in a VPLS, a customer site gets Layer 2 service from the SP. the PE is attached via an access connection to one or more CEs. the PE forwards user data packets based on information in the Layer 2 header, such as a MAC destination address. in Figure 1, L2VPN A is the VPLS case ✨
the details of the VPLS reference model (we're summarising it here, the full tea is in [RFC4664]) are as follows 🧠. in VPLS, the PE can be viewed as containing a Virtual Switching Instance (VSI) for each L2VPN that it serves. a CE device attaches, possibly through an access network, to a bridge module of a PE. inside the PE, the bridge module attaches through an Emulated LAN Interface to an Emulated LAN. for each VPLS there is an Emulated LAN instance. the Emulated LAN is made of VPLS Forwarder modules (one per PE per VPLS service instance) connected by pseudo wires (PW), and the PWs may be traveling through Packet Switched Network (PSN) tunnels over a routed backbone 🦋
a VSI is a logical entity that contains a VPLS forwarder module and part of the bridge module relevant to the VPLS service instance [RFC4664]. so the VSI terminates PWs for interconnection with other VSIs, and it also terminates Attachment Circuits (ACs) (see [RFC3985] for definition) for accommodating CEs 💜. a VSI includes the forwarding information base for an L2VPN [RFC4664]. that's the set of info about how to forward Layer 2 frames received over the AC from the CE to VSIs in other PEs supporting the same L2VPN service (and/or to other ACs), and it also holds info on how to forward Layer 2 frames received from PWs to ACs 🎀. forwarding information bases can be populated dynamically (such as by source MAC address learning) or statically (e.g., by configuration) 🌷. bottom line, each PE device is responsible for proper forwarding of the customer traffic to the appropriate destination(s), based on the forwarding information base of the corresponding VSI 💖
5. Service Requirements Common to Customers and Service Providers ✨
this section has the requirements that apply to both the customer and the provider, or that are otherwise general in nature 🌍
5.1. Scope of emulation
L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols and standards of the Layer 2 network the customer is managing. if they impact customer Layer 2 protocols that are sent over the VPLS, then those impacts MUST be documented 📝
some possibly salient differences between VPLS and a real LAN 🙈:
- the reliability may likely be less. like, the probability that a message broadcast over the VPLS is not seen by one of the bridge modules in PEs is higher than in a true Ethernet 💀
- VPLS frames can get duplicated if the PW sequencing option isn't turned on. the data frames on the PWs are sent in IP datagrams, and under certain failure scenarios IP networks can duplicate packets. if the PW data transmission protocol does not ensure sequence of data packets, frames can be duplicated or received out of sequence. if the customer's Bridge Protocol Data Unit (BPDU) frames are sent as data packets, then BPDU frames can be duplicated or mis-sequenced, although this may not create any problems for Real-Time Streaming Protocol (RSTP) 😭
- delayed delivery of packets (e.g., more than half a second), rather than dropping them, could have an adverse effect on the performance of the service 🥀
- 802.3x Pause frames will not be transported over a VPLS, as the bridge module ([RFC4664]) in the PE terminates them 🚫
- since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution is NOT REQUIRED to preserve the Layer 2 Header transparently from CE to CE. for example, Source MAC address will probably not be preserved by the IPLS solution 🫠
5.2. Traffic Types
a VPLS MUST support unicast, multicast, and broadcast traffic 📡. support for efficient replication of broadcast and multicast traffic is highly desirable 🔥
5.3. Topology
an SP network may be realized using one or more network tunnel topologies to interconnect PEs, ranging from simple point-to-point to distributed hierarchical arrangements 🗺️. the typical topologies include:
- Point-to-point
- Point-to-multipoint, a.k.a. hub and spoke
- Any-to-any, a.k.a. full mesh
- Mixed, a.k.a. partial mesh
- Hierarchical
regardless of the SP topology employed, the service to the customers MUST retain the connectivity type implied by the type of L2VPN. for example, a VPLS MUST allow multipoint-to-multipoint connectivity even if it is implemented with point-to-point circuits 🦄. this requirement does not imply that all traffic characteristics (such as bandwidth, QoS, delay, etc.) necessarily be the same between any two end points of an L2VPN. it's important to note that SLS requirements of a service have a bearing on the type of topology that can be used 💅
to the extent possible, an L2VPN service SHOULD be capable of crossing multiple administrative boundaries 🛂
to the extent possible, the L2VPN services SHOULD be independent of access network technology 🌐
5.4. Isolated Exchange of Data and Forwarding Information
L2VPN solutions SHALL define means that prevent CEs in an L2VPN from interaction with unauthorized entities 🔒
L2VPN solutions SHALL avoid introducing undesired forwarding information that could corrupt the L2VPN forwarding information base 🧹
a means to constrain or isolate the distribution of addressed data to only those VPLS sites determined either by MAC learning and/or configuration MUST be provided 🫧
the internal structure of an L2VPN SHOULD not be advertised or discoverable from outside that L2VPN 🤫
5.5. Security
a range of security features MUST be supported by the suite of L2VPN solutions. each L2VPN solution MUST state which security features it supports and how such features can be configured on a per-customer basis 🛡️
a number of security concerns come up in the setup and operation of an L2VPN 😱. they range from misconfigurations to attacks that can be launched on an L2VPN and can strain network resources such as memory space, forwarding information base table, bandwidth, and CPU processing 🚨
this section lists some potential security hazards that can result from mis-configurations and/or malicious attacks. there MUST be methods available to protect against the following situations. ⚠️
- Protocol attacks
- Excessive protocol adjacency setup/teardown
- Excessive protocol signaling/withdrawal
- Resource Utilization
- Forwarding plane replication (VPLS)
- Looping (VPLS primarily)
- MAC learning table size limit (VPLS)
- Unauthorized access
- Unauthorized member of VPN
- Incorrect customer interface
- Incorrect service delimiting VLAN tag
- Unauthorized access to PE
- Tampering with signaling
- Incorrect FEC signaling
- Incorrect PW label assignment
- Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- Tampering with data forwarding
- Incorrect MAC learning entry
- Incorrect PW label
- Incorrect AC identifier
- Incorrect customer facing encapsulation
- Incorrect PW encapsulation
- Hijacking PWs using the wrong tunnel
- Incorrect tunnel encapsulation
5.5.1. User Data Security
an L2VPN solution MUST provide traffic separation between different L2VPNs 🧱
in case of VPLS, VLAN Ids MAY be used as service delimiters. when used in this manner, they MUST be honored and traffic separation MUST be provided 🎀
5.5.2. Access Control
an L2VPN solution MAY also have the ability to activate the appropriate filtering capabilities upon request of a customer 🎛️
5.6. Addressing
an L2VPN solution MUST support overlapping addresses of different L2VPNs. for instance, customers MUST NOT be prevented from using the same MAC addresses with different L2VPNs 🪞. if a service provider uses VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN Ids cannot overlap. if VLANs are not used as service delimiters, L2VPN solutions MAY allow VLAN Ids to overlap 🧩
5.7. Quality of Service
to the extent possible, L2VPN QoS SHOULD be independent of the access network technology 🌸
5.7.1. QoS Standards
as provided in [RFC3809], an L2VPN SHALL be able to support QoS in one or more of the following already standardized modes ✨:
- Best Effort (support mandatory for all provider-provisioned VPN types)
- Aggregate CE Interface Level QoS (i.e., 'hose' level)
- Site-to-site, or 'pipe' level QoS
note that all cases involving QoS MAY require that the CE and/or PE perform shaping and/or policing 🍭
mappings or translations of Layer 2 QoS parameters into PSN QoS (e.g., DSCPs or MPLS EXP field), as well as QoS mapping based on VC (e.g., FR/ATM or VLAN), MAY be performed in order to provide QoS transparency 🌈. the actual mechanisms for these mappings or translations are outside the scope of this document. in addition, the Diffserv support of underlying tunneling technologies (e.g., [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be used 💫. as such, the L2VPN SLS requirements SHOULD be supported by appropriate core mechanisms 🫶
5.7.2. Service Models ✨
okay bestie, so a service provider may want to sell QoS to a customer as at least these generic service types: a managed access VPN service or an edge-to-edge QoS service 💅 the details of those service models live in [RFC3809] and [RFC4031], so go check those out 🧚
In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) fields may be used for this purpose 🎀
5.8. Service Level Specifications
for an L2VPN service, the capabilities for Service Level Specification (SLS) monitoring and reporting stated in [RFC3809] SHOULD be provided 📊✨
5.9. Protection and Restoration
the L2VPN service infrastructure SHOULD provide redundant paths to ensure high availability 🛡️ and when something fails, the reaction SHOULD result in an attempt to restore the service using alternative paths 🦋
the whole point is to keep the restoration time small 🏃♀️💨 the restoration time MUST be less than the time it takes the CE devices, or customer Layer 2 control protocols as well as Layer 3 routing protocols, to detect a failure in the L2VPN 😭 like, it has to be faster than the customer's own gear noticing something is wrong. no cap, that's the bar 💀
5.10. CE-to-PE and PE-to-PE Link Requirements
the CE-to-PE links MAY be 🔗
- direct physical links (e.g., 100BaseTX, and T1/E1 TDM),
- logical links (e.g., ATM PVC, and RFC2427-encapsulated link),
- transport networks carrying Ethernet,
- a Layer 2 tunnel that goes through a Layer 3 network (e.g., L2TP sessions).
Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to PE, using one of a variety of tunneling technologies (e.g., IP-in-IP, GRE, MPLS, L2TP, etc.) 🚇🌸
5.11. Management
standard interfaces to manage L2VPN services MUST be provided (e.g., standard SNMP MIB Modules) 🎛️ and these interfaces SHOULD provide access to configuration, verification and runtime monitoring protocols 👀
service management MAY include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Performance, and Security, as detailed in [ITU_Y.1311.1] 🗂️✨
5.12. Interoperability
multi-vendor interoperability, which corresponds to similar network and service levels among different implementations, at the network element SHOULD be guaranteed 🤝 this will likely rely on the completeness of the corresponding standard 📚
the technical solution MUST be multi-vendor interoperable, not only within the SP network infrastructure, but also with the customer's network equipment and services making use of the L2VPN service 💖
a L2VPN solution SHOULD NOT preclude different access technologies 🙅♀️ for instance, customer access connections to an L2VPN service MAY be different at different CE devices (e.g., Frame Relay, ATM, 802.1D, MPLS) 🌈
5.13. Inter-working
inter-working scenarios among different solutions providing L2VPN services are highly desirable 😍 it's possible to have cases that require inter-working or interconnection between customer sites, which span network domains with different L2VPN solutions or different implementations of the same approach. inter-working SHOULD be supported in a scalable manner 📈
inter-working scenarios MUST consider at least traffic isolation, security, QoS, access, and management aspects 🔐 this requirement is essential in the case of network migration, to ensure service continuity among sites belonging to different portions of the network 🫶
6. Customer Requirements 👑
this section captures requirements from a customer perspective 💅
6.1. Service Provider Independence
customers MAY require L2VPN service that spans multiple administrative domains or SP networks 🗺️ therefore, an L2VPN service MUST be able to span multiple AS and SP networks but still to act and to appear as a single, homogeneous L2VPN from a customer point of view ✨
a customer might also start with an L2VPN provided in a single AS with a certain SLS but then ask for an expansion of the service spanning multiple ASes and/or multiple-SPs. in this case, as well as for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service SHOULD be able to deliver the same SLS to all sites in a VPN regardless of the AS/SP to which it homes 🏡💕
6.2. Layer 3 Support
with the exception of IPLS, an L2VPN service SHOULD be agnostic to customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated within Layer 2 frames 🫠
IPLS MUST allow transport of customer's IPv4 and IPv6 traffic encapsulated within Layer 2 frames 🌐 IPLS SHOULD also allow CEs to run ISIS and MPLS protocols transparently among them when those are used in conjunction with IP 🧚♀️
6.3. Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of an L2VPN service for some customers 💯
a customer requires that the L2VPN service provide the QoS applicable to his or her application, which can range from PWs (e.g., SONET emulation) to voice, interactive video, and multimedia applications 🎥 hence, best-effort as well as delay and loss sensitive traffic MUST be supported over an L2VPN service 🙌 a customer application SHOULD experience consistent QoS independent of the access network technology used at different sites connected to the same L2VPN 🍓
6.4. Service Level Specification
most customers simply want their apps to perform well 🥹 a SLS is a vehicle for a customer to measure the quality of the service that SP(s) provide. therefore, when purchasing a service, a customer requires access to the measures from the SP(s) that support the SLS 📈
standard interfaces to monitor usage of L2VPN services SHOULD be provided (e.g., standard SNMP MIB Modules) 👩💻✨
6.5. Security
6.5.1. Isolation
an L2VPN solution MUST provide traffic as well as forwarding information base isolation for customers similar to that obtained in private lines, FR, or ATM services 🔒
an L2VPN service MAY use customer VLAN Ids as service delimiters. in that case, they MUST be honored, and traffic separation MUST be provided 🫧
6.5.2. Access Control
an L2VPN solution MAY have the mechanisms to activate the appropriate filtering capabilities upon request of a customer 🚦 for instance, MAC and/or VLAN filtering MAY be considered between CE and PE for a VPLS 🧐
6.5.3. Value-Added Security Services
an L2VPN solution MAY provide value-added security services such as encryption and/or authentication of customer packets, certificate management, and similar services 🎁
L2VPN services MUST NOT interfere with the security mechanisms employed at Layer 3 and higher layers by customers 🙅♀️ Layer 2 security mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE ([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service delimiting VLAN Ids are encrypted 🔐👀
Security is not a joke, bestie. Keep the Layer 3 and higher protections intact, and check how the Layer 2 mechanisms can interact with the VLAN Ids you're using as delimiters 😭🚨
6.6. Network Access
every packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L2VPN 🌸
6.6.1. Physical/Link Layer Technology
L2VPN solutions SHOULD support a broad range of physical and link-layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, mobile radio access, etc. 📡 the capacity and QoS achievable MAY be dependent on the specific access technology in use 🫶
6.6.2. Access Connectivity
various types of physical connectivity scenarios MUST be supported, such as multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks 🕸️ in case of VPLS, IEEE 802.3ad-2000 link aggregation SHOULD be supported 🪢 L2VPN solutions SHOULD support at least the types of physical or link-layer connectivity arrangements shown in Figures 2 - 4 (in addition to the case shown in Figure 1). as in Figure 2, a CE can be dual-homed to an SP or to two different SPs via diverse access networks 🧩
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 2. Dual-Homed Access of CE DevicesResiliency of the L2VPN service can be further enhanced as shown in Figure 3, where CE's connected via a "back door" connection, connect to the same SP or to different SPs 💪✨
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 3. Backdoor Links Between CE DevicesArbitrary combinations of the above methods, with a few examples shown in Figure 4, SHOULD be supported by any L2VPN solution 🌈
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +-------------
|door \ | SP network |door \ +-------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 4. Combination of Dual-Homing and
Backdoor Links for CE Devices6.7. Customer Traffic 🦋
6.7.1. Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
okay bestie, the big rule here is that a VPLS MUST deliver every packet at least to its intended destination(s) within the scope of the VPLS 📬✨ and that's still true even when the ingress policing and security policies are doing their thing 🛡️💅. no packet gets ghosted 👻💖
6.7.2. Packet Re-ordering
so during normal operation, the queuing and forwarding policies SHOULD preserve packet order for packets with the same QoS parameters 🧃📦 it's giving "keep the line in order" energy, and it's honestly so iconic 👑🌸
6.7.3. Minimum MTU
a VPLS MUST support the theoretical MTU of the offered service 📏💅
the committed minimum MTU size MUST be the same for a given VPLS instance 🎀 but different L2VPN services MAY have different committed MTU sizes 🦋 and if the customer VLANs are used as service delimiters, all VLANs within a given VPLS MUST inherit the same MTU size 🫶 consistency is the vibe 💜
a VPLS MAY use IP fragmentation, as long as it presents reassembled packets at VPLS customer edge devices 🧩✨ the reassembly part is the whole point, so don't skip it 🙈
6.7.4. End-point VLAN Tag Translation
the L2VPN service MAY support translation of customers' AC identifiers (e.g., VLAN tags, if the customer VLANs are used as service delimiters) 🏷️🔁 this is super helpful for sites that want to keep their AC assignments, or sites that belong to different administrative domains 🌈 when it's the second case, people sometimes call it a Layer 2 extranet 🤝
BUT, and this is a big but 🚨, VLAN tag translation messes with multiple spanning trees (like 802.1s [IEEE_802.1s]) and can break the proper operation 💀 so it's worth keeping that in mind 🙈
6.7.5. Transparency
the L2VPN service is intended to be transparent to Layer 2 customer networks 🪞🦋 and an L2VPN solution SHOULD NOT require any special packet processing by the end users before sending packets to the provider's network 💅 nobody should have to do extra homework 📚🫠
if VLAN Ids are assigned by the SP, then VLANs are not transparent 🙅♀️ transparency doesn't apply in that case, because it works the same way as the FR/ATM service model 🧾
since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution MUST not alter the packets encapsulated inside Layer 2 frames that are transported by the IPLS ✨🔒 the encapsulated packets stay untouched, no notes 🙅♀️ but the IPLS solution is NOT REQUIRED to preserve the Layer 2 header transparently from CE to CE 🫣 so, for example, the Source MAC address might not be preserved by the IPLS solution 🪄 and the IPLS solution MAY remove Layer 2 headers for transport over the backbone when those can be reconstructed on egress without compromising transport of encapsulated traffic 🧚💖 it's like packing a bag and unpacking it later, as long as nothing inside gets damaged 🎒🌸
6.8. Support for Layer 2 Control Protocols
the L2VPN solution SHOULD allow transparent operation of Layer 2 control protocols employed by customers 🎀🫶
for VPLS, the L2VPN service MUST ensure that loops be prevented 🔁🚫 this can be done with a loop-free topology or appropriate forwarding rules 🗺️✨ control protocols like Spanning Tree (STP) or similar protocols could be used for this 🌳 and the L2VPN solution MAY use indications from customer Layer 2 control protocols, like STP BPDU snooping, to make a VPLS work even better 👀💜
6.9. CE Provisioning
the L2VPN solution MUST require only minimal or no configuration on the CE devices 🛠️🎀 exactly how much depends on what type of CE device is plugging into the infrastructure 🔌✨
7. Service Provider Network Requirements
this section is all about the requirements from an SP perspective 🏢💅
7.1. Scalability
this section has projections about L2VPN sizing and scalability requirements, plus metrics that are specific to particular solutions 📈🌸
7.1.1. Service Provider Capacity Sizing Projections
[RFC3809] lists projections regarding L2VPN sizing and scalability requirements and metrics 📋 the examples are also given in [RFC3809] 🙌
7.1.2. Solution-Specific Metrics
each L2VPN solution SHALL document its scalability characteristics in quantitative terms 🔢💖 no vibes-only numbers allowed 🙅♀️📊
7.2. Identifiers
an SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting an L2VPN that spans multiple SPs 🪪🌐 ideally, this identifier SHOULD be globally unique (e.g., an AS number) 🌍✨
each L2VPN's identifier SHOULD be unique, at least within each SP's network 🏷️ it MAY get used in auto-discovery, management (like alarm and service correlation, troubleshooting, and performance statistics collection), and signaling 📡 ideally the L2VPN identifier SHOULD be globally unique too, for the case where an L2VPN spans multiple SPs (e.g., [RFC2685]) 🌏💜 globally unique identifiers make inter-AS/SP L2VPNs so much easier to support 🫶
7.3. Discovering L2VPN Related Information
configuring PE devices (i.e., U-PE and N-PE [RFC4664]) is a seriously big task for an SP 😩📋 so solutions SHOULD provide methods that let PEs dynamically discover L2VPN information, to cut down on the configuration steps ✨🧠
each device in an L2VPN SHOULD be able to figure out which other devices belong to the same L2VPN 🕵️♀️ and that membership discovery scheme MUST prevent unauthorized access, and it allows authentication of the source 🔐💖
distribution of L2VPN information SHOULD be limited to the devices involved in that L2VPN 🤫 an L2VPN solution SHOULD also use discovery mechanisms to keep the amount of operational information the SPs have to maintain as small as possible 🧹 for example, if an SP adds or removes a customer port on a given PE, the remaining PEs SHOULD determine the necessary actions to take on their own, without the SP having to explicitly reconfigure them 🪄🌸
an L2VPN solution SHOULD support the means for attached CEs to authenticate each other and to verify that the SP L2VPN is correctly connected 🤝🔗
the mechanism SHOULD respond to L2VPN membership changes in a "timely manner" ⏰ a "timely manner" is no longer than the provisioning timeframe (typically minutes), and it MAY be as short as the timeframe needed for "rerouting" (typically seconds) ⚡💨
dynamically creating, changing, and managing multiple L2VPN assignments to sites and/or customers is another part of membership that MUST be addressed in an L2VPN solution 📋💅
7.4. Quality of Service (QoS)
QoS is a huge part of a provider-provisioned VPN 🎀⭐ an SP has control over provisioning resources and configuring parameters in at least the PE and P devices, and sometimes the CE devices too 🛠️ so the SP is to provide either managed QoS access service, or edge-to-edge QoS service, as defined in [RFC4031] 🏆✨
7.5. Isolation of Traffic and Forwarding Information
from a high-level SP perspective, an L2VPN MUST isolate the exchange of traffic and forwarding information so it only reaches sites that are authenticated and authorized members of that L2VPN 🔒🫶
an L2VPN solution SHOULD provide a means of meeting provider-provisioned VPN QoS SLS requirements that isolates L2VPN traffic from the affects of traffic offered by non-VPN customers 🛡️🌈 and L2VPN solutions SHOULD provide a means so that traffic congestion produced by sites in one L2VPN doesn't affect another L2VPN 🚦💖
7.6. Security
the security requirements are stated in Section 6.5 🔐👑 the security requirements provided in [RFC3809] SHOULD be met 🧾 and the security requirements specified in [RFC4031] SHOULD be met too, except for the Layer 3 and higher-layer dependent ones 🙌
🚨 an SP network MUST be protected against malformed or maliciously constructed customer traffic 🚨 this includes, but isn't limited to: duplicate or invalid Layer 2 addresses, customer side loops, short/long packets, spoofed management packets, spoofed VLAN tags, and high volume traffic 💀😭
the SP network devices MUST NOT be accessible from any L2VPN, unless specifically authorized 🚫🔐 and the devices in the SP network SHOULD provide some means of reporting intrusion attempts to the SP, if an intrusion is detected 🕵️♀️🚨
when an L2VPN solution operates over a part of the Internet, it should support a configurable option for one or more of the following standard IPsec methods to secure a customer's VPN traffic 🌐🔐
- Confidentiality, so that only authorized devices can decrypt it 🤫
- Integrity, to ensure that the data has not been altered 🧩
- Authentication, to ensure that the sender is indeed who he or she claims to be 🪪
- Replay attack prevention 🔁🚫
these functions SHOULD be applicable to the customer's "data traffic," which includes the traffic exchanged between sites 📦💜 it SHOULD also be possible to apply these functions to "control traffic," like routing or signaling protocol exchanges, which the customer might not even notice but are still essential for keeping their VPN alive 🧠🫀
furthermore, such security methods MUST be configurable between different end-points, such as PE-PE and PE-MTU, but only when L2VPN data traffic is carried over IP [RFC4023] 🎯 methods to secure data flows at the native service layer (Layer 2), from CE-CE, CE-MTU and CE-PE, are outside the scope of this document 🙅♀️ it's also desirable to configure security on a per-VPN basis 💅✨
a VPN solution MAY support one or more encryption schemes, including AES and 3DES 🔑 encryption, decryption, and key management SHOULD be included in profiles as part of the security management system 🧁🌸
7.7. Inter-AS/SP L2VPNs
all applicable SP requirements, like traffic and forwarding information isolation, SLSes, management, security, provisioning, and so on, MUST be preserved across adjacent ASes 🌉💖 the solution MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters 📝✨
an L2VPN solution MUST provide the specifics of offering L2VPN services that span multiple ASes and/or SPs 🌍🎀
an L2VPN solution MUST support proper dissemination of operational parameters to all elements of an L2VPN service when multiple ASes and/or SPs are involved 📣 and an L2VPN solution MUST employ mechanisms for sharing operational parameters between different ASes 🤝💜
an L2VPN solution SHOULD support policies for properly selecting operational parameters that come from different ASes 🧭 and similarly, an L2VPN solution SHOULD support policies for selecting the information that gets disseminated to different ASes 📡🌸
7.7.1. Management
the general requirements for managing a single AS apply to a concatenation of ASes too 🧩 a minimum subset of those capabilities is:
- Diagnostic tools 🩺
- Secured access to one AS management system by another 🔐
- Configuration request and status query tools 🛠️
- Fault notification and trouble tracking tools 🚨
7.7.2. Bandwidth and QoS Brokering
when an L2VPN spans multiple ASes, there's a need for a brokering mechanism that requests certain SLS parameters, like bandwidth and QoS, from the other domains and/or networks that are involved in carrying traffic to various sites 🤝💰 the essential requirement is that a solution MUST be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of a provider-provisioned VPN 🎯✨
7.8. L2VPN Wholesale
the architecture MUST support the possibility of one SP offering 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 their own customers 🧾🌈
7.9. Tunneling Requirements 🎀
okay so connectivity between CE sites or PE devices in the backbone SHOULD be able to use a whole range of tunneling techs, like L2TP, GRE, IP-in-IP, MPLS, etc. 🦋 variety is giving ✨
Every PE MUST support a tunnel setup protocol, if tunneling is used. 💅 no cap, that one's non-negotiable. A PE MAY support static configuration too 🌸 and if it's employed, a tunnel establishment protocol SHOULD be capable of conveying info like:
- 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 the VPN SP uses, plus its mechanisms for tunnel establishment, multiplexing, and maintenance, MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc. that's a lot of boxes to tick 🔥
Regardless of which tunneling choice you go with, the existence of the tunnels and their operations MUST be transparent to the customers 🫶 nobody should ever see the plumbing 🙈
7.10. Support for Access Technologies 💖
okay so the connection between a PE and a CE is called an AC 🔗 and ACs MAY span networks of other providers or public networks.
There are several choices for implementing ACs. Some popular ones include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual circuits etc. pick your fighter 🧚
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. ↔️ it goes both ways, bestie.
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. the provider is the boss of the tags 👑
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. ideal vs. reality, the eternal drama 🙄
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. 🧠 basically no one gets to hog the whole buffet 🍰
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. playing nice with everyone is literally the whole vibe 🤝
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. test everything, leak nothing 🔒
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. old gear gets a glow-up too ✨
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 SP wants to see everything, honestly iconic 👀
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. the nerdy backstage pass 🎟️
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. 🚧 nobody's gossip leaves the group chat 🤫
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. 📈 more people, more chatter, obviously
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. keep the group chat chill 🌿
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. 🙅♀️ no extra homework on top of the existing ones
9.2.2. Responsiveness to Congestion 🚦
An L2VPN solution SHOULD utilize the congestion avoidance techniques defined by PWE3 ([RFC3985]). 🚗💨 traffic jams, avoided
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. every group gets its own room 🏠
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. 📢 loud when it needs to be, obviously
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. 👀 the network just watches and learns
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. 🧩 every room learns its own stuff
10. Security Considerations 🔐
Security considerations occur at several levels and dimensions within L2VPNs, as detailed within this document. this section is the serious one, bestie 🚨
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. 🛡️
🚨 okay, dramatic pause: 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. 😭 no leaving the door unlocked!
11. Acknowledgements 💌
The authors would like to give a huge shout-out to the people who contributed extensive comments and contributions: 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 thank 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. the whole squad, iconic 🌈
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 📚
okay so this is the reading list bit, and these are the docs the spec leans on for context, not the ones it strictly needs. ngl the list is kinda long, but it's giving research-paper energy 💅
[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 🎀
the editors, aka the people who wrangled this whole thing together, and how to reach them 💌
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Yetik Serbest
AT&T Labs
9505 Arboretum Blvd.
Austin, TX 78759
EMail: yetik_serbest@labs.att.comFull Copyright Statement ⚖️
okay the legal bit, but make it cute 🫶
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 doesn't pick a side on whether any IP rights apply to the tech in here, or whether you can get a license for them. it also doesn't claim it went hunting for those rights itself. if you want the rules on rights in RFCs, check out BCP 78 and BCP 79 💅
IPR disclosures that were sent to the IETF Secretariat, plus any licensing assurances, or the outcome of trying to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🌈
Acknowledgement 🌸
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶
📦 where this page comes from
- ietf: rfc4665 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms