{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}} \viewkind4\uc1\pard\lang1033\f0\fs20\par \par \par Provider Provisioned VPN WG Vasile Radoaca\par Internet Draft: Dinesh Mohan\par draft-radoaca-l2vpn-gvpls-03.txt Nortel Networks\par Expiration Date: March 2004\par Ananth Nagarajan\par Sprint\par \par Javier Achirica\par Telefonica Data\par Pascal Menezes\par Terabeam Andrew Malis\par Vivace Networks\par Marty Borden\par Yaron Raz\par Yael Dayan\par \par Simon Hunt Atrica\par 186k\par Alain Vedrenne\par Muneyoshi Suzuki Equant\par NTT Corporation\par Shah Himanshu\par Tenor Networks\par \par November 2003\par \par \par \par GVPLS/LPE - Generalized VPLS Solution based on LPE Framework\par \par \par \par Status of this Memo\par \par This document is an Internet-Draft and is in full conformance with\par all provisions of Section 10 of RFC2026.\par \par Internet-Drafts are working documents of the Internet Engineering\par Task Force (IETF), its areas, and its working groups. Note that\par other groups may also distribute working documents as Internet-\par Drafts.\par \par Internet-Drafts are draft documents valid for a maximum of six\par months and may be updated, replaced, or obsoleted by other\par documents at any time. It is inappropriate to use Internet-Drafts\par as reference material or to cite them other than as "work in\par progress."\par \par The list of current Internet-Drafts can be accessed at\par http://www.ietf.org/ietf/1id-abstracts.txt\par The list of Internet-Draft Shadow Directories can be accessed at\par http://www.ietf.org/shadow.html.\par \par Radoaca, et. al Expires: April 2003 [Page 1] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par \par \par Abstract\par \par This document describes distributed virtual private LAN service\par (VPLS) solution over MPLS using LDP signaling.\par \par For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW]\par introduces two types of models: distributed and non-distributed.\par \par While [VPLS] solution presents a non-distributed model, it is\par recognized that both models may co-exist in the same SP network.\par This implies a need of signaling mechanisms to support these new\par classes of solutions.\par \par The current draft presents the GVPLS solution that addresses such\par issues. The term "Generalized" in this document is used to reflect\par the unified aspect of the two models.\par \par \par Conventions Used\par \par The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL\par NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and\par "OPTIONAL" in this document are to be interpreted as described in\par RFC-2119 [2].\par \par \par Placement of this Memo in Sub-IP Area\par \par RELATED DOCUMENTS\par \par http://search.ietf.org/internet-drafts/draft-ietf-pwe3-control-\par protocol-02.txt\par http://search.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-\par encap-02.txt\par http://search.ietf.org/internet-drafts/draft-ietf-l2vpn-l2vpn-\par requirements-00.txt\par http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-\par 00.txt\par http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-\par 03.txt\par http://search.ietf.org/internet-drafts/draft-rosen-l2vpn-l2-\par signaling-03.txt\par \par \par WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK\par \par l2vpn\par \par \par \par Radoaca, et. al Expires: March 2004 [Page 2] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par WHY IS IT TARGETTED AT THIS WG\par \par The charter of the l2vpn WG includes L2 VPN services and this\par draft specifies a distributed model for Ethernet L2 VPN services\par over MPLS.\par \par \par JUSTIFICATION\par \par Existing Internet drafts specify how to provide point-to-point and\par multi-point Ethernet L2 VPN services over MPLS. This draft defines\par how multipoint Ethernet services can be provided using the\par distributed model, a Generalized Signaling mechanism [PEW3-CTRL]\par and scalability requirements to be implemented.\par \par \par Table of Contents\par \par Status of this Memo..............................................1\par Abstract.........................................................2\par Conventions Used.................................................2\par 1. Introduction..................................................3\par 1.1 Overview...................................................4\par 1.2 Attributes of the distributed model..........................5\par 1.3 Functional components........................................6\par 1.4 GVPLS Topological model......................................6\par 2.10 SP Address scheme mapping to the VPLS core..................9\par 2.11 N-PE's VSI and FIBs........................................10\par 3. Signaling....................................................10\par 3.1 Identify the SAII with the local or remote N-PE.............11\par 3.2 Egress N-PE processing......................................12\par 4. Data Plane Aspects...........................................12\par 4.1 Access Encapsulation........................................12\par 4.2 VPLS Core Encapsulation.....................................13\par 4.3 Forwarding..................................................13\par 4.4 Replication and flooding....................................13\par 4.5 OAM Mechanism...............................................13\par 5. VPLS Resiliency..............................................14\par 6. Security Considerations......................................14\par 7. Compliance with the PPVN Requirements........................14\par 8. References...................................................15\par 9. Acknowledgments..............................................15\par 10. Intellectual Property Considerations........................16\par 11. Authors' Addresses..........................................16\par \par \par 1. Introduction\par \par \par Radoaca, et. al Expires: March 2004 [Page 3] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par This document describes virtual private LAN service (VPLS)\par solution over MPLS, called Generalized VPLS/LPE (GVPLS), based on\par the distributed model, and the Generalized signaling method [PWE3-\par CTRL].\par \par In the current landscape of VPLS solutions there are other\par attempts to describe the distributed model, e.g. [DTLS] and\par [ROSEN-LDP].\par \par This draft is different from the approach taken in [ROSEN-LDP], as\par follows:\par \par . The proposed model uses a Service Provider address scheme that\par is independent from the access network type. This would allow\par use of different access connectionless protocols to be included\par as part of the VPLS solution and to interwork seamlessly with\par protocols like PW or Provider VLAN based Ethernet Access\par Networks\par . The algorithm used for selecting the VPLS core PWs presented in\par [ROSEN-LDP] is a sub-set of the algorithm that is proposed in\par the current solution. Also, the GVPLS algorithm is applicable\par for non-distributed model and it allow further optimisations in\par order to increase the scalability of the VPLS PWs\par . It describes a complete VPLS solution\par . The unknown and mulitcast traffic is well optimized\par . Allows inter-working between [VPLS] and the distributed model\par \par \par 1.1 Overview\par \par Following [L2-FRW], regardless of the signaling and auto-discovery\par protocols, two paradigms can be identified for the VPLS solutions:\par \par . Non-distributed model - the MAC learning/forwarding and VPLS\par forwarding is done in a PE device\par . Distributed model - the VPLS functionality like MAC\par learning/forwarding and VPLS forwarding is distributed across\par the U-PE and the N-PE devices\par \par [VPLS] describes a non-distributed solution where the VPLS\par functionality is concentrated in the PE device. The solution is\par enhanced with a hierarchical model (called HVPLS), by using U-PE\par and N-PE devices. The U-PE and N-PE devices are connected via P2P\par PWs to address number of PW between PE devices or provider VLAN\par based Ethernet access networks, however, both U-PE and N-PE\par devices perform customers MAC learning and forwarding.\par \par Following the Reference Model for VPLS in [L2-FRW] the\par GVPLS solution extends and complements the non-distributed model\par to support the distributed model. In this respect, GVPLS extends\par the [VPLS] model in two key areas: access network and core\par network.\par \par Radoaca, et. al Expires: March 2004 [Page 4] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par The access network is extended with a new type of U-PE device that\par is capable to perform the VPLS service, with or without the N-PE\par devices. Therefore, such devices would perform MAC learning and\par forwarding to other U-PE devices and may perform auto-discovery\par and signaling of the VPN membership. In order to enable and scale\par such model, besides PWs [PWE3-CTRL] usage, or provider VLAN based\par ethernet access networks, new encapsulation methods may be\par proposed in the future.\par \par The U-PE devices can be connected with core network via Ethernet\par access networks when the traffic between U-PEs can be switched\par without the involvement of the N-PEs. Also, the U-PE devices can\par be connected directly via PWs.\par \par The VPLS core is built using PW, based on the Generalized PW model\par [PWE3-CTRL].\par \par \par 1.2 Attributes of the distributed model\par \par It is recognized that SP may deploy the non-distributed model\par and/or the distributed model, based on different vendors\par solutions, scalability, reachability and port density\par requirements.\par \par While the non-distributed model has values, like simplicity, easy\par of deployment and manageability, it is well recognized that the\par distributed model has some compelling attributes:\par \par . Allows deploying, in flexible way, the U-PE devices in the COs\par or close to the CPE devices. Also, by dividing the work between\par the U-PE and N-PE devices, the N-PE single failure impact is\par limited, compare to the non-distributed model.\par . Allows creating access networks where a significant percentage\par of the traffic would stay local, without involving the N-PE\par devices in switching such traffic.\par . Allow a large number of VPNs to be deployed in the SP domain,\par when the CE devices are mainly L2 Bridges - this is a direct\par result of eliminating MAC learning in the N-PE devices, hence\par MAC explosion in the Metro core.\par \par In addition, by mixing the two models, a SP can incrementally\par deploy the VPLS service, based on the complex characteristics of\par the metro [such as customer density, diversity of the Ethernet\par ports, co-existence with legacy SDH/SONET infrastructure]. A VPLS\par offer can start from an access network, only with the U-PE\par devices, upgraded with an MPLS core, or can start from a non-\par distributed model and upgraded to a distributed model if the\par scalability parameters require such extension.\par \par \par \par Radoaca, et. al Expires: March 2004 [Page 5] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par 1.3 Functional components\par \par GVPLS extends the functional components described in [VPLS] and\par [PWE3-CTRL\} in order to accommodate the distributed model. As such\par the following components are discussed:\par \par . Control plane\par o Signaling\par o Auto-discovery\par . Data plane\par \par The provisioning and auto-discovery components would be presented\par in separate drafts. This draft focuses on the signaling and data\par plane aspects.\par \par \par 1.4 GVPLS Topological model\par \par The GVPLS topological model is described in the figure 1.\par \par | |\par | +----+ |\par | /| P | |\par | / +----+\\ |\par ---------------------|-----/ \\ |\par | | /| \\ |\par +----+ | +-------+ | / | \\ |\par | CE |-|--| U-PE |\\ | / | \\ |\par +----+ | +-------+ \\ | / | \\| +----+\par | \\ +---------+| +-------+ +-| CE |\par +----+ | +-------+ \\| || | | / +----+\par | CE |-|--| U-PE |----| N-PE || | N-PE |<\par +----+ | +-------+ /| || | | \\ +----+\par | / +---------+| +-------+ +-| CE |\par +----+ | +-------+ / | \\ | / | +----+\par | CE |-|--| U-PE |/ | \\| / |\par +----+ |/ +-------+ | \\ +---+ +---+ |\par / | |\\| P |--| P | |\par +----+/|--------------------|-----| +---+ +---+ |\par | CE | Distributed model | |Non-distributed\par +----+ | Core Network | model\par | |\par \par Figure 1\par \par \par The VPLS model [VPLS] is extended with the new type of devices,\par called U-PE [L2-FRW], that supports VPLS functionality. Such\par devices would inter-work with the N-PE or [VPLS] PE-rs devices\par capable of the VPLS functionality.\par \par \par \par Radoaca, et. al Expires: March 2004 [Page 6] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par 2. Information Model\par \par The Information model describes the essential information for the\par VPLS Service and the SP network in order to do consistent\par provisioning, discovering and signaling tasks. Also, the same\par information data should be used by competing protocols [e.g. BGP\par versus LDP in signaling] for the same functionality.\par \par \par 2.1 VPN-ID\par \par A SP refers to a given VPLS by a VPN-ID [VPLS]. Such VPN-ID should\par be unique in the SP context. VPN-ID format can be similar to one\par used in [VPLS], [RFC2685] etc.\par \par \par 2.2 Device Ids\par \par In GVPLS, the following device ids are defined:\par \par . N-PE-id, which identifies an N-PE device\par . U-PE-id, which identifies a U-PE device\par \par A device ID is unique in the SP scope and its representation is a\par matter of the SP address scheme.\par \par \par 2.3 SP address scheme\par \par A distributed model is built around a specific SP address scheme\par that would allow the customer packets to be classified,\par encapsulated and forwarded solely based on such scheme. Following\par the [L2-FRW] reference model, the U-PE devices [or U-PE interface\par ports] can be used to encode such SP address scheme.\par \par The SP address scheme has the following basic attributes:\par \par . SRC-ID [or SRC-U-PE-ID] represents the address of the ingress U-\par PE [or N-PE] device, or U-PE Interface\par . DST-ID [or DST-U-PE-ID] represents the address of the egress U-\par PE [or N-PE] device, or U-PE Interface\par . VPN-ID represents the ID of a given VPN\par \par The SP address scheme can be mapped into underlying access\par protocols, e.g. Provider VLAN based Ethernet access networks or\par [PWE3-ETHERNET].\par \par In the distributed model, the U-PE devices are enhanced to perform\par SP encapsulation with the following information: (SRC-ID, DST-ID,\par VPN-ID). In addition, the U-PE devices would perform MAC learning\par and forwarding against the SRC-ID and DST-ID parameters.\par \par Radoaca, et. al Expires: March 2004 [Page 7] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par Once a packet arrives to the destination U-PE, the device would\par perform forwarding decision based on the customer MAC addresses.\par \par \par 2.4 VC-LSP\par \par [PWE3-CTRL] defines how to carry L2 PDUs over point-to-point\par MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS\par or GRE tunnels. The VC-LSPs can be distributed between the U-PE\par and N-PE devices, and between the N-PE devices.\par \par \par 2.5 VC-Label\par \par VC-Label (or Service Label) identifies the multiplexing value, or\par the service label on top of the MPLS tunnels for VC-LSPs.\par \par \par 2.6 VPLS Port (VP)\par \par It represents a physical or a logical port where a VPLS is\par provisioned. Such port can reside on the U-PE or N-PE device. A CE\par is connected to the VPLS Port. The VPLS Port can be provisioned\par with a VLAN [IEEE802.1Q], a set of VLANs or untagged (in this\par case, all the traffic on such port is accepted on the VPLS).\par Untagged and VLAN ports can be mixed in a VPLS scope.\par \par \par 2.7 VPLS EndPoint (VEP)\par \par The VPLS EndPoint is used to represents the destination where a\par packet is to be forwarded, or from where the packet is coming, as\par the originating source. The VEP represents:\par \par . A U-PE and N-PE device which contains a minimum one VPLS port,\par if the device is capable to forward the packet based on MAC\par destination to its VPLS ports\par . A VPLS port, if the above condition doesn't hold\par \par \par 2.8 Source Control Flag (src-cflag)\par \par It identifies the encoding mechanism for the ingress VEP. The\par VC-Labels calculation and the MAC source learning process behavior\par can be determined based on this flag.\par \par \par 2.9 End-to-End Path Identification\par \par An end-to-end path between a given U-PE source and a given U-PE\par destination can be described as a tuple: (SRC-U-PE-ID, DST-U-PE-\par ID, VPN-ID).\par \par Radoaca, et. al Expires: March 2004 [Page 8] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par In the VPLS core, such path should be mapped on PWs. As we will\par see later, there are possible multiple paths to same DST-ID, due\par to the Traffic engineering or dual homing connections of the U-PE\par devices.\par \par Let's call the N-PE device that is attached to the SRC-U-PE device\par as SRC-N-PE, and the N-PE device that is attached to the DST-U-PE\par device as DST-N-PE.\par \par A VPLS core PW path that is built between two different N-PE\par devices (SRC and DST), is defined as a tuple with the following\par information:\par \par <, >.\par \par \par The above concepts are shown in the figure 2.\par \par +-----------+ +--------+ +--------+ +--------+\par | SRC-U-PE | |SRC-N-PE| |DST-N-PE| |DST-U-PE|\par +-----------+ +--------+ +--------+ +--------+\par VPLS PW (VPN-ID)\par < --------------------- >\par End-to-End Path (VPN-ID)\par < --------------------------------------------------- >\par \par Figure 2\par \par \par 2.10 SP Address scheme mapping to the VPLS core\par \par As described in section above, the key aspect of the distributed\par model is to provide some sort of SP address scheme, so the\par customer packets can be forwarded in the SP domain, using only the\par SP address scheme.\par \par In the distributed model, the SP address scheme encompasses the\par following attributes, SRC-ID, DST-ID, VPN-FLG, and VPN-ID.\par Consequently, in the access network, the customer packets should\par be encapsulated with the above information.\par \par In order for the N-PE device to forward the traffic from the\par access Network (that comes with VPN-ID, SRC-ID, DST-ID\par information), toward the core, it needs to find a PW, with the\par following match criteria:\par \par . VPN-ID of the PW\par . DST-ID equal with the DST-U-PE-ID of the PW\par . SRC-ID equal with the SRC-U-PE-ID of the PW\par \par \par Radoaca, et. al Expires: March 2004 [Page 9] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par 2.11 N-PE's VSI and FIBs\par \par The N-PE VSI [L2-FRW] can be decomposed in two logical entities:\par \par . U-VSI that performs MAC learning, identification of DST-ID and\par forwarding toward the DST-ID\par . N-VSI that performs mapping between DST-ID and the PW (or Set of\par PWs) that leads to the DST-ID.\par \par \par 3. Signaling\par \par In the following section, the GVPLS Address Scheme is mapped to\par PWE3 generalized signaling method [PWE3-CTRL] with some additional\par enhancements.\par \par [PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point\par MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS\par or GRE tunnels.\par \par In GVPLS, the U-PE may have one control connection per N-PE\par device, regardless the number of VPLS provisioned. When the U-PE\par is connected via dual homing, two control sessions may exist\par between this U-PE and the two related N-PEs.\par \par This simplifies the number of control connections that need to be\par maintained by the U-PE device and the amount of information that\par needs to be signaled to the other U-PE members in the VPLS space.\par \par The N-PE devices, using LDP Extended Discovery mechanism, maintain\par a full mesh of LDP sessions between them.\par \par In the distributed model the U-PE devices are attached to the N-PE\par devices via a layer 2 connection, called : such link\par can be connection less type (for example in the case of Provider\par VLAN based Ethernet access networks, or Ethernet access) or\par connection oriented type using PW (Martini's style). A connection\par end-to-end between two U-PEs, is composed of two U-PE links, and\par one PW from N-PE to N-PE.\par \par At a given U-PE, in a given VPLS there is a list of tuple (SRC-ID,\par DST-ID). Such list can be learned in the data plane or can be\par distributed in the control plane via the configuration/discovery\par process. Each element of the list tells the U-PE to build U-PE\par connections between the U-PE and the N-PE (between VSI-U/U-PE and\par VSI/N-PE).\par \par At a given N-PE, the VSI-N FIB is built using two lists:\par \par . Local-list \par . Remote-list \par \par Radoaca, et. al Expires: March 2004 [Page 10]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par Each tuple <, > tells to N-PE to set a PW that can forward the\par customer traffic from the SRC-ID to the DST-ID and reverse.\par \par Using generalized signaling mechanism [PWE3-CTRL]; the mapping is\par done as following:\par \par The Local N-PE that has knowledge of the remote N-PE initiates a\par setup of the LSP in the incoming (remote N-PE -> local N-PE) by\par sending a Label Mapping Message with the following info:\par \par AGI = VPN-ID\par SAII= DST-U-PE-ID\par TAII= SRC-U-PE-ID\par \par \par The remote N-PE that has knowledge of the local N-PE initiates a\par setup of the LSP in the incoming (local N-PE -> remote N-PE) by\par sending a Label Mapping Message with the following info:\par \par AGI = VPN-ID;\par SAII= SRC-U-PE-ID\par TAII= DST-U-PE-ID\par \par In order for the N-PE device to forward the traffic from the\par access Network (that comes with VPN-ID, SRC-ID, DST-ID\par information), toward the core, it needs to find a PW, with the\par following match criteria:\par \par . VPN-ID of the PW\par . DST-ID equal with the TAII of the PW\par . SRC-ID equal with the SAII of the PW\par \par For example, when the traffic is forwarding from the SRC-ID to the\par DST-ID, then on the local N-PE, the DST-ID needs to match the TAII\par = DST-U-PE-ID. When the traffic is forwarding from the DST-ID to\par the SRC-ID, then the remote N-PE needs to match the TAII = SRC-U-\par PE-ID.\par \par An LSP between local N-PE -> remote N-PE has the forwarders\par defined as following: for the local N-PE is VSI/TAII and for the\par remote N-PE is VSI/SAII. Similarly, an LSP between remote N-PE ->\par local N-PE has the forwarders defined as following: for the remote\par N-PE is VSI/SAII and for the local N-PE is VSI/TAII.\par \par IF we combine the above statements, then it results that for each\par N-PE and a given PW, the forwarder is defined as VSI/.\par \par \par 3.1 Identify the SAII with the local or remote N-PE\par \par \par Radoaca, et. al Expires: March 2004 [Page 11]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par For just MPLS forwarding in the VPLS core, the only field\par important is the TAII. The SAII presence is to identify the Source\par of the packet for the U-PE devices so these devices can do L2 MAC\par forwarding and bridge learning.\par \par For the LSP (remote N-PE -> local N-PE), we can consider the case\par when SAII = Remote-N-PE-ID. For the LSP (local N-PE -> remote N-\par PE), we can consider the case when SAII = Local-N-PE-ID. So, the\par following relationships hold:\par \par LSP(remote N-PE->local N-PE) : (SAII= remote-N-PE, TAII= SRC-U-PE-\par ID)\par LSP(local N-PE->remote N-PE) : (SAII= local-N-PE, TAII= DST-U-PE-\par ID).\par \par In this case, the number of PWs decreases significantly (one order\par of magnitude). However, for U-PE devices to properly learn the\par source of the packet, the N-PE needs to transport the source in\par the date plane.\par \par The Generalized ID FEC [PWE3-CTRL] is augmented with two new\par parameters:\par \par The SRC-CW-U-PE-ID is an ID encoded for the SRC-U-PE-ID, which is\par unique in the scope of a given VPN-ID. This ID can be provisioned\par or generated based on algorithm that will be described in a\par subsequent version of the GVPLS.\par \par As it was stated above, during the MAC learning process the SRC-ID\par is needed in order that a receiver U-PE device (DST-ID) can\par forward the traffic in the VPLS core. The src-cflag denotes the\par encoding mechanism for the source U-PE or N-PE device that\par originates the packet.\par \par \par 3.2 Egress N-PE processing\par \par At the egress side, from the N-PE to the U-PE device, the packet\par is coming with the PW encapsulation, from where the SRC-ID, DST-ID\par and the VPN-ID information are mapped back to the underline access\par protocol.\par \par In the case of SAII identified with the N-PE then the SRC-ID is\par derived from the Data Plane encapsulation.\par \par \par 4. Data Plane Aspects\par \par 4.1 Access Encapsulation\par \par In the VPLS access network, the SP address scheme (SRC-U-PE, DST-\par U-PE, VPN-ID) can be implemented using different underlying\par \par Radoaca, et. al Expires: March 2004 [Page 12]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par protocols, such as PW [PWE3-ETHERNET], or connectionless protocols\par (like, Provider VLAN based Ethernet access networks). The\par specification of such mapping and a signaling protocol is out of\par scope of this document.\par \par \par 4.2 VPLS Core Encapsulation\par \par In the VPLS core, GVPLS employs the [PWE3-Ethernet] based\par encapsulation. However the SRC-ID may be encapsulated in the data\par plane in order to optimize the number of PWs; this would be\par described in a separate draft.\par \par \par 4.3 Forwarding\par \par The U-PE device is capable to do MAC learning and forwarding based\par on the SP address scheme as such SRC-ID, DST-ID, VPN-FLG and VPN-\par ID. The VPN-FLG has two bits, Continuity Check [C], and Multicast\par Flag [M].\par \par In the VPLS core, the N-PE device is doing packet forwarding by\par mapping the incoming tuple (SRC-ID, DST-ID, VPN-ID, VPN-FLG) with\par a specific PW TAII data.\par \par \par 4.4 Replication and flooding\par \par The replication and flooding uses P2P PWs, denoted as Multicast\par PWs, which are constructed among the N-PE devices (with SRC-ID =\par SRC-N-PE-ID, DST-ID = DST-N-PE-ID). The packets that are coming\par from the access side, would have a Multicast/Unknown indication.\par Based on such indication the Multicast PWs are selected.\par \par \par Note\par If Multicast PWs are not used, the replication needs to be done\par per P2P PW that connected the U-PE devices. When multiple U-PE\par devices are attached to the same N-PE device, than multiple\par customer packets need to be sent to that N-PE - this may impact\par the bandwidth in the core.\par \par \par 4.5 OAM Mechanism\par \par The GVPLS OAM mechanism is based on the Control Word extension.\par The "C" flag is set by the ingress U-PE device [or N-PE device for\par non-distributed] and can be used to trigger unicast, and multicast\par packets between VPs, in order to check the status of the specific\par VC-LSP(s), to calculate round trip delay and other values that can\par be used for SLA. For normal encapsulated data traffic, the "C"\par flag is always clear.\par \par Radoaca, et. al Expires: March 2004 [Page 13]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par \par \par 5. VPLS Resiliency\par \par The GVPLS model allows greater flexibility in building resiliency\par between U-PE and N-PE devices. When a U-PE device is connected to\par a single N-PE device using multiple physical links, standard link\par aggregation and load-distribution techniques can be used between\par the two devices. The load-distribution should be done in such a\par way so as to avoid packet reordering and duplicate packets within\par a VPLS instance. The exact algorithm for load balancing between U-\par PE and N-PE is really a matter of local decision.\par \par When a U-PE device is dual-homed to two different N-PE devices,\par only one of the N-PE devices should be elected as the primary for\par any particular VPLS. This is so as to avoid duplicate multicast\par packets being transmitted to the dual-homed U-PE device. It must\par be ensured that no packet-reordering or duplicate multicast\par packets are sent in steady state and in any failure recovery\par scenario.\par \par Since the GVPLS model defines a SP addressing scheme to identify\par individual U-PE devices (and their ports if the U-PE device is not\par bridge-capable), this information can be exchanged between a dual-\par homed U-PE and its N-PEs a priori, i.e. before a failure happens.\par \par When a failure happens, the N-PEs can intelligently perform\par failure recovery in the access networks as they can independently\par identify the dual-homed U-PE device using the SP addressing\par scheme. The exact mechanisms for failure detection and recovery\par will be described further in future.\par \par \par 6. Security Considerations\par \par Security issues resulting from this draft will be discussed in\par greater depth at a later point. It is recommended in [RFC3036]\par that LDP authentication methods be applied. This would prevent\par unauthorized participation by a PE in a VPLS. Traffic separation\par for a VPLS is effected by using VC labels. However, for\par additional levels of security, the customer MAY deploy end-to-end\par security, which is out of the scope of this draft.\par \par \par 7. Compliance with the PPVN Requirements\par \par The GVPLS solution is compliant with most of the requirements.\par However, the design was chosen in order to allow large deployments\par of VPNs, while maintaining the PE performance and security\par constant.\par \par \par \par Radoaca, et. al Expires: March 2004 [Page 14]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par 8. References\par \par [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet\par Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-\par 01.txt, Work in progress, November 2003-03-02\par \par [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-\par pwe3-control-protocol-02.txt, Work in progress, February 2003\par \par [802.1D-REV] 802.1D - "Information technology - Telecommunications\par and information exchange between systems - Local and metropolitan\par area networks - Common specifications - Part 3: Media Access\par Control (MAC) Bridges: Revision. This is a revision of ISO/IEC\par 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates\par P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998\par \par [IEEE802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE\par Standards for Local and Metropolitan Area Networks: Virtual\par Bridged Local Area Networks", July 1998\par \par [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs" draft-ietf-ppvpn-\par rfc2547bis-03.txt\par \par [RFC3036] "LDP Specification", Andersson, et al RFC 3036, January\par 2001\par \par [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)",\par draft-ietf-l2vpn-vpn-requirements-01.txt, Work in progress,\par October 2002\par \par [VPLS] Lasserre, M. et al., " Virtual Private LAN Services over\par MPLS", draft-ietf-l2vpn-vpls-ldp-00.txt, work in progress,\par March 2004.\par \par [LPE] Ould-Brahim, H., et al., "VPLS/LPE L2VPNS: Virtual Private\par LAN Service using logical PE architecture", draft-ouldbrahim-\par l2vpn-lpe-02.txt, work in progress, March 2002\par \par [L2-FRW] L2 PPVN framework, draft-ietf-ppvn-l2-framework-03.txt,\par work in progress, August 2003\par \par [ROSEN-LDP] Eric Rosen "LDP-based signaling for L2VPNs", draft-\par rosen-l2vpn-l2-sign-03.txt, work in progress, November 2003\par \par [VPLS-COMP] Michael Chen, Mohan Dinesh, Vasile Radoaca "VPLS\par solutions: Commonalities and Differences", work in progress,\par draft-chen-ppvn-dvpls-compare-04.txt, February 2003\par \par \par 9. Acknowledgments\par \par \par Radoaca, et. al Expires: March 2004 [Page 15]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par The GVPLS solution came out with the help, generous ideas, and\par efforts from a lot of people. We would like to recognize the\par involvement of Mirza Arifovic, and Hesahm Elbakouri in drafting\par the solution. We would also like to acknowledge Hamid Ould-Brahim,\par Lakkapragada, Shobhan from Nortel Networks, for their\par contributions. In addition we like to thank to Eric Rosen, Ali\par Sajassi from Cisco, Don O'Connor from Fujitsu for their comments\par and participation during this work.\par \par \par 10. Intellectual Property Considerations\par \par Nortel Networks may seek patent or other intellectual property\par protection for some of all of the technologies disclosed in this\par document. If any standards arising from this document are or\par become protected by one or more patents assigned to Nortel\par Networks, Nortel Networks intends to disclose those patents and\par license them on reasonable and non-discriminatory terms.\par \par \par 11. Authors' Addresses\par \par Vasile Radoaca\par Nortel Networks\par 600 Technology Park\par Billerica, MA 01821\par Phone: (781) 856-0590/978-288-6097\par \par Dinesh Mohan\par Nortel Networks\par P O Box 3511 Station C\par Ottawa ON K1Y 4H7 Canada\par Phone: +1 (613) 763 4794\par Email: mohand@nortelnetworks.com\par \par Lakkapragada, Shobhan\par Nortel Networks\par 600 Technology Park\par Billerica, MA 01821\par \par Javier Achirica\par Telefonica Data\par Email: javier.achirica@telefonica-data.com\par \par Pascal Menezes\par Terabeam Networks, Inc.\par 14833 NE 87th St.\par Redmond, WA, USA\par Phone: (206) 686-2001\par Email: Pascal.Menezes@Terabeam.com\par \par Ananth Nagarajan\par \par Radoaca, et. al Expires: March 2004 [Page 16]\par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par Sprint\par 9300 Metcalf Ave,\par Overland Park, KS 66212, USA\par ananth.nagarajan@mail.sprint.com\par \par Himanshu Shah\par Tenor Networks\par 100 Nagog Park\par Email : hshah@tenornetworks.com\par \par Yaron Raz\par Atrica\par Email : yaron_raz@atrica.com\par \par Andrew G. Malis\par Vivace Networks, Inc.\par 2730 Orchard Parkway\par San Jose, CA 95134\par Andy.Malis@vivacenetworks.com\par \par Simon Hunt\par 186k\par Simon.Hunt@186k.co.uk\par \par Muneyoshi Suzuki\par NTT Information Sharing Platform Labs.\par 3-9-11, Midori-cho,\par Musashino-shi, Tokyo 180-8585, Japan\par Email: suzuki.muneyoshi@lab.ntt.co.jp\par \par Alain Vedrenne\par Equant, Customer Service & Network\par Strategic Technology Planning\par Heraklion; 1041 route des Dolines; BP347\par 06906 Sophia Antipolis; Cedex; France\par Phone: +33-(0)4-92-96-57-22 (7-223-5722)\par \par \par 12. Full Copyright Statement\par \par Copyright (C) The Internet Society (2001). All Rights Reserved.\par This document and translations of it may be copied and furnished\par to others, and derivative works that comment on or otherwise\par explain it or assist in its implementation may be prepared,\par copied, published and distributed, in whole or in part, without\par restriction of any kind, provided that the above copyright notice\par and this paragraph are included on all such copies and derivative\par works. However, this document itself may not be modified in any\par way, such as by removing the copyright notice or references to the\par Internet Society or other Internet organizations, except as needed\par for the purpose of developing Internet standards in which case the\par procedures for copyrights defined in the Internet Standards\par \par Radoaca, et. al Expires: March 2004 [Page 17] \par Internet Draft draft-radoaca-l2vpn-gvpls-03.txt November 2003\par \par process must be followed, or as required to translate it into\par languages other than English.\par \par The limited permissions granted above are perpetual and will not\par be revoked by the Internet Society or its successors or assigns.\par This document and the information contained herein is provided on\par an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET\par ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR\par IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\par THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\par WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\par \par \par }