summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4026.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4026.txt')
-rw-r--r--doc/rfc/rfc4026.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4026.txt b/doc/rfc/rfc4026.txt
new file mode 100644
index 0000000..051da7a
--- /dev/null
+++ b/doc/rfc/rfc4026.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group L. Andersson
+Request for Comments: 4026 T. Madsen
+Category: Informational Acreo AB
+ March 2005
+
+
+ Provider Provisioned Virtual Private Network (VPN) Terminology
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ The widespread interest in provider-provisioned Virtual Private
+ Network (VPN) solutions lead to memos proposing different and
+ overlapping solutions. The IETF working groups (first Provider
+ Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have
+ discussed these proposals and documented specifications. This has
+ lead to the development of a partially new set of concepts used to
+ describe the set of VPN services.
+
+ To a certain extent, more than one term covers the same concept, and
+ sometimes the same term covers more than one concept. This document
+ seeks to make the terminology in the area clearer and more intuitive.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. PPVPN Terminology . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Provider Provisioned Virtual Private Network Services . . . . 4
+ 3.1. Layer 3 VPN (L3VPN) . . . . . . . . . . . . . . . . . . 4
+ 3.2. Layer 2 VPN (L2VPN) . . . . . . . . . . . . . . . . . . 4
+ 3.3. Virtual Private LAN Service (VPLS) . . . . . . . . . . . 4
+ 3.4. Virtual Private Wire Service (VPWS) . . . . . . . . . . 4
+ 3.5. IP-Only LAN-Like Service (IPLS) . . . . . . . . . . . . 5
+ 3.6. Pseudo Wire (PW) . . . . . . . . . . . . . . . . . . . . 5
+ 3.7. Transparent LAN Service (TLS) . . . . . . . . . . . . . 5
+ 3.8. Virtual LAN (VLAN) . . . . . . . . . . . . . . . . . . . 6
+ 3.9. Virtual Leased Line Service (VLLS) . . . . . . . . . . . 6
+ 3.10. Virtual Private Network (VPN) . . . . . . . . . . . . . 6
+ 3.11. Virtual Private Switched Network (VPSN) . . . . . . . . 6
+
+
+
+Andersson & Madsen Informational [Page 1]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ 4. Classification of VPNs . . . . . . . . . . . . . . . . . . . . 7
+ 5. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Customer Edge Device (CE) . . . . . . . . . . . . . . . 8
+ 5.1.1. Device Based CE Naming . . . . . . . . . . . . . 9
+ 5.1.2. Service Based CE Naming . . . . . . . . . . . . 9
+ 5.2. Provider Edge (PE) . . . . . . . . . . . . . . . . . . . 10
+ 5.2.1. Device Based PE Naming . . . . . . . . . . . . . 10
+ 5.2.2. Service Based PE Naming . . . . . . . . . . . . 10
+ 5.2.3. Distribution Based PE Naming . . . . . . . . . . 11
+ 5.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.3.1 Provider Router (P) . . . . . . . . . . . . . . 11
+ 5.4. Naming in Specific Internet Drafts . . . . . . . . . . . 11
+ 5.4.1. Layer 2 PE (L2PE) . . . . . . . . . . . . . . . 11
+ 5.4.2. Logical PE (LPE) . . . . . . . . . . . . . . . . 12
+ 5.4.3. PE-CLE . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.4. PE-Core . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.5. PE-Edge . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.6. PE-POP . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.7. VPLS Edge (VE) . . . . . . . . . . . . . . . . . 12
+ 6. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.1. Attachment Circuit (AC) . . . . . . . . . . . . . . . . 12
+ 6.2. Backdoor Links . . . . . . . . . . . . . . . . . . . . . 13
+ 6.3. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 13
+ 6.4. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.5. MAC Address Learning . . . . . . . . . . . . . . . . . . 13
+ 6.5.1. Qualified Learning . . . . . . . . . . . . . . . 13
+ 6.5.2. Unqualified Learning . . . . . . . . . . . . . . 13
+ 6.6. Signalling . . . . . . . . . . . . . . . . . . . . . . . 13
+ 7. 'Boxes' . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 7.1. Aggregation Box . . . . . . . . . . . . . . . . . . . . 14
+ 7.2. Customer Premises Equipment (CPE) . . . . . . . . . . . 14
+ 7.3. Multi-Tenant Unit (MTU) . . . . . . . . . . . . . . . . 14
+ 8. Packet Switched Network (PSN) . . . . . . . . . . . . . . . . 14
+ 8.1. Route Distinguisher (RD) . . . . . . . . . . . . . . . . 15
+ 8.2. Route Reflector . . . . . . . . . . . . . . . . . . . . 15
+ 8.3. Route Target (RT) . . . . . . . . . . . . . . . . . . . 15
+ 8.4. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.5. Tunnel Multiplexor . . . . . . . . . . . . . . . . . . . 16
+ 8.6. Virtual Channel (VC) . . . . . . . . . . . . . . . . . . 16
+ 8.7. VC Label . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.8. Inner Label . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.9. VPN Routing and Forwarding (VRF) . . . . . . . . . . . . 16
+ 8.10. VPN Forwarding Instance (VFI) . . . . . . . . . . . . . 16
+ 8.11. Virtual Switch Instance (VSI) . . . . . . . . . . . . . 17
+ 8.12. Virtual Router (VR) . . . . . . . . . . . . . . . . . . 17
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
+ 11. Informative References . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Andersson & Madsen Informational [Page 2]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
+
+1. Introduction
+
+ A comparatively large number of memos have been submitted to the
+ former PPVPN working group, and to the L2VPN, L3VPN, and PWE3 working
+ groups, which all address the same problem space; provider
+ provisioned virtual private networking for end customers. The memos
+ address a wide range of services, but there is also a great deal of
+ commonality among the proposed solutions.
+
+ This has led to the development of a partial set of new concepts used
+ to describe this set of VPN services. To a certain extent, more than
+ one term covers the same concept, and sometimes the same term covers
+ more than one concept.
+
+ This document proposes a foundation for a unified terminology for the
+ L2VPN and L3VPN working groups. In some cases, the parallel concepts
+ within the PWE3 working group are used as references.
+
+2. PPVPN Terminology
+
+ The concepts and terms in this list are gathered from Internet Drafts
+ sent to the L2VPN and L3VPN mailing lists (earlier the PPVPN mailing
+ list) and RFCs relevant to the L2VPN and L3VPN working groups. The
+ focus is on terminology and concepts that are specific to the PPVPN
+ area, but this is not strictly enforced; e.g., some concepts and
+ terms within the PWE3 and (Generalized) MPLS areas are closely
+ related. We've tried to find the earliest uses of terms and
+ concepts.
+
+ This document is intended to fully cover the concepts within the core
+ documents from the L2VPN and L3VPN working groups; i.e., [L3VPN-REQ],
+ [L2VPN-REQ], [L3VPN-FRAME], [L2VPN], and [RFC3809]. The intention is
+ to create a comprehensive and unified set of concepts for these
+ documents and, by extension, for the entire PPVPN area. To do so, it
+ is also necessary to give some of the development the concepts of the
+ area have been through.
+
+ The document is structured in four major sections. Section 4 lists
+ the different services that have been or will be specified Section 5
+ lists the building blocks that are used to specify those services
+ Section 6 lists the functions needed in those services. Section 7
+ lists some typical devices used in customer and provider networks.
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 3]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+3. Provider Provisioned Virtual Private Network Services
+
+ In this section, we define the terminology that relates the set of
+ services to solutions specified by the L2VPN and L3VPN working
+ groups. The "pseudo wire" concept, which belongs to the PWE3 working
+ group, is included for reference purposes. For requirements in
+ provider provisioned VPNs, see [L3VPN-REQ].
+
+ All terms and abbreviations are listed together with a brief
+ description of the service. The list is structured to give the more
+ general information first and the more specific later. The names of
+ services for which the IETF is working on solutions have been moved
+ to the top of the list. Older and more dated terminology has been
+ pushed toward the end of the list.
+
+3.1. Layer 3 VPN (L3VPN)
+
+ An L3VPN interconnects sets of hosts and routers based on Layer 3
+ addresses; see [L3VPN-FRAME].
+
+3.2. Layer 2 VPN (L2VPN)
+
+ Three types of L2VPNs are described in this document: Virtual Private
+ Wire Service (VPWS) (Section 3.4); Virtual Private LAN Service
+ (VPLS)(Section 3.3); and IP-only LAN-like Service
+ (IPLS)(Section 3.5).
+
+3.3. Virtual Private LAN Service (VPLS)
+
+ A VPLS is a provider service that emulates the full functionality of
+ a traditional Local Area Network (LAN). A VPLS makes it possible to
+ interconnect several LAN segments over a packet switched network
+ (PSN) and makes the remote LAN segments behave as one single LAN.
+ For an early work on defining a solution and protocol for a VPLS, see
+ [L2VPN-REQ], [VPLS-LDP], and [VPLS].
+
+ In a VPLS, the provider network emulates a learning bridge, and
+ forwarding decisions are taken based on MAC addresses or MAC
+ addresses and VLAN tag.
+
+3.4. Virtual Private Wire Service (VPWS)
+
+ A Virtual Private Wire Service (VPWS) is a point-to-point circuit
+ (link) connecting two Customer Edge devices. The link is established
+ as a logical through a packet switched network. The CE in the
+ customer network is connected to a PE in the provider network via an
+ Attachment Circuit (see Section 6.1); the Attachment Circuit is
+ either a physical or a logical circuit.
+
+
+
+Andersson & Madsen Informational [Page 4]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ The PEs in the core network are connected via a PW.
+
+ The CE devices can be routers, bridges, switches, or hosts. In some
+ implementations, a set of VPWSs is used to create a multi-site L2VPN
+ network. An example of a VPWS solution is described in
+ [PPVPN-L2VPN].
+
+ A VPWS differs from a VPLS (Section 3.3) in that the VPLS is point to
+ multipoint, while the VPWS is point to point. See [L2VPN].
+
+3.5. IP-Only LAN-Like Service (IPLS)
+
+ An IPLS is very like a VPLS (see Section 3.3), except that
+
+ o it is assumed that the CE devices (see Section 5.1) are hosts or
+ routers, not switches,
+ o it is assumed that the service will only have to carry IP packets,
+ and supporting packets such as ICMP and ARP (otherwise layer 2
+ packets that do not contain IP are not supported); and
+ o the assumption that only IP packets are carried by the service
+ applies equally to IPv4 and IPv6 packets.
+
+ While this service is a functional subset of the VPLS service, it is
+ considered separately because it may be possible to provide it by
+ using different mechanisms, which may allow it to run on certain
+ hardware platforms that cannot support the full VPLS functionality
+ [L2VPN].
+
+3.6. Pseudo Wire (PW)
+
+ The PWE3 working group within the IETF specifies the pseudo wire
+ technology. A pseudo wire is an emulated point-to-point connection
+ over a packet switched network that allows the interconnection of two
+ nodes with any L2 technology. The PW shares some of the building
+ blocks and architecture constructs with the point-to-multipoint
+ solutions; e.g., PE (see Section 5.2) and CE (see Section 5.1). An
+ early solution for PWs is described in [TRANS-MPLS]. Encapsulation
+ formats readily used in VPWS, VPLS, and PWs are described in
+ [ENCAP-MPLS]. Requirements for PWs are found in [RFC3916], and
+ [PWE3-ARCH] presents an architectural framework for PWs.
+
+3.7. Transparent LAN Service (TLS)
+
+ TLS was an early name used to describe the VPLS service. TLS has
+ been replaced by VPLS, which is the current term.
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 5]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+3.8. Virtual LAN (VLAN)
+
+ The term VLAN was specified by IEEE 802.1Q; it defines a method of
+ differentiating traffic on a LAN by tagging the Ethernet frames. By
+ extension, VLAN is used to mean the traffic separated by Ethernet
+ frame tagging or similar mechanisms.
+
+3.9. Virtual Leased Line Service (VLLS)
+
+ The term VLLS has been replaced by term VPWS. VLLS was used in a now
+ dated document intended to create metrics by which it should have
+ been possible to compare different L2VPN solutions. This document
+ has now expired, and the work has been terminated.
+
+3.10. Virtual Private Network (VPN)
+
+ VPN is a generic term that covers the use of public or private
+ networks to create groups of users that are separated from other
+ network users and that may communicate among them as if they were on
+ a private network. It is possible to enhance the level of separation
+ (e.g., by end-to-end encryption), but this is outside the scope of
+ IETF VPN working group charters. This VPN definition is from
+ [RFC2764].
+
+ In the [L3VPN-FRAME], the term VPN is used to refer to a specific set
+ of sites as either an intranet or an extranet that have been
+ configured to allow communication. Note that a site is a member of
+ at least one VPN and may be a member of many.
+
+ In this document, "VPN" is also used as a generic name for all
+ services listed in Section 3.
+
+3.11. Virtual Private Switched Network (VPSN)
+
+ The term VPSN has been replaced by the term VPLS. The requirements
+ have been merged into the L3VPN [L3VPN-REQ] and L2VPN [L2VPN-REQ]
+ requirements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 6]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+4. Classification of VPNs
+
+ The terminology used in [RFC3809] is defined based on the figure
+ below.
+
+
+ PPVPN
+ ________________|__________________
+ | |
+ Layer 2 Layer 3
+ ______|_____ ______|______
+ | | | |
+ P2P P2M PE-based CE-based
+ (VPWS) _____|____ ______|____ |
+ | | | | |
+ VPLS IPLS BGP/MPLS Virtual IPsec
+ IP VPNs Router
+
+ Figure 1
+
+ The figure above presents a taxonomy of PPVPN technologies. Some of
+ the definitions are given below:
+
+
+ CE-based VPN: A VPN approach in which the shared service provider
+ network does not have any knowledge of the customer VPN. This
+ information is limited to CE equipment. All the VPN-specific
+ procedures are performed in the CE devices, and the PE devices are
+ not aware in any way that some of the traffic they are processing is
+ VPN traffic (see also [L3VPN-FRAME]).
+
+ PE-Based VPNs: A Layer 3 VPN approach in which a service provider
+ network is used to interconnect customer sites using shared
+ resources. Specifically, the PE device maintains VPN state,
+ isolating users of one VPN from users of another. Because the PE
+ device maintains all required VPN states, the CE device may behave as
+ if it were connected to a private network. Specifically, the CE in a
+ PE-based VPN must not require any changes or additional functionality
+ to be connected to a PPVPN instead of a private network.
+
+ The PE devices know that certain traffic is VPN traffic. They
+ forward the traffic (through tunnels) based on the destination IP
+ address of the packet, and optionally based on other information in
+ the IP header of the packet. The PE devices are themselves the
+ tunnel endpoints. The tunnels may make use of various encapsulations
+ to send traffic over the SP network (such as, but not restricted to,
+ GRE, IP-in-IP, IPsec, or MPLS tunnels) [L3VPN-FRAME].
+
+
+
+
+Andersson & Madsen Informational [Page 7]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ Virtual Router (VR) style: A PE-based VPN approach in which the PE
+ router maintains a complete logical router for each VPN that it
+ supports. Each logical router maintains a unique forwarding table
+ and executes a unique instance of the routing protocols. These VPNs
+ are described in [L3VPN-VR].
+
+ BGP/MPLS IP VPNs: A PE-based VPN approach in which the PE router
+ maintains a separate forwarding environment and a separate forwarding
+ table for each VPN. In order to maintain multiple forwarding table
+ instances while running only a single BGP instance, BGP/MPLS IP VPNs
+ mark route advertisements with attributes that identify their VPN
+ context. These VPNs are based on the approach described in
+ [RFC2547bis].
+
+ RFC 2547 Style: The term has been used by the L3VPN to describe the
+ extensions of the VPNs defined in the informational RFC 2547
+ [RFC2547]. This term has now been replaced by the term BGP/MPLS IP
+ VPNs.
+
+5. Building Blocks
+
+ Starting with specifications of L3VPNs (e.g., the 2547 specification
+ [RFC2547] and [RFC2547bis] and Virtual Routers [L3VPN-VR]), a way of
+ describing the building blocks and allocation of functions in VPN
+ solutions was developed. The building blocks are often used in
+ day-to-day talk as if they were physical boxes, common for all
+ services.
+
+ However, for different reasons, this is an oversimplification. Any
+ of the building blocks could be implemented across more than one
+ physical box. How common the use of such implementations will be is
+ beyond the scope of this document.
+
+5.1. Customer Edge Device (CE)
+
+ A CE is the name of the device with the functionality needed on the
+ customer premises to access the services specified by the former
+ PPVPN working group in relation to the work done on L3VPNs
+ [L3VPN-FRAME]. The concept has been modified; e.g., when L2VPNs and
+ CE-based VPNs were defined. This is addressed further in the
+ sub-sections of this section.
+
+ There are two different aspects that have to be considered in naming
+ CE devices. One could start with the type of device that is used to
+ implement the CE (see Section 5.1.1). It is also possible to use the
+ service the CE provides whereby the result will be a set of "prefixed
+ CEs", (see Section 5.1.2).
+
+
+
+
+Andersson & Madsen Informational [Page 8]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ It is common practice to use "CE" to indicate any of these boxes, as
+ it is very often unambiguous in the specific context.
+
+5.1.1. Device Based CE Naming
+
+5.1.1.1. Customer Edge Router (CE-R)
+
+ A CE-R is a router in the customer network interfacing the provider
+ network. There are many reasons to use a router in the customer
+ network; e.g., in an L3VPN using private IP addressing, this is the
+ router that is able to do forwarding based on the private addresses.
+ Another reason to require the use of a CE-R on the customer side is
+ that one wants to limit the number of MAC-addresses that need to be
+ learned in the provider network.
+
+ A CE-R could be used to access both L2 and L3 services.
+
+5.1.1.2. Customer Edge Switch (CE-S)
+
+ A CE-S is a service aware L2 switch in the customer network
+ interfacing the provider network. In a VPWS or a VPLS, it is not
+ strictly necessary to use a router in the customer network; a layer 2
+ switch might very well do the job.
+
+5.1.2. Service Based CE Naming
+
+ The list below contains examples of how different functionality has
+ been used to name CEs. There are many examples of this type of
+ naming, and we only cover the most frequently used functional names.
+ As these are functional names, it is quite possible that on a single
+ piece of equipment there are platforms for more than one type of
+ function. For example, a router might at the same time be both a
+ L2VPN-CE and a L3VPN-CE. It might also be that the functions needed
+ for a L2VPN-CE or L3VPN-CE are distributed over more than one
+ platform.
+
+5.1.2.1. L3VPN-CE
+
+ An L3VPN-CE is the device or set of devices on the customer premises
+ that attaches to a provider provisioned L3VPN; e.g., a 2547bis
+ implementation.
+
+5.1.2.2. VPLS-CE
+
+ A VPLS-CE is the device or set of devices on the customer premises
+ that attaches to a provider provisioned VPLS.
+
+
+
+
+
+Andersson & Madsen Informational [Page 9]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+5.1.2.3. VPWS-CE
+
+ A VPWS-CE is the device or set of devices on the customer premises
+ that attaches to a provider provisioned VPWS.
+
+5.2. Provider Edge (PE)
+
+ A PE is the name of the device or set of devices at the edge of the
+ provider network with the functionality that is needed to interface
+ with the customer. Without further qualifications, PE is very often
+ used for naming the devices since it is made unambiguous by the
+ context.
+
+ In naming PEs there are three aspects that we need to consider, the
+ service they support, whether the functionality needed for service is
+ distributed across more than one device and the type of device they
+ are build on.
+
+5.2.1. Device Based PE Naming
+
+ Both routers and switches may be used to implement PEs; however, the
+ scaling properties will be radically different depending on which
+ type of equipment is chosen.
+
+5.2.1.1. Provider Edge Router (PE-R)
+
+ A PE-R is a L3 device that participates in the PSN (see Section 8)
+ routing and forwards packets based on the routing information.
+
+5.2.1.2. Provider Edge Switch (PE-S)
+
+ A PE-S is a L2 device that participates in for example a switched
+ Ethernet taking forwarding decision packets based on L2 address
+ information.
+
+5.2.2. Service Based PE Naming
+
+5.2.2.1. L3VPN-PE
+
+ An L3VPN-PE is a device or set of devices at the edge of the provider
+ network interfacing the customer network, with the functionality
+ needed for an L3VPN.
+
+5.2.2.2. VPWS-PE
+
+ A VPWS-PE is a device or set of devices at the edge of the provider
+ network interfacing the customer network, with the functionality
+ needed for a VPWS.
+
+
+
+Andersson & Madsen Informational [Page 10]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+5.2.2.3. VPLS-PE
+
+ A VPLS-PE is a device or set of devices at the edge of the provider
+ network interfacing the customer network, with the functionality
+ needed for a VPLS.
+
+5.2.3. Distribution Based PE Naming
+
+ For scaling reasons, in the VPLS/VPWS cases sometimes it is desired
+ to distribute the functions in the VPLS/VPWS-PE across more than one
+ device. For example, is it feasible to allocate MAC address learning
+ on a comparatively small and inexpensive device close to the customer
+ site, while participation in the PSN signalling and setup of PE to PE
+ tunnels are done by routers closer to the network core.
+
+ When distributing functionality across devices, a protocol is needed
+ to exchange information between the Network facing PE (N-PE) (see
+ Section 5.2.3.1) and the User facing PE (U-PE) (see Section 5.2.3.2).
+
+5.2.3.1. Network Facing PE (N-PE)
+
+ The N-PE is the device to which the signalling and control functions
+ are allocated when a VPLS-PE is distributed across more than one box.
+
+5.2.3.2. User Facing PE (U-PE)
+
+ The U-PE is the device to which the functions needed to take
+ forwarding or switching decisions at the ingress of the provider
+ network.
+
+5.3. Core
+
+5.3.1. Provider Router (P)
+
+ The P is defined as a router in the core network that does not have
+ interfaces directly toward a customer. Therefore, a P router does
+ not need to keep VPN state and is VPN unaware.
+
+5.4. Naming in Specific Internet Drafts
+
+5.4.1. Layer 2 PE (L2PE)
+
+ L2PE is the joint name of the devices in the provider network that
+ implement L2 functions needed for a VPLS or a VPWS.
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 11]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+5.4.2. Logical PE (LPE)
+
+ The term Logical PE (LPE) originates from a dated Internet Draft,
+ "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE
+ Architecture", and was used to describe a set of devices used in a
+ provider network to implement a VPLS. In a LPE, VPLS functions are
+ distributed across small devices (PE-Edges/U-PE) and devices attached
+ to a network core (PE-Core/N-PE). In an LPE solution, the PE-edge
+ and PE-Core can be interconnected by a switched Ethernet transport
+ network or uplinks. The LPE will appear to the core network as a
+ single PE. In this document, the devices that constitutes, the LPE
+ are called N-PE and U-PE.
+
+5.4.3. PE-CLE
+
+ An alternative name for the U-PE suggested in the expired Internet
+ Draft, "VPLS architectures".
+
+5.4.4. PE-Core
+
+ See the origins and use of this concept in Section 5.4.2.
+
+5.4.5. PE-Edge
+
+ See the origins and use of this concept in Section 5.4.2.
+
+5.4.6. PE-POP
+
+ An alternative name for the U-PE suggested in the expired Internet
+ Draft, "VPLS architectures".
+
+5.4.7. VPLS Edge (VE)
+
+ The term VE originates from a dated Internet Draft on a distributed
+ transparent LAN service and was used to describe the device used by a
+ provider network to hand off a VPLS to a customer. In this document,
+ the VE is called a VPLS-PE. This name is dated.
+
+6. Functions
+
+ In this section, we have grouped a number of concepts and terms that
+ have to be performed to make the VPN services work.
+
+6.1. Attachment Circuit (AC)
+
+ In a Layer 2 VPN the CE is attached to PE via an Attachment Circuit
+ (AC). The AC may be a physical or logical link.
+
+
+
+
+Andersson & Madsen Informational [Page 12]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+6.2. Backdoor Links
+
+ Backdoor Links are links between CE devices that are provided by the
+ end customer rather than by the SP; they may be used to interconnect
+ CE devices in multiple-homing arrangements [L3VPN-FRAME].
+
+6.3. Endpoint Discovery
+
+ Endpoint discovery is the process by which the devices that are aware
+ of a specific VPN service will find all customer facing ports that
+ belong to the same service.
+
+ The requirements on endpoint discovery and signalling are discussed
+ in [L3VPN-REQ]. It was also the topic in a now dated Internet Draft
+ reporting from a design team activity on VPN discovery.
+
+6.4. Flooding
+
+ Flooding is a function related to L2 services; when a PE receives a
+ frame with an unknown destination MAC address, that frame is send out
+ over (flooded) every other interface.
+
+6.5. MAC Address Learning
+
+ MAC address learning is a function related to L2 services; when PE
+ receives a frame with an unknown source MAC address, the relationship
+ between that MAC-address and interface is learned for future
+ forwarding purposes. In a layer 2 VPN solution from the L2VPN WG,
+ this function is allocated to the VPLS-PE.
+
+6.5.1. Qualified Learning
+
+ In qualified learning, the learning decisions at the U-PE are based
+ on the customer Ethernet frame's MAC address and VLAN tag, if a VLAN
+ tag exists. If no VLAN tag exists, the default VLAN is assumed.
+
+6.5.2. Unqualified Learning
+
+ In unqualified learning, learning is based on a customer Ethernet
+ frame's MAC address only.
+
+6.6. Signalling
+
+ Signalling is the process by which the PEs that have VPNs behind them
+ exchange information to set up PWs, PSN tunnels, and tunnel
+ multiplexers. This process might be automated through a protocol or
+ done by manual configuration. Different protocols may be used to
+ establish the PSN tunnels and exchange the tunnel multiplexers.
+
+
+
+Andersson & Madsen Informational [Page 13]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+7. 'Boxes'
+
+ We list a set of boxes that will typically be used in an environment
+ that supports different kinds of VPN services. We have chosen to
+ include some names of boxes that originate outside the protocol
+ specifying organisations.
+
+7.1. Aggregation Box
+
+ The aggregation box is typically an L2 switch that is service unaware
+ and is used only to aggregate traffic to more function rich points in
+ the network.
+
+7.2. Customer Premises Equipment (CPE)
+
+ The CPE equipment is the box that a provider places with the
+ customer. It serves two purposes: giving the customer ports to plug
+ in to and making it possible for a provider to monitor the
+ connectivity to the customer site. The CPE is typically a low cost
+ box with limited functionality and, in most cases, is not aware of
+ the VPN services offered by the provider network. The CPE equipment
+ is not necessarily the equipment to which the CE functions are
+ allocated, but it is part of the provider network and is used for
+ monitoring purposes.
+
+ The CPE name is used primarily in network operation and deployment
+ contexts and should not be used in protocol specifications.
+
+7.3. Multi-Tenant Unit (MTU)
+
+ An MTU is typically an L2 switch placed by a service provider in a
+ building where several customers of that service provider are
+ located. The term was introduced in an Internet Draft specifying a
+ VPLS solution with function distributed between the MTU and the PE in
+ the context of a [VPLS].
+
+ The MTU device name is used primarily in network operation and
+ deployment contexts and should not be used in protocol
+ specifications, as it is also an abbreviation used for Maximum
+ Transmit Units.
+
+8. Packet Switched Network (PSN)
+
+ A PSN is the network through which the tunnels supporting the VPN
+ services are set up.
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 14]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+8.1. Route Distinguisher (RD)
+
+ A Route Distinguisher [RFC2547bis] is an 8-byte value that, together
+ with a 4 byte IPv4 address, identifies a VPN-IPv4 address family. If
+ two VPNs use the same IPv4 address prefix, the PEs translate these
+ into unique VPN-IPv4 address prefixes. This ensures that if the same
+ address is used in two different VPNs, it is possible to install two
+ completely different routes to that address, one for each VPN.
+
+8.2. Route Reflector
+
+ A route reflector is a network element owned by a Service Provider
+ (SP) that is used to distribute BGP routes to the SP's BGP-enabled
+ routers [L3VPN-FRAME].
+
+8.3. Route Target (RT)
+
+ A Route Target attribute [RFC2547bis] can be thought of as
+ identifying a set of sites or, more precisely, a set of VRFs (see
+ Section 8.9).
+
+ Associating a particular Route Target with a route allows that route
+ to be placed in all VRFs used for routing traffic received from the
+ corresponding sites.
+
+ A Route Target attribute is also a BGP extended community used in
+ [RFC2547] and [BGP-VPN]. A Route Target community is used to
+ constrain VPN information distribution to the set of VRFs. A route
+ target can be perceived as identifying a set of sites or, more
+ precisely, a set of VRFs.
+
+8.4. Tunnel
+
+ A tunnel is connectivity through a PSN that is used to send traffic
+ across the network from one PE to another. The tunnel provides a
+ means to transport packets from one PE to another. Separation of one
+ customer's traffic from another customer's traffic is done based on
+ tunnel multiplexers (see Section 8.5). How the tunnel is established
+ depends on the tunnelling mechanisms provided by the PSN; e.g., the
+ tunnel could be based on the IP-header, an MPLS label, the L2TP
+ Session ID, or the GRE Key field.
+
+
+
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 15]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+8.5. Tunnel Multiplexor
+
+ A tunnel multiplexor is an entity that is sent with the packets
+ traversing the tunnel to make it possible to decide which instance of
+ a service a packet belongs to and from which sender it was received.
+ In [PPVPN-L2VPN], the tunnel multiplexor is formatted as an MPLS
+ label.
+
+8.6. Virtual Channel (VC)
+
+ A VC is transported within a tunnel and identified by its tunnel
+ multiplexer. A virtual channel is identified by a VCI (Virtual
+ Channel Identifier). In the PPVPN context, a VCI is a VC label or
+ tunnel multiplexer, and in the Martini case, it is equal to the VCID.
+
+8.7. VC Label
+
+ In an MPLS-enabled IP network, a VC label is an MPLS label used to
+ identify traffic within a tunnel that belongs to a particular VPN;
+ i.e., the VC label is the tunnel multiplexer in networks that use
+ MPLS labels.
+
+8.8. Inner Label
+
+ "Inner label" is another name for VC label (see Section 8.6).
+
+8.9. VPN Routing and Forwarding (VRF)
+
+ In networks running 2547 VPN's [RFC2547], PE routers maintain VRFs.
+ A VRF is a per-site forwarding table. Every site to which the PE
+ router is attached is associated with one of these tables. A
+ particular packet's IP destination address is looked up in a
+ particular VRF only if that packet has arrived directly from a site
+ that is associated with that table.
+
+8.10. VPN Forwarding Instance (VFI)
+
+ VPN Forwarding Instance (VFI) is a logical entity that resides in a
+ PE that includes the router information base and forwarding
+ information base for a VPN instance [L3VPN-FRAME].
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 16]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+8.11. Virtual Switch Instance (VSI)
+
+ In a layer 2 context, a VSI is a virtual switching instance that
+ serves one single VPLS [L2VPN]. A VSI performs standard LAN (i.e.,
+ Ethernet) bridging functions. Forwarding done by a VSI is based on
+ MAC addresses and VLAN tags, and possibly on other relevant
+ information on a per VPLS basis. The VSI is allocated to VPLS-PE or,
+ in the distributed case, to the U-PE.
+
+8.12. Virtual Router (VR)
+
+ A Virtual Router (VR) is software and hardware based emulation of a
+ physical router. Virtual routers have independent IP routing and
+ forwarding tables, and they are isolated from each other; see
+ [L3VPN-VR].
+
+9. Security Considerations
+
+ This is a terminology document and as such doesn't have direct
+ security implications. Security considerations will be specific to
+ solutions, frameworks, and specification documents whose terminology
+ is collected and discussed in this document.
+
+10. Acknowledgements
+
+ Much of the content in this document is based on discussion in the
+ PPVPN design teams for "auto discovery" and "l2vpn".
+
+ Dave McDysan, Adrian Farrel, and Thomas Narten have carefully
+ reviewed the document and given many useful suggestions.
+
+ Thomas Narten converted an almost final version of this document into
+ XML, after extracting an acceptable version from Word became too
+ painful. Avri Doria has been very helpful in guiding us in the use
+ of XML.
+
+11. Informative References
+
+ [L2VPN] Andersson, L. and E. Rosen, "Framework for Layer 2
+ Virtual Private Networks (L2VPNs)", Work in Progress,
+ June 2004.
+
+ [L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for
+ Layer 2 Provider Provisioned Virtual Private
+ Networks", Work in Progress, October 2004.
+
+ [VPLS] Kompella, K., "Virtual Private LAN Service", Work in
+ Progress, January 2005.
+
+
+
+Andersson & Madsen Informational [Page 17]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ [VPLS-LDP] Lasserre, M. and V. Kompella, "Virtual Private LAN
+ Services over MPLS", Work in Progress, September 2004.
+
+ [BGP-VPN] Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP
+ as an Auto-Discovery Mechanism for Layer-3 and Layer-2
+ VPNs", Work in Progress, May 2004.
+
+ [L3VPN-FRAME] Callon, R. and M. Suzuki, "A Framework for Layer 3
+ Provider Provisioned Virtual Private Networks", Work in
+ Progress, July 2003.
+
+ [RFC3809] Nagarajan, A., "Generic Requirements for Provider
+ Provisioned Virtual Private Networks (PPVPN)", RFC
+ 3809, June 2004.
+
+ [L3VPN-REQ] Carugi, M. and D. McDysan, "Service requirements for
+ Layer 3 Virtual Private Networks", Work in Progress,
+ July 2004.
+
+ [RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", Work in Progress,
+ October 2004.
+
+ [L3VPN-VR] Knight, P., Ould-Brahim, H. and B. Gleeson, "Network
+ based IP VPN Architecture using Virtual Routers", Work
+ in Progress, April 2004.
+
+ [PWE3-ARCH] Bryant, S. and P. Pate, "PWE3 Architecture", Work in
+ Progress, March 2004.
+
+ [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
+ Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
+ September 2004.
+
+ [PPVPN-L2VPN] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in
+ Progress, June 2002.
+
+ [ENCAP-MPLS] Martini, L., "Encapsulation Methods for Transport of
+ Layer 2 Frames Over IP and MPLS Networks", Work in
+ Progress, September 2004.
+
+ [TRANS-MPLS] Martini, L. and N. El-Aawar, "Transport of Layer 2
+ Frames Over MPLS", Work in Progress, June 2004.
+
+ [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
+ March 1999.
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 18]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+ [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
+ A. Malis, "A Framework for IP Based Virtual Private
+ Networks", RFC 2764, February 2000.
+
+Authors' Addresses
+
+ Loa Anderson
+ Acreo AB
+
+ EMail: loa@pi.se
+
+
+ Tove Madsen
+ Acreo AB
+
+ EMail: tove.madsen@acreo.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 19]
+
+RFC 4026 Provider Provisioned VPN Terminology March 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Andersson & Madsen Informational [Page 20]
+