Provider Provisioned VPN WG Vasile Radoaca Internet Draft: Dinesh Mohan draft-radoaca-ppvpn-gvpls-02.txt Nortel Networks Expiration Date: December 2003 Ananth Nagarajan Sprint Javier Achirica Telefonica Data Pascal Menezes 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 June 2003 GVPLS/LPE - Generalized VPLS Solution based on LPE Framework 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-02.txt June 2003 Abstract This document describes distributed virtual private LAN service (VPLS) solution over MPLS using LDP signaling. 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 co-exist in the same SP network. This implies a need of signaling mechanisms to support these new classes of solutions. The current draft presents the GVPLS solution that addresses such issues. The term "Generalized" in this document is used to reflect the unified aspect of the two models. 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-control- protocol-02.txt http://search.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet- encap-02.txt http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn- requirements-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp- 00.txt http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2-framework- 03.txt http://search.ietf.org/internet-drafts/draft-rosen-ppvpn-l2- signaling-03.txt WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN Radoaca, et. al Expires: December 2003 [Page 2] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 WHY IS IT TARGETTED AT THIS WG The charter of the PPVPN WG includes L2 VPN services and this draft specifies a distributed model for Ethernet L2 VPN services over MPLS. JUSTIFICATION Existing Internet drafts specify how to provide point-to-point and multi-point Ethernet L2 VPN services over MPLS. This draft defines how multipoint Ethernet services can be provided using the distributed model, a Generalized Signaling mechanism [PEW3-CTRL] and scalability requirements to be implemented. Table of Contents Status of this Memo..............................................1 Abstract.........................................................2 Conventions Used.................................................2 1. Introduction..................................................3 1.1 Overview...................................................4 1.2 Attributes of the distributed model..........................5 1.3 Functional components........................................6 1.4 GVPLS Topological model......................................6 2.10 SP Address scheme mapping to the VPLS core..................9 2.11 N-PE's VSI and FIBs........................................10 3. Signaling....................................................10 3.1 Identify the SAII with the local or remote N-PE.............11 3.2 Egress N-PE processing......................................12 4. Data Plane Aspects...........................................12 4.1 Access Encapsulation........................................12 4.2 VPLS Core Encapsulation.....................................13 4.3 Forwarding..................................................13 4.4 Replication and flooding....................................13 4.5 OAM Mechanism...............................................13 5. VPLS Resiliency..............................................14 6. Security Considerations......................................14 7. Compliance with the PPVN Requirements........................14 8. References...................................................15 9. Acknowledgments..............................................15 10. Intellectual Property Considerations........................16 11. Authors' Addresses..........................................16 1. Introduction Radoaca, et. al Expires: December 2003 [Page 3] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 This document describes virtual private LAN service (VPLS) solution over MPLS, called Generalized VPLS/LPE (GVPLS), based on the distributed model, and the Generalized signaling method [PWE3- CTRL]. In the current landscape of VPLS solutions there are other attempts to describe the distributed model, e.g. [DTLS] and [ROSEN-LDP]. This draft is different from the approach taken in [ROSEN-LDP], as follows: . The proposed model uses a Service Provider address scheme that is independent from the access network type. This would allow use of different access connectionless protocols to be included as part of the VPLS solution and to interwork seamlessly with protocols like PW or Provider VLAN based Ethernet Access Networks . The algorithm used for selecting the VPLS core PWs presented in [ROSEN-LDP] is a sub-set of the algorithm that is proposed in the current solution. Also, the GVPLS algorithm is applicable for non-distributed model and it allow further optimisations in order to increase the scalability of the VPLS PWs . It describes a complete VPLS solution . The unknown and mulitcast traffic is well optimized . Allows inter-working between [VPLS] and the distributed model 1.1 Overview Following [L2-FRW], regardless of the signaling 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 like MAC learning/forwarding and VPLS forwarding is distributed across the U-PE and 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), by using U-PE and N-PE devices. The U-PE and N-PE devices are connected via P2P PWs to address number of PW between PE devices or provider VLAN based Ethernet access networks, however, both U-PE and N-PE devices perform customers MAC learning and forwarding. Following the Reference Model for VPLS in [L2-FRW] the GVPLS solution extends and complements the non-distributed model to support the distributed model. In this respect, GVPLS extends the [VPLS] model in two key areas: access network and core network. Radoaca, et. al Expires: December 2003 [Page 4] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 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 signaling of the VPN membership. In order to enable and scale such model, besides PWs [PWE3-CTRL] usage, or provider VLAN based ethernet access networks, new encapsulation methods may be proposed in the future. The U-PE devices can be connected with core network via Ethernet access networks when the traffic between U-PEs can be switched without the involvement of the N-PEs. Also, the U-PE devices can be connected directly via PWs. The VPLS core is built using PW, based on the Generalized PW model [PWE3-CTRL]. 1.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, reachability 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: . Allows deploying, 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 N-PE single failure impact is limited, compare to the non-distributed model. . Allows creating access networks where a significant percentage of the traffic would stay local, without involving the N-PE devices in switching such traffic. . Allow a large number of VPNs to be deployed in the SP domain, when the CE devices are mainly L2 Bridges - 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. Radoaca, et. al Expires: December 2003 [Page 5] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 1.3 Functional components GVPLS extends the functional components described in [VPLS] and [PWE3-CTRL} in order to accommodate the distributed model. As such the following components are discussed: . Control plane o Signaling o Auto-discovery . Data plane The provisioning and auto-discovery components would be presented in separate drafts. This draft focuses on the signaling and data plane aspects. 1.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 | +----+ | +-------+ / | \ | / | +----+ | CE |-|--| U-PE |/ | \| / | +----+ |/ +-------+ | \ +---+ +---+ | / | |\| P |--| P | | +----+/|--------------------|-----| +---+ +---+ | | CE | Distributed model | |Non-distributed +----+ | Core Network | model | | 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] PE-rs devices capable of the VPLS functionality. Radoaca, et. al Expires: December 2003 [Page 6] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 2. 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 signaling tasks. Also, the same information data should be used by competing protocols [e.g. BGP versus LDP in signaling] for the same functionality. 2.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. VPN-ID format can be similar to one used in [VPLS], [RFC2685] etc. 2.2 Device Ids In GVPLS, the following device ids are defined: . N-PE-id, which identifies an N-PE device . U-PE-id, which identifies a U-PE device A device ID is unique in the SP scope and its representation is a matter of the SP address scheme. 2.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 ingress U- PE [or N-PE] device, or U-PE Interface . DST-ID [or DST-U-PE-ID] represents the address of the egress U- PE [or N-PE] device, or U-PE Interface . VPN-ID represents the ID of a given VPN The SP address scheme can be mapped into underlying access protocols, e.g. Provider VLAN based Ethernet access networks 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). In addition, the U-PE devices would perform MAC learning and forwarding against the SRC-ID and DST-ID parameters. Radoaca, et. al Expires: December 2003 [Page 7] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 Once a packet arrives to the destination U-PE, the device would perform forwarding decision based on the customer MAC addresses. 2.4 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. 2.5 VC-Label VC-Label (or Service Label) identifies the multiplexing value, or the service label on top of the MPLS tunnels for VC-LSPs. 2.6 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 [IEEE802.1Q], a set of VLANs or untagged (in this case, all the traffic on such port is accepted on the VPLS). Untagged and VLAN ports can be mixed in a VPLS scope. 2.7 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 2.8 Source Control Flag (src-cflag) It identifies the encoding mechanism for the ingress VEP. The VC-Labels calculation and the MAC source learning process behavior can be determined based on this flag. 2.9 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 tuple: (SRC-U-PE-ID, DST-U-PE- ID, VPN-ID). Radoaca, et. al Expires: December 2003 [Page 8] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 In the VPLS core, such path should be mapped on PWs. 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. A VPLS core PW path that is built between two different N-PE devices (SRC and DST), is defined as a tuple with the following information: <, >. 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 2.10 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, and 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 . SRC-ID equal with the SRC-U-PE-ID of the PW Radoaca, et. al Expires: December 2003 [Page 9] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 2.11 N-PE's VSI and FIBs The N-PE VSI [L2-FRW] can be decomposed in two logical entities: . U-VSI that performs MAC learning, identification of DST-ID and forwarding toward the DST-ID . N-VSI that performs mapping between DST-ID and the PW (or Set of PWs) that leads to the DST-ID. 3. Signaling In the following section, the GVPLS Address Scheme is mapped to PWE3 generalized signaling method [PWE3-CTRL] with some additional enhancements. [PWE3-ETHERNET] 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. In GVPLS, the U-PE may have one control connection per N-PE device, regardless the number of VPLS provisioned. When the U-PE is connected via dual homing, two control sessions may exist between this U-PE and the two related N-PEs. This simplifies the number of control connections that need to be maintained by the U-PE device and the amount of information that needs to be signaled to the other U-PE members in the VPLS space. The N-PE devices, using LDP Extended Discovery mechanism, maintain a full mesh of LDP sessions between them. In the distributed model the U-PE devices are attached to the N-PE devices via a layer 2 connection, called : such link can be connection less type (for example in the case of Provider VLAN based Ethernet access networks, or Ethernet access) or connection oriented type using PW (Martini's style). A connection end-to-end between two U-PEs, is composed of two U-PE links, and one PW from N-PE to N-PE. At a given U-PE, in a given VPLS there is a list of tuple (SRC-ID, DST-ID). Such list can be learned in the data plane or can be distributed in the control plane via the configuration/discovery process. Each element of the list tells the U-PE to build U-PE connections between the U-PE and the N-PE (between VSI-U/U-PE and VSI/N-PE). At a given N-PE, the VSI-N FIB is built using two lists: . Local-list . Remote-list Radoaca, et. al Expires: December 2003 [Page 10] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 Each tuple <, > tells to N-PE to set a PW that can forward the customer traffic from the SRC-ID to the DST-ID and reverse. Using generalized signaling mechanism [PWE3-CTRL]; the mapping is done as following: The Local N-PE that has knowledge of the remote N-PE initiates a setup of the LSP in the incoming (remote N-PE -> local N-PE) by sending a Label Mapping Message with the following info: AGI = VPN-ID SAII= DST-U-PE-ID TAII= SRC-U-PE-ID The remote N-PE that has knowledge of the local N-PE initiates a setup of the LSP in the incoming (local N-PE -> remote N-PE) by sending a Label Mapping Message with the following info: AGI = VPN-ID; SAII= SRC-U-PE-ID TAII= DST-U-PE-ID 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 TAII of the PW . SRC-ID equal with the SAII of the PW For example, when the traffic is forwarding from the SRC-ID to the DST-ID, then on the local N-PE, the DST-ID needs to match the TAII = DST-U-PE-ID. When the traffic is forwarding from the DST-ID to the SRC-ID, then the remote N-PE needs to match the TAII = SRC-U- PE-ID. An LSP between local N-PE -> remote N-PE has the forwarders defined as following: for the local N-PE is VSI/TAII and for the remote N-PE is VSI/SAII. Similarly, an LSP between remote N-PE -> local N-PE has the forwarders defined as following: for the remote N-PE is VSI/SAII and for the local N-PE is VSI/TAII. IF we combine the above statements, then it results that for each N-PE and a given PW, the forwarder is defined as VSI/. 3.1 Identify the SAII with the local or remote N-PE Radoaca, et. al Expires: December 2003 [Page 11] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 For just MPLS forwarding in the VPLS core, the only field important is the TAII. The SAII presence is to identify the Source of the packet for the U-PE devices so these devices can do L2 MAC forwarding and bridge learning. For the LSP (remote N-PE -> local N-PE), we can consider the case when SAII = Remote-N-PE-ID. For the LSP (local N-PE -> remote N- PE), we can consider the case when SAII = Local-N-PE-ID. So, the following relationships hold: LSP(remote N-PE->local N-PE) : (SAII= remote-N-PE, TAII= SRC-U-PE- ID) LSP(local N-PE->remote N-PE) : (SAII= local-N-PE, TAII= DST-U-PE- ID). In this case, the number of PWs decreases significantly (one order of magnitude). However, for U-PE devices to properly learn the source of the packet, the N-PE needs to transport the source in the date plane. The Generalized ID FEC [PWE3-CTRL] is augmented with two new parameters: The SRC-CW-U-PE-ID is an ID encoded for the SRC-U-PE-ID, which is unique in the scope of a given VPN-ID. This ID can be provisioned or generated based on algorithm that will be described in a subsequent version of the GVPLS. As it was stated above, during the MAC learning process the SRC-ID is needed in order that a receiver U-PE device (DST-ID) can forward the traffic in the VPLS core. The src-cflag denotes the encoding mechanism for the source U-PE or N-PE device that originates the packet. 3.2 Egress N-PE processing At the egress side, from the N-PE to the U-PE device, the packet is coming with the PW encapsulation, from where the SRC-ID, DST-ID and the VPN-ID information are mapped back to the underline access protocol. In the case of SAII identified with the N-PE then the SRC-ID is derived from the Data Plane encapsulation. 4. Data Plane Aspects 4.1 Access Encapsulation In the VPLS access network, the SP address scheme (SRC-U-PE, DST- U-PE, VPN-ID) can be implemented using different underlying Radoaca, et. al Expires: December 2003 [Page 12] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 protocols, such as PW [PWE3-ETHERNET], or connectionless protocols (like, Provider VLAN based Ethernet access networks). The specification of such mapping and a signaling protocol is out of scope of this document. 4.2 VPLS Core Encapsulation In the VPLS core, GVPLS employs the [PWE3-Ethernet] based encapsulation. However the SRC-ID may be encapsulated in the data plane in order to optimize the number of PWs; this would be described in a separate draft. 4.3 Forwarding The U-PE device is capable to do MAC learning and forwarding based on the SP address scheme as such SRC-ID, DST-ID, VPN-FLG and VPN- ID. The VPN-FLG has two bits, Continuity Check [C], and Multicast Flag [M]. In the VPLS core, the N-PE device is doing packet forwarding by mapping the incoming tuple (SRC-ID, DST-ID, VPN-ID, VPN-FLG) with a specific PW TAII data. 4.4 Replication and flooding The replication and flooding uses P2P PWs, denoted as Multicast PWs, which are constructed among the N-PE devices (with SRC-ID = SRC-N-PE-ID, DST-ID = DST-N-PE-ID). The packets that are coming from the access side, would have a Multicast/Unknown indication. Based on such indication the Multicast PWs are selected. Note If Multicast PWs are not used, the replication needs to be done per P2P PW that connected the U-PE devices. When multiple U-PE devices are attached to the same N-PE device, than multiple customer packets need to be sent to that N-PE - this may impact the bandwidth in the core. 4.5 OAM Mechanism The GVPLS OAM mechanism is based on the Control Word extension. The "C" flag is set by the ingress U-PE device [or N-PE device for non-distributed] and can be used to trigger unicast, and multicast packets between VPs, in order to check the status of the specific VC-LSP(s), to calculate round trip delay and other values that can be used for SLA. For normal encapsulated data traffic, the "C" flag is always clear. Radoaca, et. al Expires: December 2003 [Page 13] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 5. VPLS Resiliency The GVPLS model allows greater flexibility in building resiliency between U-PE and N-PE devices. When a U-PE device is connected to a single N-PE device using multiple physical links, standard link aggregation and load-distribution techniques can be used between the two devices. The load-distribution should be done in such a way so as to avoid packet reordering and duplicate packets within a VPLS instance. The exact algorithm for load balancing between U- PE and N-PE is really a matter of local decision. When a U-PE device is dual-homed to two different N-PE devices, only one of the N-PE devices should be elected as the primary for any particular VPLS. This is so as to avoid duplicate multicast packets being transmitted to the dual-homed U-PE device. It must be ensured that no packet-reordering or duplicate multicast packets are sent in steady state and in any failure recovery scenario. Since the GVPLS model defines a SP addressing scheme to identify individual U-PE devices (and their ports if the U-PE device is not bridge-capable), this information can be exchanged between a dual- homed U-PE and its N-PEs a priori, i.e. before a failure happens. When a failure happens, the N-PEs can intelligently perform failure recovery in the access networks as they can independently identify the dual-homed U-PE device using the SP addressing scheme. The exact mechanisms for failure detection and recovery will be described further in future. 6. Security Considerations Security issues resulting from this draft will be discussed in greater depth at a later point. It is recommended in [RFC3036] that LDP authentication methods be applied. This would prevent unauthorized participation by a PE in a VPLS. Traffic separation for a VPLS is effected by using VC labels. However, for additional levels of security, the customer MAY deploy end-to-end security, which is out of the scope of this draft. 7. Compliance with the PPVN Requirements The GVPLS solution is compliant with most of the requirements. However, the design was chosen in order to allow large deployments of VPNs, while maintaining the PE performance and security constant. Radoaca, et. al Expires: December 2003 [Page 14] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 8. References [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 01.txt, Work in progress, November 2003-03-02 [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf- pwe3-control-protocol-02.txt, Work in progress, February 2003 [802.1D-REV] 802.1D - "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998 [IEEE802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", July 1998 [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs" draft-ietf-ppvpn- rfc2547bis-03.txt [RFC3036] "LDP Specification", Andersson, et al RFC 3036, January 2001 [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", draft-ietf-ppvpn-vpn-requirements-01.txt, Work in progress, October 2002 [VPLS] Lasserre, M. et al., " Virtual Private LAN Services over MPLS", draft-ietf-ppvpn-vpls-ldp-00.txt, work in progress, December 2003. [LPE] Ould-Brahim, H., et al., "VPLS/LPE L2VPNS: Virtual Private LAN Service using logical PE architecture", draft-ouldbrahim- l2vpn-lpe-02.txt, work in progress, March 2002 [L2-FRW] L2 PPVN framework, draft-ietf-ppvn-l2-framework-03.txt, work in progress, August 2003 [ROSEN-LDP] Eric Rosen "LDP-based signaling for L2VPNs", draft- rosen-ppvpn-l2-sign-03.txt, work in progress, November 2003 [VPLS-COMP] Michael Chen, Mohan Dinesh, Vasile Radoaca "VPLS solutions: Commonalities and Differences", work in progress, draft-chen-ppvn-dvpls-compare-04.txt, February 2003 9. Acknowledgments Radoaca, et. al Expires: December 2003 [Page 15] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 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, Lakkapragada, Shobhan 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. 10. 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. 11. 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 Lakkapragada, Shobhan Nortel Networks 600 Technology Park Billerica, MA 01821 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 Radoaca, et. al Expires: December 2003 [Page 16] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 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 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) 12. 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 Radoaca, et. al Expires: December 2003 [Page 17] Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003 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.