PPVPN WG Vasile Radoaca Internet Draft: Dinesh Mohan draft-radoaca-ppvpn-gvpls-01.txt Nortel Networks Expiration Date: April 2003 Ananth Nagarajan Sprint Javier Achirica Telefonica Data Pascal Menezez Terabeam Andrew Malis Vivace Networks Marty Borden Yaron Raz Yael Dayan Simon Hunt Atrica 186k Alain Vedrenne Muneyoshi Suzuki Equant NTT Corporation Shah Himanshu Tenor Networks October 2002 GVPLS/LPE - Generic VPLS Solution based on LPE Framework 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Radoaca, et. al Expires: April 2003 [Page 1] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 2. Abstract This document describes virtual private LAN service (VPLS) solution over MPLS, called Generic VPLS/LPE (GVPLS) that emulates a partial bridging functionality [802.1D] to connect customers LANs/VLANs across the Metro and WAN Service Provider networks. This functionality includes the MAC learning and forwarding to emulate connectivity between the customer LANs/VLANs. This is a partial bridging functionality since it is transparent to customer topology and STP protocol. For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW] introduces two types of models: distributed and non-distributed. While [VPLS] solution presents a non-distributed model, it is recognized that both models may need to co-exist in the same SP network. This implies a need of a unified provisioning model with signalling mechanisms to support these new classes of solutions. The MAC learning process and the scalability in terms of number of VPLSs and number of customer ports can be increased significantly if some optimisations are provided in the Control and Data plane. The current draft presents the GVPLS solution that extend the [VPLS] solution and addresses such issues. In addition an improvement model for Mulitpoint to Point PW (M2P) is presented. The term "Generic" in this document is used to reflect the unified aspect of the two models. 3. Conventions Used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Placement of this Memo in Sub-IP Area RELATED DOCUMENTS http://search.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap.txt http://search.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol.txt http://search.ietf.org/internet-drafts/draft-augustyn-ppvpn-vpls- reqmts-00.txt http://search.ietf.org/internet-drafts/draft-lasserre-vkompella- ppvpn-vpls-04.txt http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-l2- framework-02.txt http://search.ietf.org/internet-drafts/draft-rosen-ppvpn-l2- signaling-02.txt Radoaca, et. al Expires: August 2003 [Page 2] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN WHY IS IT TARGETTED AT THIS WG The charter of the PPVPN WG includes L2 VPN services and this draft specifies a model for Ethernet L2 VPN services over MPLS. JUSTIFICATION Existing Internet drafts specify how to provide point-to-point Ethernet L2 VPN services over MPLS. This draft defines how multipoint Ethernet services can be provided using distributed and non-distributed models, allows some optimization and scalability requirements to be satisfied. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................2 3. Conventions Used................................................2 4. Introduction....................................................4 4.1 Overview.......................................................4 4.2 Attributes of the distributed model............................5 4.3 Functional components..........................................6 4.4 GVPLS Topological model 5. Information model...............................................7 5.1 VPN-ID.........................................................7 5.2 Device Ids.....................................................7 5.3 SP address scheme..............................................7 5.4 Information model Entities.....................................8 5.5 SP Address scheme mapping to the VPLS core....................10 5.6 N-PE's VSI and FIBs...........................................10 6. Control Plane .................................................11 6.1 Provisioning and Auto-discovery...............................11 6.2 Auto-discovery ...............................................12 6.3 Signaling.....................................................13 6.3.1 Access control sessions and LDP Sessions....................13 6.3.2 VC-Label semantic...........................................14 6.3.3 BGP Signaling...............................................14 7. Data Plane.....................................................17 7.4.1 Access Encapsulation........................................17 7.4.1.1 MAC-in-MAC Encapsulation..................................17 7.4.1.2 Q-in-Q Encapsulation......................................17 7.4.1.3 Martini type encapsulation................................17 Radoaca, et. al Expires: August 2003 [Page 3] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 7.4.2 VPLS Core Encapsulation.....................................18 7.4.3 Forwarding..................................................18 7.4.4 Replication and flooding....................................19 7.4.5 OAM Mechanism...............................................19 7.5 Considerations regarding M2P and Control Word.................19 8. Deployment Scenarios...........................................20 8.1 Interoperability between GVPLS and VPLS solutions.............20 9. VPLS Resiliency................................................20 10. Security Considerations.......................................21 11. Compliance with the PPVN Requirements.........................21 12. References....................................................21 13.1 Normative References.........................................21 13.2 Informative References.......................................21 14. Acknowledgments...............................................22 15. Intellectual Property Considerations..........................22 14. Authors' Addresses............................................22 15. Full Copyright Statement.....................................24 4. Introduction This document describes virtual private LAN service (VPLS) solution over MPLS, called Generic VPLS/LPE (GVPLS) that emulates a partial bridging functionality to connect customers LANs/VLANs across the Metro and WAN Service Provider networks. This functionality includes the MAC learning and forwarding to emulate connectivity between the customer LANs/VLANs. This is a partial bridging functionality since it is transparent to customer topology and STP. 4.1 Overview Following [LPE] and [L2-FRW], regardless of the signalling and auto- discovery protocols, two paradigms can be identified for the VPLS solutions: - Non-distributed model - the MAC learning/forwarding and VPLS forwarding is done in a PE device - Distributed model - the VPLS functionality and MAC learning/forwarding is distributed in the U-PE devices, and the VPLS forwarding in the N-PE devices. [VPLS] describes a non-distributed solution where the VPLS functionality is concentrated in the PE device. The solution is enhanced with a hierarchical model (called HVPLS), between U-PE and N-PE devices, which allows scaling the number of Pseudo-Wires in Metro core. The U-PE and N-PE devices are connected via P2P Pseudo-Wires or Ethernet access networks, and both devices would perform customers MAC learning and forwarding. Radoaca, et. al Expires: August 2003 [Page 4] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 Following the Reference Model for VPLS in [L2-FRW], and [LPE] the GVPLS solution extends and complements the non-distributed model [VPLS] in order to support the distributed model. In this respect, GVPLS extends the [VPLS] model in two key areas: access network and core network. The access network is extended with a new type of U-PE device that is capable to perform the VPLS service, with or without the N-PE devices. Therefore, such devices would perform MAC learning and forwarding to other U-PE devices and may perform auto-discovery and signalling of the VPN membership. In order to enable and scale such model, besides PWs [PWE3-CTRL] usage, or Q-in-Q [Q-in-Q], new encapsulation methods may be proposed, such as [MAC-in-MAC]. The U-PE devices can be connected with core network via a Switched Ethernet Transport (SET). The SET is considered to be the Ethernet access network when the traffic between U-PEs can be switched without the involvement of the N-PEs. >From the VPLS core perspective, there are two ways to build a distributed model: - using Point to Point PW [P2P] - using Multipoint to Point PW [M2P] The P2P-PWs are defined in [L2-FRW]. The first option is discussed in [ROSEN] and [DTLS] and presented also in the current GVPLS solution, as the default component. The second option would be discussed in the present document and represents a key contribution of the proposal. As a key requirement, GVPLS integrates both non-distributed and distributed models, so different VPN members that are provisioned in both models can participate in the same VPLS instance. In addition, we would discuss how the N-PE device can perform both the VPLS and GVPLS solutions, using the same architectural framework. 4.2 Attributes of the distributed model It is recognized that SP may deploy the non-distributed model and/or the distributed model, based on different vendors' solutions, scalability, reach-ability and port density requirements. While the non-distributed model has values, like simplicity, easy of deployment and manageability, it is well recognized that the distributed model has some compelling attributes: 1. Allow to deploy VPLS solutions using only the U-PE devices, without the MPLS/IP core amongst them. However, such VPLS access networks can be interconnected using MPLS/IP Metro core technology. 2. Allow to deploy, in flexible way, the U-PE devices in the COs or close to the CPE devices. Also, by dividing the work between the U-PE and N-PE devices, the single point of failure [like in the case of non-distributed model] is eliminated. With GVPLS model, even the N-PE failure will allow the U-PE devices on the same access network still to work. Radoaca, et. al Expires: August 2003 [Page 5] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 3. Allow to create access networks where a significant percentage of the traffic would stay local, without involving the N-PE devices in switching such traffic. This would free resources for the N-PE devices to perform other vital functions like L3 VPNs, or high touch services. 4. Allow a large number of VPNs to be deployed in the SP domain - this is a direct result of eliminating MAC learning in the N-PE devices, hence MAC explosion in the Metro core. In addition, by mixing the two models, a SP can incrementally deploy the VPLS service, based on the complex characteristics of the metro [such as customer density, diversity of the Ethernet ports, co-existence with legacy SDH/SONET infrastructure]. A VPLS offer can start from an access network, only with the U-PE devices, upgraded with an MPLS core, or can start from a non-distributed model and upgraded to a distributed model if the scalability parameters require such extension. 4.3 Functional components GVPLS extends the functional components described in [VPLS] in order to accommodate the distributed model. As such the following components are discussed: - control plane - signalling - auto-discovery - data plane - provisioning It is worth to note that the current document describes only what is essential for the distributed model, and the extensions to the [VPLS] description that is considered as the base line. As such, some functional components would be referred directly to the [VPLS] document. 4.4 GVPLS Topological model The GVPLS topological model is described in the figure 1. | | | +----+ | | /| P | | | / +----+\ | -----------------------|-----/ \ | | | /| \ | +----+ | +---------+ | / | \ | | CE |-|--| U-PE |\ | / | \ | +----+ | +---------+ \ | / | \| +----+ | \ +---------+| +-------+ +-| CE | +----+ | +---------+ \| || | | / +----+ | CE |-|--| U-PE |----| N-PE || | N-PE |< +----+ | +---------+ /| || | | \ +----+ | / +---------+| +-------+ +-| CE | +----+ | +---------+ / | \ | / | +----+ Radoaca, et. al Expires: August 2003 [Page 6] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 | CE |-|--| U-PE |/ | \| / | +----+ |/ +---------+ | \ +---+ +---+ | / | |\| P |--| P | | +----+/|----------------------|------ +---+ +---+ | | CE | Distributed model | |Non-distributed | | | | model +----+ | CORE NETWORK | Figure 1 The VPLS model [VPLS] is extended with the new type of devices, called U-PE [L2-FRW], that supports VPLS functionality. Such devices would inter-work with the N-PE or [VPLS] MTU devices capable of the VPLS functionality. 5. Information Model The Information model describes the essential information for the VPLS Service and the SP network in order to do consistent provisioning, discovering and signalling tasks. Also, the same information data should be used by competing protocols [ex. BGP versus LDP in signalling] for the same functionality. 5.1 VPN-ID A SP refers to a given VPLS by a VPN-ID [VPLS]. Such VPN-ID should be unique in the SP context. 5.2 Device Ids In GVPLS, the following device ids are defined: - N-PE-id, which identifies a N-PE device - U-PE-id, which identifies a U-PE device A device ID is encoded as 6 bytes long, is unique in the SP scope, and it's representation is a matter of the SP address scheme. 5.3 SP address scheme A distributed model is built around a specific SP address scheme that would allow the customer packets to be classified, encapsulated and forwarded solely based on such scheme. Following the [L2-FRW] reference model, the U-PE devices [or U-PE interface ports] can be used to encode such SP address scheme. The SP address scheme has the following basic attributes: - SRC-ID [or SRC-U-PE-ID] represents the address of the originator U-PE [or N-PE] device, or U-PE Interface - DST-ID [or DST-U-PE-ID] represents the address of the destination U-PE [or N-PE] device, or U-PE Interface Radoaca, et. al Expires: August 2003 [Page 7] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 - VPN-ID represents the ID of a given VPN - VPN-FLG a set of bits that represents some conditions on the packet forwarding such multicast, OAM/continuity check, and so on. Most of the VPN-FLG bits can be advertised on the VPLS Control plane [In the current GVPLS solution, the only flag that is mapped in Data plane is the OAM flag]. There are different ways to encode such scheme: - using MAC address of the U-PE/N-PE devices [MAC-in-MAC] or MAC Addresses of U-PE access ports, when the U-PE devices are not bridge capable - using SP Ids of the U-PE/N-PE devices or SP Ids of U-PE access ports, when the U-PE devices are not bridge capable - etc. The SP address scheme can be mapped into underlying access protocols, such Q-in-Q [Q-in-Q], MAC-in-MAC [MAC-In-MAC], or [PWE3-ETHERNET]. In the distributed model, the U-PE devices are enhanced to perform SP encapsulation with the following information: (SRC-ID, DST-ID, VPN-ID, VPN-FLG). In addition, the U-PE devices would perform MAC learning and forwarding against the SRC-ID and DST-ID parameters. Once a packet arrives to the destination U-PE, the device would perform forwarding decision based on the customer MAC addresses. Note: Based on these assumptions, a VPLS service can be built without N-PE devices - this would allow to deploy the VPLS service in small metro access networks and to join them using the MPLS/IP [VPLS Core] core network, via GVPLS solution. 5.4 Information Model entities The GVPLS terminology is based on the [L2-FRW] and VPLS. GVPLS uses the following information model enities: PE - Provider Edge Based on the [L2-FRW] model, for distributed VPLS case, two types of device are described: - U-PE - User facing PE - N-PE - Network facing PE VC-LSP [PWE3-CTRL] defines how to carry L2 PDUs over point-to-point MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS or GRE tunnels. The VC-LSPs can be distributed between the U-PE and N-PE devices, and between the N-PE devices. VC-Label VC-Label (or Service Label) identifies the multiplexing value, or the service label on top of the MPLS tunnels. Radoaca, et. al Expires: August 2003 [Page 8] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 VPLS Port (VP) It represents a physical or a logical port where a VPLS is provisioned. Such port can reside on the U-PE or N-PE device. A CE is connected to the VPLS Port. The VPLS Port can be provisioned with a VLAN[802.1D-ORIG] , a set of VLANs or transparent (in this case, all the traffic on such port is accepted on the VPLS). Transparent and VLAN ports can be mixed in a VPLS scope. VPLS EndPoint (VEP) The VPLS EndPoint is used to represents the destination where a packet is to be forwarded, or from where the packet is coming, as the originating source. The VEP represents: - A U-PE and N-PE device which contains a minimum one VPLS port, if the device is capable to forward the packet based on MAC destination to its VPLS ports - A VPLS port, if the above condition doesn't hold The VEP-ID attribute stores the device id, which value can be: U-PE- id or N-PE-id. Ingress VEP-ID is known as SRC-ID while the egress VEP-ID is known DST-ID. Source Control Flag (src-cflag) It identifies the encoding mechanism for the ingress VEP. The VC-Labels calculation and the MAC source learning process are dependent on this flag. Service Header The service header is used to tag the customer traffic through the Service Provider access network, i.e. SET. It is used to effectively identify the VPN that the customer belongs to. Also, it may contains VPN Flags that are needed in order to forward the traffic independently of the N-PE devices - example: M: denotes the port type (it's transparent or mapped) C: denotes the traffic type (it's customer or OAM type) There are different methods to encapsulate such Service Header, like Q-in-Q, MAC-in-MAC and so on. End-to-End Path Identification An end-to-end path between a given U-PE source and a given U-PE destination can be described as a t-upl: (SRC-U-PE-ID, DST-U-PE-ID, VPN-ID). In the VPLS core, such path should be mapped on PWs (P2P, or M2P). As we will see later, there are possible multiple paths to same DST-ID, due to the Traffic engineering or dual homing connections of the U-PE devices. Let's call the N-PE device that is attached to the SRC-U-PE device as SRC-N-PE, and the N-PE device that is attached to the DST-U-PE device as DST-N-PE. Radoaca, et. al Expires: August 2003 [Page 9] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 A VPLS core PW path that is built between two different N-PE devices (SRC and DST), is defined as a t-upl with the following information: <, >. Mutlipoint to Point PW (M2P PW) A Multipoint to point PW is defined by a set of VC-LSPs that originate from different sources (ex. N-PE-Ids) and terminate in one U- PE-ID destination. For M2P PW the SRC-U-PE-id is set to zero - however, the SRC-U-PE-id information is transported in the data path by using different methods, like the Control Word [PWE3-CTRL]. The above concepts are shown in the figure 2. +-----------+ +--------+ +--------+ +--------+ | SRC-U-PE | |SRC-N-PE| |DST-N-PE| |DST-U-PE| +-----------+ +--------+ +--------+ +--------+ VPLS PW (VPN-ID) < --------------------- > End-to-End Path (VPN-ID) < --------------------------------------------------- > Figure 2 5.5 SP Address scheme mapping to the VPLS core As described in section above, the key aspect of the distributed model is to provide some sort of SP address scheme, so the customer packets can be forwarded in the SP domain, using only the SP address scheme. In the distributed model, the SP address scheme encompasses the following attributes, SRC-ID, DST-ID, VPN-FLG, VPN-ID. Consequently, in the access network, the customer packets should be encapsulated with the above information. In order for the N-PE device to forward the traffic from the access Network (that comes with VPN-ID, SRC-ID, DST-ID information), toward the core, it needs to find a PW, with the following match criteria: - VPN-ID of the PW - DST-ID equal with the DST-U-PE-ID of the PW When, following this match criteria, different PWs result to the same destination, then other criteria (policy based) can be used to select one of the PW. As we can realize, the binding between the access protocols [ex. Attachment circuits] and VPLS LSPs is done in the data plane. 5.6 N-PE's VSI and FIBs The N-PE VSI [L2-FRW] can be decomposed in two logical entities: Radoaca, et. al Expires: August 2003 [Page 10] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 - VSI-U that performs MAC learning, identification of DST-ID and forwarding toward the DST-ID - VSI-N that performs mapping between DST-ID and the PW ( or Set of PWs) that leads to the DST-ID. The VSI-U FIB is built using the standard bridging functionality. The VSI-N FIB is built using two lists: -local-list -remote-list Each t-upl <, > defines a PW or a list of PWs that can forward the customer traffic from the SRC-ID to the DST-ID and reverse. In the case of non-distributed model [VPLS], the SRC-ID field is equal with SRC-N-PE-ID and the DST-ID is equal with DST-N-PE-ID. The SRC-N-PE-ID and DST-N-PE-ID can be set to NULL. This shows that both models can be accommodated within the same VSI infrastructure. It also important to note that from VSI perspective it is transparent if the SRC-ID or DST-ID represents a U-PE or an N- PE device. This also implies that U-PE-ID and N-PE-ID need to have the same representation and to be unique across of the SP network. In the non-distributed model the N-PE VSI-U is not used, because such functionality would be performed by the U-PE device. In addition, the U-PE device would deliver the packet with information. The VSI-N would perform forwarding decision, regardless if the packet is coming from the local VSI-U or from the subtended U-PE device. Further optimizations can be done if we assume that U-PE-ID and N- PE-ID are represented as MAC addresses, like in MAC-in-MAC proposal. In this case, the VSI-U and VSI-N can use the same FIB. 6. Control Plane The following section describes the Auto-Discovery, Signaling and Provisioning. 6.1 Provisioning and Auto-discovery As we mentioned above, the VP is the port on the U-PE device (or a port on N-PE device, when CE connects directly to N-PE) where a VPLS is provisioned. The VP,VPN-ID, VLAN(s) and other attributes (like QoS, etc.) define the VPN Member information. The VPLS provisioning has the following steps: Radoaca, et. al Expires: August 2003 [Page 11] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 1. Each N-PE has knowledge about any remote N-PE [using N-PE-ID]. In order to get such information, an auto-discovery protocol can be used (ex. BGP ). Following this step, the LDP sessions and/or VPLS tunnels are provisioned/generated between the N-PE devices 2. Each N-PE has knowledge about the subtended access network, so all the U-PE devices [using U-PE-ID] are known to the N-PE. This can be done via an access auto-discovery protocol (ex. LDP) for PWs or using the data plane bridging mode for MAC-in-MAC. As a result of configuration/auto-discovery process, the N-PE device will be given a list of U-PE devices. 3. A VPLS instance with a given VPN-ID is provisioned in each N-PE device that would be part of that VPLS scope. Following this step, a set of P2P PWs are generated between the corresponding N- PE devices (as in [VPLS]) 4. The VPLS VPN Members are provisioned on the U-PE interfaces [or N-PE interfaces]. The following information is propagated from the local U-PE/N-PE, to each remote N-PE: Following this step, each N-PE device builds a VSI-N FIB table with the following information: < VPN-Member-local-list: VPN- Member-remote-list>. This process can be completed by using an auto discovery protocol. For each pair a PW (P2P, or M2P) is created with the corresponding remote N-PE. In the signaling message the following data should be sent: <, >. The SRC indicates the local VP and DST indicate the remote VP. For the M2P PW the DST- U-PE-ID is set to zero - in other words for M2P, the signalling process doesn't need to know the remote VPN Members. Note for the [VPLS] model In the VPLS model [VPLS], the LDP Label Mapping message has the SRC-U-PE-id and the DST-U-PE-id set to respectively to SRC-N-PE-ID and to DST-N-PE-ID. The FIB records would have the VPN-Member set to VPN-ID and the U- PE-ID fields (SRC/DST) set to the corresponding N-PE-ID ( 14. Acknowledgments The GVPLS solution came out with the help, generous ideas, and efforts from a lot of people. We would like to recognize the involvement of Mirza Arifovic, and Hesahm Elbakouri in drafting the solution. We would also like to acknowledge Hamid Ould-Brahim, Michael Chen, Paul Valentine, from Nortel Networks, for their contributions. In addition we like to thank to Eric Rosen, Ali Sajassi from Cisco, Don O'Connor from Fujitsu for their comments and participation during this work. Radoaca, et. al Expires: August 2003 [Page 22] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 15. Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. 14. Authors' Addresses Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: (781) 856-0590/978-288-6097 Dinesh Mohan Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortelnetworks.com Javier Achirica Telefonica Data Email: javier.achirica@telefonica-data.com Pascal Menezes Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA Phone: (206) 686-2001 Email: Pascal.Menezes@Terabeam.com Ananth Nagarajan Sprint 9300 Metcalf Ave, Overland Park, KS 66212, USA ananth.nagarajan@mail.sprint.com Himanshu Shah Tenor Networks 100 Nagog Park Email : hshah@tenornetworks.com Yaron Raz Atrica Email : yaron_raz@atrica.com Radoaca, et. al Expires: August 2003 [Page 23] Internet Draft draft-radoaca-ppvpn-gvpls-01.txt Feb 2003 Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Andy.Malis@vivacenetworks.com Simon Hunt 186k Simon.Hunt@186k.co.uk Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Alain Vedrenne Equant, Customer Service & Network Strategic Technology Planning Heraklion; 1041 route des Dolines; BP347 06906 Sophia Antipolis; Cedex; France Phone: +33-(0)4-92-96-57-22 (7-223-5722) 15. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.