doc: Add RFC documents

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]
+