idnits 2.17.1 draft-ietf-l3vpn-ppvpn-terminology-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 928. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 13) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2004) is 7161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-01 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-02 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-04 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-04 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-vpn-vr-02 == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-02 == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-07 == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-14 -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Andersson 2 Internet-Draft T. Madsen 3 Expires: March 11, 2005 Acreo AB 4 September 10, 2004 6 Provider Provisioned VPN terminology 7 draft-ietf-l3vpn-ppvpn-terminology-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 11, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The wide spread interest in provider-provisioned VPN solutions lead 43 to memos proposing different and overlapping solutions. The IETF 44 working groups, first Provider Provisioned VPNs and later Layer 2 45 VPNs and Layer 3 VPNs, have been discussed these proposals and 46 documented specifications. This has lead to the development of a 47 partly new set of concepts used to describe the set of VPN services. 48 To a certain extent there is more than one term covering the same 49 concept and sometimes the same term covers more than one concept. 50 This document seeks to fill the need to make the terminology in the 51 area clearer and more intuitive. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. PPVPN Terminology . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Provider Provisioned Virtual Private Network services . . . . 6 58 3.1 Layer 3 VPN (L3VPN) . . . . . . . . . . . . . . . . . . . 6 59 3.2 Layer 2 VPN (L2VPN) . . . . . . . . . . . . . . . . . . . 6 60 3.3 Virtual Private LAN Service (VPLS) . . . . . . . . . . . . 6 61 3.4 Virtual Private Wire Service (VPWS) . . . . . . . . . . . 6 62 3.5 IP-only LAN-like Service (IPLS) . . . . . . . . . . . . . 7 63 3.6 Pseudo Wire (PW) . . . . . . . . . . . . . . . . . . . . . 7 64 3.7 Transparent LAN Service (TLS) . . . . . . . . . . . . . . 8 65 3.8 Virtual LAN (VLAN) . . . . . . . . . . . . . . . . . . . . 8 66 3.9 Virtual Leased Line Service (VLLS) . . . . . . . . . . . . 8 67 3.10 Virtual Private Network (VPN) . . . . . . . . . . . . . . 8 68 3.11 Virtual Private Switched Network (VPSN) . . . . . . . . . 8 69 4. Classification of VPNs . . . . . . . . . . . . . . . . . . . . 9 70 5. Building blocks . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1 Customer Edge device (CE) . . . . . . . . . . . . . . . . 11 72 5.1.1 Device based CE naming . . . . . . . . . . . . . . . . 11 73 5.1.2 Service based CE naming . . . . . . . . . . . . . . . 12 74 5.2 Provider Edge (PE) . . . . . . . . . . . . . . . . . . . . 12 75 5.2.1 Device based PE naming . . . . . . . . . . . . . . . . 13 76 5.2.2 Service based PE naming . . . . . . . . . . . . . . . 13 77 5.2.3 Distribution based PE naming . . . . . . . . . . . . . 13 78 5.3 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.3.1 Provider router (P) . . . . . . . . . . . . . . . . . 14 80 5.4 Naming in specific Internet drafts . . . . . . . . . . . . 14 81 5.4.1 Layer 2 PE (L2PE) . . . . . . . . . . . . . . . . . . 14 82 5.4.2 Logical PE (LPE) . . . . . . . . . . . . . . . . . . . 14 83 5.4.3 PE-CLE . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.4.4 PE-Core . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.4.5 PE-Edge . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.4.6 PE-POP . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.4.7 VPLS Edge (VE) . . . . . . . . . . . . . . . . . . . . 15 88 6. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 6.1 Attachment Circuit (AC) . . . . . . . . . . . . . . . . . 16 90 6.2 Backdoor Links . . . . . . . . . . . . . . . . . . . . . . 16 91 6.3 Endpoint discovery . . . . . . . . . . . . . . . . . . . . 16 92 6.4 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 6.5 MAC address learning . . . . . . . . . . . . . . . . . . . 16 94 6.5.1 Qualified learning . . . . . . . . . . . . . . . . . . 16 95 6.5.2 Unqualified learning . . . . . . . . . . . . . . . . . 17 96 6.6 Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 98 7. 'Boxes' . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 7.1 Aggregation box . . . . . . . . . . . . . . . . . . . . . 18 100 7.2 Customer Premises Equipment (CPE) . . . . . . . . . . . . 18 101 7.3 Multi Tenant Unit (MTU) . . . . . . . . . . . . . . . . . 18 102 8. Packet Switched Network (PSN) . . . . . . . . . . . . . . . . 19 103 8.1 Route Distinguisher (RD) . . . . . . . . . . . . . . . . . 19 104 8.2 Route Reflector . . . . . . . . . . . . . . . . . . . . . 19 105 8.3 Route Target (RT) . . . . . . . . . . . . . . . . . . . . 19 106 8.4 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 8.5 Tunnel multiplexor . . . . . . . . . . . . . . . . . . . . 20 108 8.6 Virtual Channel (VC) . . . . . . . . . . . . . . . . . . . 20 109 8.7 VC label . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 8.8 Inner label . . . . . . . . . . . . . . . . . . . . . . . 20 111 8.9 VPN Routing and Forwarding (VRF) . . . . . . . . . . . . . 20 112 8.10 VPN Forwarding Instance (VFI) . . . . . . . . . . . . . . 20 113 8.11 Virtual Switch Instance (VSI) . . . . . . . . . . . . . . 20 114 8.12 Virtual Router (VR) . . . . . . . . . . . . . . . . . . . 21 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 117 11. Informative References . . . . . . . . . . . . . . . . . . . 23 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 119 Intellectual Property and Copyright Statements . . . . . . . . 26 121 1. Introduction 123 A comparatively large number of memos has been submitted to the 124 former PPVPN working group, and to the L2VPN, L3VPN and PWE3 working 125 groups that all address the same problem space, provider provisioned 126 virtual private networking for end customers. The memos address a 127 wide range of services, but there is also a great deal of commonality 128 among the proposed solutions. 130 This has lead to the development of a partly new set of concepts used 131 to describe this set of VPN services. To a certain extent there is 132 more than one term covering the same concept and sometimes the same 133 term covers more than one concept. 135 This document seeks to fill at least part of the need and proposes a 136 foundation for a unified terminology for the L2VPN, L3VPN working 137 groups; in some cases the parallel concepts within the PWE3 working 138 group are used as references. 140 2. PPVPN Terminology 142 The concepts and terms in this list are gathered from Internet Drafts 143 sent to the L2VPN and L3VPN mailing lists (earlier PPVPN mailing 144 list) and RFCs relevant to the L2VPN and L3VPN working groups. The 145 focus is on terminology and concepts that are specific to the PPVPN 146 area, but this is not strictly enforced, e.g. there are concepts and 147 terms within the PWE3 and (Generalized) MPLS areas that are closely 148 related. We've tried to find the earliest use of terms and concepts. 150 This document intends to fully cover the concepts within the core 151 documents from the L2VPN and L3VPN working groups, i.e. 152 [I-D.ietf-l3vpn-requirements] , [I-D.ietf-l2vpn-requirements], 153 [I-D.ietf-l3vpn-framework], [I-D.ietf-l2vpn-l2-framework], and 154 [I-D.ietf-l3vpn-generic-reqts]. The intention is to create a 155 comprehensive and unified set of concepts for these documents, and by 156 extension for the entire PPVPN area. To do so it is also necessary 157 to give some of the development the concepts of the area have been 158 through. 160 The document is structured in four major sections. Section 4 lists 161 the different services that have been or will be specified, Section 5 162 lists the building blocks that are used to specify those services, 163 Section 6 lists the functions needed in those services and Section 7 164 list some typical devices used in customer and provider networks. 166 3. Provider Provisioned Virtual Private Network services 168 In this section we define the terminology that relates the set of 169 services to solutions specified by the L2VPN and L3VPN working 170 groups. The concept "pseudo wire" that belongs to the PWE3 working 171 group is included for reference purposes. For requirements in 172 provider provisioned VPNs see [I-D.ietf-l3vpn-requirements]. 174 In this section all abbreviations are listed together with short 175 information on tyhe service. The list is structured to give the more 176 general information first and more specific later. The names of 177 services for which IETF are working on solution for have as far as 178 feasible been moved to the top of the list. Older and dated 179 terminology has been pushed towrd the en of the list. 181 3.1 Layer 3 VPN (L3VPN) 183 An L3VPN interconnects sets of hosts and routers based on Layer 3 184 addresses, see [I-D.ietf-l3vpn-framework]. 186 3.2 Layer 2 VPN (L2VPN) 188 Three types of L2VPNs are described in this document, Virtual Private 189 Wire Service (VPWS) (Section 3.4), Virtual Private LAN Service 190 (VPLS)( Section 3.3), and IP-only LAN-like Service (IPLS)(Section 191 3.5). 193 3.3 Virtual Private LAN Service (VPLS) 195 A VPLS is a provider service that emulates the full functionality of 196 a traditional Local Area Network. A VPLS makes it possible to 197 interconnect several LAN segments over a packet switched network 198 (PSN) and makes the remote LAN segments behave as one single LAN. 199 For an early work on defining a solution and protocol for a VPLS see 200 [I-D.ietf-l2vpn-requirements], [I-D.ietf-l2vpn-vpls-ldp], and 201 [I-D.ietf-l2vpn-vpls-bgp]. 203 In a VPLS, the provider network emulates a learning bridge and 204 forwarding decisions are taken based on MAC addresses or MAC 205 addresses and VLAN tag. 207 3.4 Virtual Private Wire Service (VPWS) 209 A Virtual Private Wire Service (VPWS) is a point-to-point circuit 210 (link) connecting two Customer Edge devices. The link is established 211 as a logical through a packet switched Network. The CE in the 212 customer network is connected to a PE in the provider network via an 213 Attachment Circuit (see Section 6.1); the Attachment Circuit is 214 either a physical or a logical circuit. 216 The PE's in the core network are connected via a PW. 218 The CE devices can be routers, bridges, switches or hosts. In some 219 implementations a set of VPWSs is used to create a multi-site L2VPN 220 network. An example of a VPWS solution is described in 221 [I-D.kompella-ppvpn-l2vpn]. 223 A VPWS differs from a VPLS (Section 3.3) in that the VPLS is point to 224 multipoint, while the VPWS is point to point. See 225 [I-D.ietf-l2vpn-l2-framework]. 227 3.5 IP-only LAN-like Service (IPLS) 229 An IPLS is very like a VPLS (see Section 3.3), except that: 231 o it is assumed that the CE devices (see Section 5.1) are hosts or 232 routers, not switches 233 o it is assumed that the service will only need to carry IP packets, 234 and supporting packets such as ICMP and ARP; otherwise layer 2 235 packets which do not contain IP are not supported. 236 o the assumption that only IP packets is carried by the service 237 applies equally to IPv4 and IPv6 packets. 239 While this service is a functional subset of the VPLS service, it is 240 considered separately because it may be possible to provide it using 241 different mechanisms, which may allow it to run on certain hardware 242 platforms that cannot support the full VPLS functionality 243 [I-D.ietf-l2vpn-l2-framework]. 245 3.6 Pseudo Wire (PW) 247 The PWE3 working group within the IETF specifies the pseudo wire 248 technology. A pseudo wire is an emulated point-to-point connection 249 over a packet switched network that gives the possibility to 250 interconnect two nodes with any L2 technology. The PW shares some of 251 the building blocks and architecture constructs with the point- 252 to-multipoint solutions, e.g. PE (see Section 5.2) and CE (see 253 Section 5.1). An early solution for PWs is described in 254 [I-D.martini-l2circuit-trans-mpls]. Encapsulation formats readily 255 used in VPWS, VPLS and PWs are described in 256 [I-D.martini-l2circuit-encap-mpls]. Requirements for PWs are found 257 in [I-D.ietf-pwe3-requirements] and [I-D.ietf-pwe3-arch] presents an 258 architectural framework for PWs. 260 3.7 Transparent LAN Service (TLS) 262 TLS was an early name used to describe the VPLS service, it was used 263 e.g., in the now dated draft-lasserre-tls-mpls-00.txt. This draft 264 has been merged into the working group VPLS solution using LDP as a 265 signalling protocol. The term TLS has been replaced by VPLS, which 266 is the current term. 268 3.8 Virtual LAN (VLAN) 270 The term VLAN was specified by IEEE 802.1Q; it defines a method to 271 differentiate traffic on a LAN by tagging the Ethernet frames. By 272 extension, VLAN is used to mean the traffic separated by Ethernet 273 frame tagging or similar mechanisms. 275 3.9 Virtual Leased Line Service (VLLS) 277 The term VLLS has been replaced by term VPWS. VLLS was used in now 278 dated document intended to create metrics by which it should have 279 been possible to compare different L2VPN solutions. This document 280 has now expired and the work terminated. 282 3.10 Virtual Private Network (VPN) 284 VPN is a generic term that covers the use of public or private 285 networks to create groups of users that are separated from other 286 network users and may communicate among them as if they were on a 287 private network. It is possible to enhance the level of separation 288 e.g. by end-to-end encryption, this is however outside the scope of 289 IETF VPN working group charters. This VPN definition is from 290 [RFC2764]. 292 In the [I-D.ietf-l3vpn-framework] the term VPN is used to refer to a 293 specific set of sites as either an intranet or an extranet that have 294 been configured to allow communication. Note that a site is a member 295 of at least one VPN, and may be a member of many VPNs. 297 In this document "VPN" is also used as a generic name for all 298 services listed in Section 3. 300 3.11 Virtual Private Switched Network (VPSN) 302 The term VPSN has been replaced by the term VPLS. The VPSN 303 abbreviation was used e.g. in the now dated draft-vkompella-ppvpn- 304 vpsn-reqmts-00.txt. The requirements has been merged into the L3VPN 305 [I-D.ietf-l3vpn-requirements] and L2VPN [I-D.ietf-l2vpn-requirements] 306 requirements. 308 4. Classification of VPNs 310 The terminology used in [I-D.ietf-l3vpn-generic-reqts] is defined 311 based on the figure below. 313 PPVPN 314 ________________|__________________ 315 | | 316 Layer 2 Layer 3 317 ______|_____ ______|______ 318 | | | | 319 P2P P2M PE-based CE-based 320 (VPWS) _____|____ ______|____ | 321 | | | | | 322 VPLS IPLS BGP/MPLS Virtual IPsec 323 IP VPNs Router 325 The figure above presents a taxonomy of PPVPN technologies. Some of 326 the definitions are given below: 328 Figure 1 330 CE-based VPN: A VPN approach in which the shared service provider 331 network does not have any knowledge of the customer VPN. This 332 information is limited to CE equipment. All the VPN-specific 333 procedures are performed in the CE devices, and the PE devices are 334 not aware in any way that some of the traffic they are processing is 335 VPN traffic (see also [I-D.ietf-l3vpn-framework]). 337 PE-Based VPNs: A Layer 3 VPN approach in which a service provider 338 network is used to interconnect customer sites using shared 339 resources. Specifically the PE device maintains VPN state, isolating 340 users of one VPN from users of another VPN. Because the PE device 341 maintains all required VPN state, the CE device may behave as if it 342 were connected to a private network. Specifically, the CE in a 343 PE-based VPN must not require any changes or additional functionality 344 to be connected to a PPVPN instead of a private network. 346 The PE devices know that certain traffic is VPN traffic. They 347 forward the traffic (through tunnels) based on the destination IP 348 address of the packet, and optionally based on other information in 349 the IP header of the packet. The PE devices are themselves the 350 tunnel endpoints. The tunnels may make use of various encapsulations 351 to send traffic over the SP network (such as, but not restricted to, 352 GRE, IP-in-IP, IPsec, or MPLS tunnels) [I-D.ietf-l3vpn-framework]. 354 Virtual Router (VR) style: A PE-based VPN approach in which the PE 355 router maintains a complete logical router for each VPN that it 356 supports. Each logical router maintains a unique forwarding table 357 and executes a unique instance of the routing protocols. These VPNs 358 are described in [I-D.ietf-l3vpn-vpn-vr]. 360 BGP/MPLS IP VPNs: A PE-based VPN approach in which the PE router 361 maintains separate forwarding environment for each VPN and a separate 362 forwarding table for each VPN. In order to maintain multiple 363 forwarding table instances while running only a single BGP instance, 364 BGP/MPLS IP VPNs mark route advertisements with attributes that 365 identify their VPN context. These VPNs are based on the approach 366 described in [I-D.ietf-l3vpn-rfc2547bis]. 368 RFC 2547 Style: The term has been used by the L3VPN to describe the 369 extensions of the VPNs defined in the informational RFC2547. This 370 term has now been replaced by the term BGP/MPLS IP VPNs. 372 5. Building blocks 374 Starting with specifications of L3VPNs, e.g. the 2547 specification 375 [RFC2547] and [I-D.ietf-l3vpn-rfc2547bis] and Virtual Routers 376 [I-D.ietf-l3vpn-vpn-vr], a way of describing the building blocks and 377 allocation of functions in VPN solutions was developed. The building 378 blocks are often used in day-to-day talk as if it were physical 379 boxes, common for all services. 381 However, for different reasons this is an over-simplification. Any 382 of the building blocks could be implemented across more than one 383 physical box. How common the use of such implementations will be is 384 beyond the scope of this document. 386 5.1 Customer Edge device (CE) 388 A CE is the name of the device with the functionality needed on the 389 customer premises to access the services specified by the former 390 PPVPN working group in relation to the work done on L3VPNs 391 [I-D.ietf-l3vpn-framework]. The concept has been modified e.g. when 392 L2VPNs and CE-based VPNs were defined, this is addressed further in 393 the sub- sections of this section. 395 There are two different aspects that need to be considered in naming 396 CE devices. One could start with the type of device that is used to 397 implement the CE (see Section 5.1.1). It is also possible to use the 398 service the CE provides and with the result it will be a set of 399 "prefixed CEs", (see Section 5.1.2). 401 It is common practice to use "CE" to indicate any of these boxes, 402 since it is very often unambiguous in the specific context. 404 5.1.1 Device based CE naming 406 5.1.1.1 Customer Edge Router (CE-R) 408 A CE-R is a router in the customer network interfacing the provider 409 network. There are many reasons to use a router in the customer 410 network, e.g. in an L3VPN using private IP addressing this is the 411 router that is able to do forwarding based on the private addresses. 412 Another reason to require the use of a CE-R on the customer side is 413 that one want to limit the number on MAC- addresses that needs to be 414 learned in the provider network. 416 A CE-R could be used to access both L2 and L3 services. 418 5.1.1.2 Customer Edge Switch (CE-S) 420 A CE-S is a service aware L2 switch in the customer network 421 interfacing the provider network. In a VPWS or a VPLS it is not 422 strictly necessary to use a router in the customer network, a layer 2 423 switch might very well do the job. 425 5.1.2 Service based CE naming 427 The list below contains examples of how different functionality has 428 been used to name CE's. There are many expamples of this type of 429 naming and we have not had the ambition to cover every possible 430 example, but only cover the most frequently used functional names. 431 As this is functional names it is quite possible that on single piece 432 of equipment are the platform for more than one type of function, 433 e.g. a router might at the same time be both a L2VPN-CE and a 434 L3VPN-CE. It might also be that the functions that is need to for a 435 L2VPN-CE or L3VPN-CE is distributed over more than one platform. 437 5.1.2.1 L3VPN-CE 439 An L3VPN-CE is the device or set of devices on the customer premises 440 that attaches to a provider provisioned L3VPN, e.g. a 2547bis 441 implementation. 443 5.1.2.2 VPLS-CE 445 A VPLS-CE is the device or set of devices on the customer premises 446 that attaches to a provider provisioned VPLS. 448 5.1.2.3 VPWS-CE 450 A VPWS-CE is the device or set of devices on the customer premises 451 that attaches to a provider provisioned VPWS. 453 5.2 Provider Edge (PE) 455 A PE is the name of the device or set of devices at the edge of the 456 provider network with the functionality that is needed to interface 457 the customer. PE, without further qualifications, is very often used 458 for naming the devices since it is made unambiguous by the context. 460 In naming PEs there are three aspects that we need to consider, the 461 service they support, whether the functionality needed for service is 462 distributed across more than one device and the type of device they 463 are build on. 465 5.2.1 Device based PE naming 467 Both routers and switches may be used to implement PEs, however the 468 scaling properties will be radically different depending which type 469 of equipment is chosen. 471 5.2.1.1 Provider Edge Router (PE-R) 473 A PE-R is a L3 device that participates in the PSN (see Section 8) 474 routing and forwards packets based on the routing information. 476 5.2.1.2 Provider Edge Switch (PE-S) 478 A PE-S is a L2 device that participates in e.g. a switched Ethernet 479 taking forwarding decision packets based on L2 address information. 481 5.2.2 Service based PE naming 483 5.2.2.1 L3VPN-PE 485 An L3VPN-PE is a device or set of devices at the edge of the provider 486 network interfacing the customer network, with the functionality 487 needed for an L3VPN. 489 5.2.2.2 VPWS-PE 491 A VPWS-PE is a device or set of devices at the edge of the provider 492 network interfacing the customer network, with the functionality 493 needed for a VPWS. 495 5.2.2.3 VPLS-PE 497 A VPLS-PE is a device or set of devices at the edge of the provider 498 network interfacing the customer network, with the functionality 499 needed for a VPLS. 501 5.2.3 Distribution based PE naming 503 For scaling reasons it is in the VPLS/VPWS cases sometimes desired to 504 distribute the functions in the VPLS/VPWS-PE across more than one 505 device, e.g. is it feasible to allocate MAC address learning on a 506 comparatively small and in-expensive device close to the customer 507 site, while participation in the PSN signalling and set up of PE to 508 PE tunnels are done by routers closer to the network core. 510 When distributing functionality across devices a protocol is needed 511 to exchange information between the Network facing PE (N-PE) see 512 Section 5.2.3.1 and the User facing PE (U-PE) see Section 5.2.3.2. 514 5.2.3.1 Network facing PE (N-PE) 516 The N-PE is the device to which the signalling and control functions 517 are allocated when a VPLS-PE is distributed across more than one box. 519 5.2.3.2 User facing PE (U-PE) 521 The U-PE is the device to which the functions needed to take 522 forwarding or switching decision at the ingress of the provider 523 network. 525 5.3 Core 527 5.3.1 Provider router (P) 529 The P is defined as a router in the core network that does not have 530 interfaces directly towards a customer. Hence a P router does not 531 need to keep VPN state and is VPN un-aware. 533 5.4 Naming in specific Internet drafts 535 5.4.1 Layer 2 PE (L2PE) 537 L2PE is the joint name of the devices in the provider network that 538 implement L2 functions needed for a VPLS or a VPWS. 540 5.4.2 Logical PE (LPE) 542 The term Logical PE (LPE) originates from a dated Internet Draft 543 "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE 544 Architecture" and was used to describe a set of devices used in a 545 provider network to implement a VPLS. In a LPE, VPLS functions are 546 distributed across small devices (PE-Edges/U-PE) and devices attached 547 to a network core (PE-Core/N-PE). In an LPE solution the PE-edge and 548 PE-Core can be interconnected by a switched Ethernet transport 549 network(s) or uplinks. The LPE will appear to the core network as a 550 single PE. In this document the devices that constitutes the LPE is 551 called N-PE and U-PE. 553 5.4.3 PE-CLE 555 An alternative name for the U-PE suggested in the now expired 556 Internet Draft "VPLS architectures". 558 5.4.4 PE-Core 560 See the origins and use of this concept in Section 5.4.2. 562 5.4.5 PE-Edge 564 See the origins and use of this concept in Section 5.4.2. 566 5.4.6 PE-POP 568 An alternative name for the U-PE suggested in now the expired 569 Internet Draft "VPLS architectures". 571 5.4.7 VPLS Edge (VE) 573 The term VE originates from a dated Internet Draft on a distributed 574 transparent LAN service and was used to describe the device used by a 575 provider network to hand off a VPLS to a customer. In this document 576 the VE is called a VPLS-PE. This name has dated. 578 6. Functions 580 In this section we have grouped a number of concepts and terms that 581 have to be performed to make the VPN services work. 583 6.1 Attachment Circuit (AC) 585 In a Layer 2 VPN the CE is attached to PE via an Attachment Circuit 586 (AC). The AC may be a physical or logical link. 588 6.2 Backdoor Links 590 Backdoor Links are links between CE devices that are provided by the 591 end customer rather than the SP; may be used to interconnect CE 592 devices in multiple-homing arrangements [I-D.ietf-l3vpn-framework]. 594 6.3 Endpoint discovery 596 Endpoint discovery is the process by which the devices that are aware 597 of a specific VPN service will find all customer facing ports that 598 belong to the same service. 600 The requirements on endpoint discovery and signalling are discussed 601 in [I-D.ietf-l3vpn-requirements]. It was also the topic in a now 602 dated Internet Draft reporting from a design team activity on VPN 603 discovery. 605 6.4 Flooding 607 Flooding is a function related to L2 services; when a PE receives a 608 frame with an unknown destination MAC-address, that frame is send out 609 over (flooded) every other interface. 611 6.5 MAC address learning 613 MAC address learning is a function related to L2 services; when PE 614 receives a frame with an unknown source MAC-address the relationship 615 between that MAC-address and interface is learnt for future 616 forwarding purposes. In a layer 2 VPN solution from the L2VPN WG, 617 this function is allocated to the VPLS-PE. 619 6.5.1 Qualified learning 621 In qualified learning, the learning decisions at the U-PE are based 622 on the customer Ethernet frame's MAC address and VLAN tag, if a VLAN 623 tag exists. If no VLAN tag exists, the default VLAN is assumed. 625 6.5.2 Unqualified learning 627 In unqualified learning, learning is based on a customer Ethernet 628 frame's MAC address only. 630 6.6 Signalling 632 Signalling is the process by which the PEs that have VPNs behind them 633 exchange information to set up PWs, PSN tunnels and tunnel 634 multiplexers. This process might be automated through a protocol or 635 done by manual configuration. Different protocols may be used to 636 establish the PSN tunnels and exchange the tunnel multiplexers. 638 7. 'Boxes' 640 We list a set of boxes that will typically be used in an environment 641 that supports different kinds of VPN services. We have chosen to 642 include some names of boxes that originate outside the protocol 643 specifying organisations. 645 7.1 Aggregation box 647 The aggregation box is typically an L2 switch that is service unaware 648 and is used only to aggregate traffic to more function rich points in 649 the network. 651 7.2 Customer Premises Equipment (CPE) 653 The CPE equipment is the box that a provider places with the 654 customer. It serves two purposes, giving the customer ports to plug 655 in to and making it possible for a provider to monitor the 656 connectivity to the customer site. The CPE is typically a low cost 657 box with limited functionality and in most cases not aware of the 659 VPN services offered by the provider network. The CPE equipment is 660 not necessarily the equipment to which the CE functions are 661 allocated, but is part of the provider network and used for 662 monitoring purposes. 664 The CPE name is used primarily in network operation and deployment 665 contexts, and should not be used in protocol specifications. 667 7.3 Multi Tenant Unit (MTU) 669 An MTU is typically an L2 switch placed by a service provider in a 670 building where several customers of that service provider are 671 located. The term wwere introduced in an Internet Draft specifying a 672 VPLS solution with function distributed between the MTU and the PE in 673 the contect of a [I-D.ietf-l2vpn-vpls-bgp]. 675 The MTU device name is used primarily in network operation and 676 deployment contexts, and should not be used in protocol 677 specifications, as it is also a used abbreviation for Maximum 678 Transmit Units. 680 8. Packet Switched Network (PSN) 682 A PSN is the network through which the tunnels supporting the VPN 683 services are set up. 685 8.1 Route Distinguisher (RD) 687 A Route Distinguisher [I-D.ietf-l3vpn-rfc2547bis] is an 8-byte value 688 that together with a 4 byte IPv4 address identifies a VPN-IPv4 689 address family. If two VPNs use the same IPv4 address prefix, the 690 PEs translate these into unique VPN-IPv4 address prefixes. This 691 ensures that if the same address is used in two different VPNs, it is 692 possible to install two completely different routes to that address, 693 one for each VPN. 695 8.2 Route Reflector 697 A route reflector is a network element owned by a Service Provider 698 (SP) that is used to distribute BGP routes to the SP's BGP-enabled 699 routers [I-D.ietf-l3vpn-framework]. 701 8.3 Route Target (RT) 703 A Route Target attribute [I-D.ietf-l3vpn-rfc2547bis] can be thought 704 of as identifying a set of sites, or more precisely a set of VRFs 705 (see Section 8.9). 707 Associating a particular Route Target with a route, allows that route 708 to be placed in all VRFs that are used for routing traffic received 709 from the corresponding sites. 711 A Route Target attribute is also a BGP extended community used in 712 [RFC2547], and [I-D.ietf-l3vpn-bgpvpn-auto]. A Route Target 713 community is used to constrain VPN information distribution to the 714 set of VRFs. A route target can be perceived as identifying a set of 715 sites, or more precisely a set of VRFs. 717 8.4 Tunnel 719 A tunnel is connectivity through a PSN that is used to send traffic 720 across the network from one PE to another. The tunnel provides a 721 mechanism to transport packets from one PE to another, separation of 722 one customer's traffic from another customer's traffic is done based 723 on tunnel multiplexers (see Section 8.5). How the tunnel is 724 established depends on the tunnelling mechanisms provided by the PSN, 725 i.e. the tunnel could be based on e.g. the IP-header, an MPLS 726 label, the L2TP Session ID, or on the GRE Key field. 728 8.5 Tunnel multiplexor 730 A tunnel multiplexor is an entity that is sent with the packets 731 traversing the tunnel to make it possible to decide to which instance 732 of a service a packet belongs and from which sender it was received. 733 In [I-D.kompella-ppvpn-l2vpn] the tunnel multiplexor is formatted as 734 an MPLS label. 736 8.6 Virtual Channel (VC) 738 A VC is transported within a tunnel and identified by its tunnel 739 multiplexer. A virtual channel is identified by a VCI (Virtual 740 Channel Identifier). In the PPVPN context a VCI is a VC label or 741 tunnel multiplexer and in the Martini case it is equal to the VCID. 743 8.7 VC label 745 In an MPLS-enabled IP network a VC label is an MPLS label, used to 746 identify traffic within a tunnel that belongs to a particular VPN, 747 i.e. the VC label is the tunnel multiplexer in networks that use 748 MPLS labels. 750 8.8 Inner label 752 "Inner label" is another name for VC label (see Section 8.6). 754 8.9 VPN Routing and Forwarding (VRF) 756 In networks running 2547 VPN's [RFC2547], PE routers maintain VRF's. 757 A VRF is a per-site forwarding table. Every site to which the PE 758 router is attached is associated with one of these tables. A 759 particular packet's IP destination address is looked up in a 760 particular VRF only if that packet has arrived directly from a site, 761 which is associated with that table. 763 8.10 VPN Forwarding Instance (VFI) 765 VPN Forwarding Instance (VFI) is a logical entity that resides in a 766 PE that includes the router information base and forwarding 767 information base for a VPN instance [I-D.ietf-l3vpn-framework]. 769 8.11 Virtual Switch Instance (VSI) 771 In a layer 2 context a VSI is a virtual switching instance that 772 serves one single VPLS [I-D.ietf-l2vpn-l2-framework]. A VSI performs 773 standard LAN (i.e., Ethernet) bridging functions. Forwarding done by 774 a VSI is based on MAC addresses and VLAN tags, and possibly other 775 relevant information on a per VPLS basis. The VSI is allocated to 776 VPLS-PE or in the distributed case to the U-PE. 778 8.12 Virtual Router (VR) 780 A Virtual Router (VR) is software and hardware based emulation of a 781 physical router. Virtual routers have independent IP routing and 782 forwarding tables and they are isolated from each other, see 783 [I-D.ietf-l3vpn-vpn-vr]. 785 9. Security Considerations 787 This is a terminology document and as such doesn't have direct 788 security implications. Security considerations will be specific to 789 the solutions, framework and specification documents whose 790 terminology is collected and discussed in this document. 792 10. Acknowledgements 794 Much of the content in this document is based on discussion in the 795 PPVPN design teams for "auto discovery" and "l2vpn". 797 Dave McDysan, Adrian Farrel and Thomas Narten have carefully reviewed 798 the document and given many useful suggestions. 800 Thomas Narten converted an almost final version of this document into 801 XML, after extracting an acceptable version out of Word became to 802 painful. Avri Doria has been very helpful in guiding is in the use 803 of XML. 805 11 Informative References 807 [I-D.ietf-l2vpn-l2-framework] 808 Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 809 Private Networks (L2VPNs)", 810 draft-ietf-l2vpn-l2-framework-05 (work in progress), June 811 2004. 813 [I-D.ietf-l2vpn-requirements] 814 Augustyn, W. and Y. Serbest, "Service Requirements for 815 Layer 2 Provider Provisioned Virtual Private Networks", 816 draft-ietf-l2vpn-requirements-01 (work in progress), 817 February 2004. 819 [I-D.ietf-l2vpn-vpls-bgp] 820 Kompella, K., "Virtual Private LAN Service", 821 draft-ietf-l2vpn-vpls-bgp-02 (work in progress), May 2004. 823 [I-D.ietf-l2vpn-vpls-ldp] 824 Lasserre, M. and V. Kompella, "Virtual Private LAN 825 Services over MPLS", draft-ietf-l2vpn-vpls-ldp-04 (work in 826 progress), August 2004. 828 [I-D.ietf-l3vpn-bgpvpn-auto] 829 Ould-Brahim, H., Rosen, E. and Y. Rekhter, "Using BGP as 830 an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", 831 draft-ietf-l3vpn-bgpvpn-auto-04 (work in progress), May 832 2004. 834 [I-D.ietf-l3vpn-framework] 835 Callon, R. and M. Suzuki, "A Framework for Layer 3 836 Provider Provisioned Virtual Private Networks", 837 draft-ietf-l3vpn-framework-00 (work in progress), July 838 2003. 840 [I-D.ietf-l3vpn-generic-reqts] 841 Nagarajan, A., "Generic Requirements for Provider 842 Provisioned Virtual Private Networks", 843 draft-ietf-l3vpn-generic-reqts-03 (work in progress), 844 February 2004. 846 [I-D.ietf-l3vpn-requirements] 847 Carugi, M. and D. McDysan, "Service requirements for Layer 848 3 Virtual Private Networks", 849 draft-ietf-l3vpn-requirements-02 (work in progress), July 850 2004. 852 [I-D.ietf-l3vpn-rfc2547bis] 853 Rosen, E., "BGP/MPLS IP VPNs", 854 draft-ietf-l3vpn-rfc2547bis-01 (work in progress), 855 September 2003. 857 [I-D.ietf-l3vpn-vpn-vr] 858 Knight, P., Ould-Brahim, H. and B. Gleeson, "Network based 859 IP VPN Architecture using Virtual Routers", 860 draft-ietf-l3vpn-vpn-vr-02 (work in progress), April 2004. 862 [I-D.ietf-pwe3-arch] 863 Bryant, S. and P. Pate, "PWE3 Architecture", 864 draft-ietf-pwe3-arch-07 (work in progress), March 2004. 866 [I-D.ietf-pwe3-requirements] 867 Xiao, X., "Requirements for Pseudo-Wire Emulation 868 Edge-to-Edge (PWE3)", draft-ietf-pwe3-requirements-08 869 (work in progress), January 2004. 871 [I-D.kompella-ppvpn-l2vpn] 872 Kompella, K., "Layer 2 VPNs Over Tunnels", 873 draft-kompella-ppvpn-l2vpn-02 (work in progress), June 874 2002. 876 [I-D.martini-l2circuit-encap-mpls] 877 Martini, L., "Encapsulation Methods for Transport of Layer 878 2 Frames Over IP and MPLS Networks", 879 draft-martini-l2circuit-encap-mpls-07 (work in progress), 880 June 2004. 882 [I-D.martini-l2circuit-trans-mpls] 883 Martini, L. and N. El-Aawar, "Transport of Layer 2 Frames 884 Over MPLS", draft-martini-l2circuit-trans-mpls-14 (work in 885 progress), June 2004. 887 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 888 1999. 890 [RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G. and A. 891 Malis, "A Framework for IP Based Virtual Private 892 Networks", RFC 2764, February 2000. 894 Authors' Addresses 896 Loa Anderson 897 Acreo AB 899 EMail: loa@pi.se 901 Tove Madsen 902 Acreo AB 904 EMail: tove.madsen@acreo.se 906 Intellectual Property Statement 908 The IETF takes no position regarding the validity or scope of any 909 Intellectual Property Rights or other rights that might be claimed to 910 pertain to the implementation or use of the technology described in 911 this document or the extent to which any license under such rights 912 might or might not be available; nor does it represent that it has 913 made any independent effort to identify any such rights. Information 914 on the procedures with respect to rights in RFC documents can be 915 found in BCP 78 and BCP 79. 917 Copies of IPR disclosures made to the IETF Secretariat and any 918 assurances of licenses to be made available, or the result of an 919 attempt made to obtain a general license or permission for the use of 920 such proprietary rights by implementers or users of this 921 specification can be obtained from the IETF on-line IPR repository at 922 http://www.ietf.org/ipr. 924 The IETF invites any interested party to bring to its attention any 925 copyrights, patents or patent applications, or other proprietary 926 rights that may cover technology that may be required to implement 927 this standard. Please address the information to the IETF at 928 ietf-ipr@ietf.org. 930 Disclaimer of Validity 932 This document and the information contained herein are provided on an 933 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 934 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 935 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 936 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 937 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 938 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 940 Copyright Statement 942 Copyright (C) The Internet Society (2004). This document is subject 943 to the rights, licenses and restrictions contained in BCP 78, and 944 except as set forth therein, the authors retain all their rights. 946 Acknowledgment 948 Funding for the RFC Editor function is currently provided by the 949 Internet Society.