Provider Provisioned VPN WG Vasile Radoaca Internet Draft: Dinesh Mohan draft-radoaca-ppvpn-gvpls-00.txt Nortel Networks Expiration Date: April 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 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-00.txt Oct 2002 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 [LPE] framework, and [DTLS] solution present a distributed model and [HVPLS] solution presents a non-distributed model, it is recognized that both models may need to co-exist in the same 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 addresses such issues. 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-martini-l2circuit- trans-mpls-10.txt http://search.ietf.org/internet-drafts/draft-martini-l2circuit- encap-mpls-02.txt http://search.ietf.org/internet-drafts/draft-martini-ethernet-encap- mpls-01.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-02.txt http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-l2- framework-01.txt http://search.ietf.org/internet-drafts/draft-rosen-ppvpn-l2- Radoaca, et. al Expires: April 2003 [Page 2] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 signaling-02.txt 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 implemented. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................2 3. Conventions Used................................................2 4. Introduction....................................................4 4.1 Design Objectives..............................................5 4.2 Requirements overview..........................................6 4.3 Terminology....................................................7 5. Topology........................................................8 5.1 GVPLS Network Reference Model..................................8 5.2 Description....................................................9 5.3 Two topologies.................................................9 6. Control Plane..................................................10 6.1 LDP Sessions..................................................11 6.2 GVPLS Entities for the Control Plane..........................11 6.2.1 Source Control Flag (src-cflag).............................11 6.2.2 VC-Label, VC-LSP, Multicast VC-LSP, and EndPoint (EP).......12 6.2.2.1 VC-Label..................................................12 6.2.2.2 VC-LSP and EP.............................................13 6.2.2.3 Multicast VC-LSP..........................................13 6.2.3 End to End Virtual Circuit and CW optimization..............13 6.2.4 Virtual Switch instances (VSI)..............................14 6.3 Auto-discovery................................................15 6.3.1 Topology....................................................15 6.3.2 VPLS provisioning...........................................16 6.3.3 Auto-discovery of the VEPs..................................16 Radoaca, et. al Expires: April 2003 [Page 3] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 6.3.4 Auto-discovery with Control Word............................16 6.4 Signaling.....................................................17 6.4.1 Procedure...................................................17 6.4.2 VEP Provisioning and Signalling.............................18 6.4.3 VFEC Element................................................19 6.4.3.1 VFEC Extensions for the LDP sessions between U-PE and N-PE devices...........................................................21 6.5 Differences between GVPLS model and [ROSEN] draft.............21 7. Data Plane.....................................................21 7.1 Encapsulation.................................................21 7.2 Forwarding....................................................22 7.3 Unknown/multicast packets.....................................23 7.4 OAM Mechanism.................................................23 8. Deployment Scenarios...........................................23 8.1 The DPE Topology - MAC Learning only in the U-PE/VSI-u........23 8.2 The HPE Topology..............................................24 8.2.1 Packet forwarding...........................................24 8.2.2 Known Packet address........................................25 8.2.3 Un-known Packet address.....................................25 9. Interoperability between GVPLS and HVPLS solutions.............25 10. BGP Based Signalling..........................................26 11. Security Considerations.......................................28 12. References....................................................28 12.1 Normative References.........................................28 12.2 Informative References.......................................28 13. Acknowledgments...............................................29 14. Intellectual Property Considerations..........................29 15. Authors' Addresses............................................30 16. Full Copyright Statement......................................31 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. Following the Reference Model for VPLS in [L2-FRW], and [LPE] the GVPLS solution supports both distributed and non-distributed models. It may be classified as a distributed type solution, when the PE functionality is distributed between the user facing U-PE devices (called PE-Edge in [LPE]) and network facing N-PE devices (called PE-Core in [LPE]). It may be classified as a non-distributed type solution when the PE functionality is implemented on a single device. Radoaca, et. al Expires: April 2003 [Page 4] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 4.1 Design Objectives There are different VPLS solutions proposed, like [DTLS], [HVPLS], [DNS/L2TP]. Also, there is a new signalling mechanism proposed in [ROSEN] in order to provide signalling mechanisms for both distributed and non-distributed models. Recognizing the diversity of the VPLS solutions and the deployment scenarios of each solution, the GVPLS design objectives are as following: - Support one provisioning model for both distributed and non- distributed models (see section 6.) - Support one signalling mechanism for both distributed and non- distributed models; this signalling mechanism can be based on LDP or BGP protocols; other protocols are for further study. (See section 6.) - Support different tunnel mechanisms in the VPLS core, like Martini [MARTINI-ENCAP], GRE/IP, etc. L2TP mechanism is for further study. - Support optimization for the multicast and broadcasting traffic. Optimization is characterized in terms of the replication behaviour. In a distributed model, the multicast packet is sent only once between U-PE device and N-PE device. In the VPLS core, the multicast packet is replicated only to those N-PE devices that are part of a given VPLS. (See section 7.) - Allow different mechanisms for providing source learning, based on the VC-Label semantic or use of optional Control word in [MARTINI- ENCAP]. Besides supporting VC-Label semantic, which is similar to [DTLS] and [HVPLS], GVPLS provides the Control Word semantics. Other mechanisms may also be allowed, e.g. VLAN, Q-in-Q tag. (see section 6.2.1) - Enable optimization and scalability by allowing use of optional Control Word. We believe that by using the Control Word, the following benefits can be added to the VPLS solution: - Provides optimization for learning and distributing of the VPN Member information (A VPN Member is a U-PE or N-PE port, where a given VPLS is provisioned), and the network devices (see section 6.2). Adding and removing VPN Member is not related with the apriori knowledge of the other VPN Members - Scalability by reducing the number of VC-LSPs and VC-Labels by an order of magnitude; this allows to increase the number of VPLS instances in the order of 10,000. - Allows single stage signaling and auto-discovery of VPLS Membership. The LDP Mapping Message is used, for both LSPs setup and auto-discovery of the VPLS Members. This eliminates Radoaca, et. al Expires: April 2003 [Page 5] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 a multistage approach, like in [DTLS] or [HVPLS] where the provisioning/ auto-discovery and setup LSPs are distinct steps. - Allows setting a simple mechanism for OAM continuity checking of VC-LSPs, between VPN Members - Allows to use Multipoint to Point Pseudowires for distributing the unicast and multicast traffic - Supports interoperability with [HVPLS] solution within the same SP. Interoperability with [DTLS] solution is for further study (see section 5.2) - Supports deployments of both distributed and non-distributed models within the same SP Without Control Word option, the GVPLS solution uses the VC-Label semantic as in [DTLS] or [HVPLS] solutions. However, even in this case, GVPLS provides the mechanisms to unify both distributed and non-distributed models (see section 6.). This approach is similar with [ROSEN] approach (see section 6.5). Further details about the commonalities and differences between different VPLS solutions are provided in [VPLS-COMP] draft. 4.2 Requirements overview The VPLS requirements are described in [VPLS-REQ]. The VPLS Reference Model is described in [L2-FRW]. In addition [SBC-MEF-VPLS-Requirements] states a set of requirements for a scalable VPLS architecture. Some of these requirements are: - VPLS Architecture should be distributed between customer facing devices and network facing devices; such devices should provide PE functionality - MAC learning should occur in the Customer facing device, no duplicate MAC learning should occur in Network facing device - No fully meshed targeted LDP sessions should be required among Customer Facing devices [A single LDP session between Customer facing and Network facing devices] - Ease of Manageability and Configurations [No need for tracking customer VLANs] - Ease of troubleshooting Radoaca, et. al Expires: April 2003 [Page 6] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 - Support a minimal protocol stack in the Customer Facing Devices (e.g. no OSPF-TE, no RSVP-TE) 4.3 Terminology The GVPLS terminology is based on the [L2-FRW]. GVPLS uses the following terminology to explain the model used. PE û Provide 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 [MARTINI-ENCAP] 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 or GRE tunnels. Device IDs In GVPLS, the following device ids are defined: - N-PE-id, which identifies a N-PE device - U-PE-id, which identified a U-PE device A device ID should be unique in the SP, and is represented as 16 bits value. 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, 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 Radoaca, et. al Expires: April 2003 [Page 7] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 VEP-ID is known DST-ID. The VEP-ID is used to calculate the splice VC-LSPs between U-PE and N-PE devices. VPN-ID A SP refers to a given VPLS by a VPN-ID [32 bits id û reference to be added for Standard VPN-ID]. Such VPN-ID should be unique in the SP context. The alignment of the VPN-ID with [ROSEN] recommendation is for further study. Source Control Flag (src-cflag) It identifies the encoding mechanism for the originating VEP. The VC-Labels calculation and the MAC source learning process are dependent on this flag (see section 6.1.1). Switched Ethernet Transport (SET) The SET is considered to be the access topology when the traffic between U-PEs can be switched without the involvement of the N-PEs. The only requirements for the SET data plane are the encapsulation should encode SRC-ID, DST-ID, and the VPN-ID. One mechanism that can be used is MAC-in-MAC encapsulation. 5. Topology This section describes the GVPLS Network Reference model, the network devices and the relationship between them. The GVPLS model follows the [L2-FRW] reference model, notation and concepts. 5.1 GVPLS Network Reference Model The GVPLS Network Reference Model as shown in Figure 1, identifies different devices that constitute a GVPLS network. | | | +----+ | | /| P | | | / +----+\ | -----------------------|-----/ \ | | | /| \ | +----+ | +---------+ | / | \ | | CE |-|--| U-PE |\ | / | \ | +----+ | +---------+ \ | / | \| +----+ | \ +---------+| +-------+ +-| CE | +----+ | +---------+ \| || | | / +----+ | CE |-|--| U-PE |----| N-PE || | N-PE |< +----+ | +---------+ /| || | | \ +----+ | / +---------+| +-------+ +-| CE | +----+ | +---------+ / | \ | / | +----+ | CE |-|--| U-PE |/ | \| / | +----+ |/ +---------+ | \ +---+ +---+ | / | |\| P |--| P | | +----+/|----------------------|------ +---+ +---+ | | CE | Distributed model | |Non-distributed Radoaca, et. al Expires: April 2003 [Page 8] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 | | | | model +----+ | CORE NETWORK | Figure 1: The GVPLS Network Reference Model 5.2 Description In the core network (VPLS Core), the N-PE devices are connected via tunnels, which can be implemented via MPLS, IP, etc. A U-PE can be connected to the N-PE directly e.g. Point to Point, via layer-aggregation network, or SET, in single-homing or dual- homing configurations. The constituent devices are described below: Customer Edge (CE) Device Customer site device is typically owned and operated by a customer desiring VPN service from the SP. The CE can be a Layer 2 Ethernet Switch, L2/3 Routing Switch, L3 Router, or a directly connected host or server. 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 U-PE Device A U-PE is a device that is owned and operated by the SP, capable to support MAC learning and forwarding functions described in [L2-FRW]. There are two types of U-PE devices: U-PE-s and U-PE-rs (the differences are explained in section 5.3). N-PE Device A N-PE is L2/L3 Switch owned and operated by SP, capable to support VPLS functions described in [L2-FRW], for the distributed model. When the access network is deployed without the U-PE, N-PE also needs to support the U-PE functionality, i.e. the MAC bridging/learning functions. Provider (P) Device P is owned and operated by the SP. It is VPLS service unaware. It simply supports transport tunnels in the SP core network. 5.3 Two topologies Following [LPE] and [L2-FRW], regardless of the signalling and auto- discovery protocols, two paradigms can be identified for the VPLS solutions: Radoaca, et. al Expires: April 2003 [Page 9] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 - Non-distributed model û the MAC learning and forwarding is done in a PE. This can be enhanced by attaching U-PE-s devices to the N-PE devices - Distributed model û the MAC learning and forwarding is distributed in the access network, between different network devices. It is recognized that SP may deploy the non-distributed model and/or the distributed model, based on different vendorsÆ solutions and scalability requirements (scalability, in terms of number of VPNs, number of sites per VPN, number of PE in the metro, and number of ports per PE). For example, the non-distributed model may be needed in those network spots, where scalability is not a primary requirement. A U-PE can be of two types: - U-PE-s - It is a Layer-2 bridge/switch, that can learn and forward the customer packets only to the next hop, which may be the N-PE or any other Layer-2 device if it is not direct connected to the N-PE. - U-PE-rs û It is a Layer-2 switch that is capable to learn and forward the customer packets to remote VEPs. Both devices provide the following functionality: - Customer separation û VPLSs are provisioned on the U-PE device [the provisioning can be done directly to the U-PE device, or indirectly via the N-PE device]. Different techniques can be used for customer separation: o Martini Encapsulation [MARTINI-SIG] o SET o VLAN Translation [801.2Q] o Q-in-Q TAG Encapsulation - QoS, allowing Policing and Shaping of the customer traffic [this topic is not part of this draft]. In addition the U-PE-rs devices provides VPLS forwarding û U-PE-rs may maintain multiple VC-LSPs to N-PEs, in order to learn and forward the customer traffic to the far end VPLS End-points. Following the above definitions, two fundamental access topologies, DPE (Distributed PE) and HPE (Hierarchical PE), can be integrated by GVPLS as described below: - A DPE topology provides distribution of functions between the U- PE-rs and the N-PE devices, based on [LPE]. In [L2-FRW] terms, the DPE topology distributes the MAC learning and forwarding to the U- PE, and the VPN Membership auto-discovery to the N-PE. - A HPE topology provides VPLS functions on the N-PE device. The N- PE can be extended using the U-PE-s devices. 6. Control Plane Radoaca, et. al Expires: April 2003 [Page 10] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The following section describes the GVPLS model, provisioning, discovery, signaling mechanisms and procedures. Such procedures are described for DPE topology; however, they will work in same way for the HPE topology (see 8.2) 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, VEP, VLAN(s) and other attributes (like QoS) define the VPN Member information. The VPLS Member provisioning is transparent to the DPE or HPE models. There are two ways to provision a VPLS Member: - Provision the U-PE devices with VPN membership and signal such information to the N-PEs - Provision the N-PE devices with VPN membership and signal such information to the U-PE devices (in this document we use the second option) Learning and distribution of relevant VPN membership information between U-PE and N-PE devices is achieved through LDP DU (see section 6.4.3.1). However, other protocols are for further study. Learning and distribution of relevant VPN membership information between the N-PEs is achieved through LDP, DNS, or BGP mechanisms. The signalling of the VC-LSPs can be done using LDP or BGP. The following sections describe the signalling method using LDP; the section 10 describes the signalling with the BGP. 6.1 LDP Sessions In GVPLS, the U-PE has one control connection per N-PE device, regardless the number of VPLS provisioned. When the U-PE is connected via dual homing, two LDP sessions exist between this U-PE and the two hosts 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. 6.2 GVPLS Entities for the Control Plane 6.2.1 Source Control Flag (src-cflag) 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. Radoaca, et. al Expires: April 2003 [Page 11] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The following values are possible to indicate the source: - VC-LABEL case: in this case the VC-Label denotes VPN-ID, SRC-ID, and DST-ID - Control Word (CW): in this case, a VC-Label denotes only the VPN- ID and DST-ID. The SRC-ID is encoded in the CW [see section 7.1] - Q-in-Q Tag: in this case the tagged Ethernet frame contains the second QTAG with the value of SRC-ID and VPN-ID [this topic is for further study] - SET: in this case the SET encapsulation should indicate the SRC- ID, VPN-ID, and DST-ID. - In the DPE model, the src-cflag can be used between U-PE and N-PE devices in the local access network or between N-PE devices in the VPLS Core network. The following describes src-cflag conditions: The CW can be used in the core and between U-PE and N-PE devices, should Martini type encapsulation is used. The CW can be used to reduce significantly the number of VC-LSPs, which allows the number of VPLSs to be increased by an order of magnitude in the core. - The VC-LABEL can be used in the core and local access network - The Q-in-Q tag can be used only in the local access network - The SET can be used only in the local access network. 6.2.2 VC-Label, VC-LSP, Multicast VC-LSP, and EndPoint (EP) 6.2.2.1 VC-Label [MARTINI-ENCAP] 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 GVPLS Signaling is based on [MARTINI-SIG] and encapsulation based on [MARTINI-ENCAP]. In [MARTINI-SIG] the VC-Label bindings are distributed using the LDP DU protocol. However, in order to support VPLS, some extensions are added to Martini scheme. In GVPLS, the VC-Label is overloaded with a new semantic. As such, from the VC-Label the followings can be inferred: - VPN-ID - DST-ID VEP - SRC-ID VEP Radoaca, et. al Expires: April 2003 [Page 12] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 6.2.2.2 VC-LSP and EP The VC-Labels are used to build LSP (VC-LSP) between two devices. A VC-LSP between two devices (ex. dev-2 -> dev-1) is identified by two EPs. Each EP has the following information: - device-id - VEP-id (VEP, from where the vpls traffic originates or it is targeting) - VPN-ID A VC-LSP between U-PE device and N-PE device is known as Ext-LSP, and a VC-LSP between N-PE devices is known as Vpls-LSP. LetÆs considers two EPs, EP1 on the device dev-1, and EP2 on the device dev-2. An LSP between dev-1, and dev-2 (dev-2-> dev-1) is identified by t-uplu <, > or by expanding the EP values, as the t-uplu <, >. Note: If dev-1.src-cflag is Control Word then EP2.VEP-id can have the same value as dev-2id. In other words, the EP2 is identified with device dev-2. 6.2.2.3 Multicast VC-LSP The Multicast traffic is sent using Multicast VC-LSPs. A Multicast VC-LSP is implemented using a Multicast VC-Label, which is generated from a Multicast pool of VC-Labels. A Multicast VC-LSP between U-PE device and N-PE device is known as Ext-mc-LSP, and a VC-LSP between N-PE devices is known as Vpls-mc- LSP. An Ext-mc-LSP between the U-PE device and the N-PE device has the DST-ID value as N-PE-id. A Vpls-mc-LSP between the N-PE-1 and N- PE-2 devices has the DST-ID value as N-PE-id-2. The SRC-ID is indicated in similar way as for the unicast VC-LSPs. The Multicast VC-LSPs are built when the VPLS are provisioned on the N-PE devices (see section 6.3.2) 6.2.3 End to End Virtual Circuit and CW optimization LetÆs have U-PE-l, N-PEl, as local devices, and U-PE-r, and N-PE-r as remote devices. A VPLS is provisioned in U-PE-l and U-PE-r devices, with EP-L and EP-R. The VC, from U-PE-l, to U-PE-r is composed of following VC-LSPs: Ext-LSP1 is a VC-LSP from U-PE-l to N-PE-with EP-L and EP-R EPs. Vpls-LSP2 is a VC-LSP from N-PE-l to N-PE-r EP-L and EP-R EPs. Radoaca, et. al Expires: April 2003 [Page 13] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 Ext-LSP3 is a VC-LSP from N-PE-r to U-PE-r with EP-L and EP-R EPs. Similar LSPs are defined in a reverse path from U-PE-r to U-PE-l. The Control Word can be used to optimize the number of VC-LSPs. LetÆs suppose a network with ôkö N-PE devices each with ônö EPs all belong to the same VPLS instance. The total number of EPs for this particular VPLS instance is n*k. In a model without Control Word the number of VC-LSPs in the core is n*k*(n*k -1). In a model with Control Word the number of VC-LPSs in the core is n*k*(k-1). For example if n = 10 and k = 5 (an average 50 EPs per VPLS instance), then the number of VC-LPS without CW is 50*(50-1) = 2450. With CW, the number of VC-LSPs is 50*4 = 200. The ratio is about 10 times. If the number of EPs per VPLS is 100 then ratio is 9900/80 that is about 100 times. The same scaling issue appear if we calculate the number of VC-LSPs in the access network. If we need to support 1000 VPLS instances then, using the above data, the number of VC-LSPs without CW is about 2,450,000. From this data, it is evident that CW, if used, can bring really a good optimisation in terms of number of VC-LPSs. 6.2.4 Virtual Switch instances (VSI) This section makes the connection between VSI, VC-LSP and Pseudowire concepts [L2-FRW], and [MARTINI-SIG]. [L2-FRW] describes the Virtual Switch Instance (VSI) concept and two types of circuits: - Attachment circuits (AC) between CE devices and U-PE devices - Pseudo wire circuits In GVPLS, the Virtual Switch Instance (VSI) forwarder is decomposed into VSI-u and VSI-n forwarders. The VSI-u and VSI-n can be mapped into different devices or can be part of the same device [non- distributed VPLS case]. The VSI-u maps multiple Attachment circuits to multiple Ext-LSPs, and VSI-n maps multiple Ext-LSPs to multiple VPLS-LSPs. The VSI-u forwarding conditions are based on: - Source MAC learning against a given circuit - Bridging to the Attachment circuits - Port, VLAN and P-Bits information [802.1 QTAG] Radoaca, et. al Expires: April 2003 [Page 14] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The VSI-u forwarding decision maps a MAC DA, VLAN and incoming port to an Ext-LSP. The VSI-n forwarding conditions are based on: - Port - Incoming VC-LSP (DST ID VEP) - Outgoing VC-LSP (DST ID VEP) Using the above notations, there are two types of Pseudo-wires (PW) that can be built with the VC-LSP: - Point-to-Point (P2P-PW), when the Control Word is not used - Multi Point to Point (M2P-PW), when the Control Word is used A Multipoint to point PW (M2P-PW) is defined by a set of VC-LSPs that originate from Source EPs and terminate in one destination EP. The P2P-PW is defined in [L2-FRW]. 6.3 Auto-discovery This section describes how an N-PE is configured for VPLS and how it operates, i.e. how members are auto-discovered. 6.3.1 Topology At a given N-PE, there are ônö U-PE devices that are attached to the N-PE device. The N-PE can be provisioned or can discover the attached U-PE devices. In the following sections we use the terms ôlocalö and ôremoteö N-PE and U-PE devices. A local N-PE device is a device where the provisioning is happen û all the other devices are called remotely relative to the local N-PE device. There are two distinct topologies to be handled: - N-PE access topology û between N-PE device and its U-PE devices - N-PE core topology û between N-PE devices in the core Both topologies can be provisioned or auto-discovered. Local topology The N-PE local topology can be auto-discovered using the LDP auto- discovery mechanism, if the U-PEs are direct connected. Other protocols may be used û this issue is for further work. As a result of configuration/auto-discovery process, the N-PE device will be given a list of U-PE devices that are attached to it. Also, each local U-PE device will be given a list of N-PE devices that are attached to it [e.g. in dual-homing scenarios]. Core topology Radoaca, et. al Expires: April 2003 [Page 15] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The N-PE core topology can be auto-discovered using the BGP protocol û this issue will be addressed in a different draft. As a result of configuration/auto-discovery process, the N-PE device will be given a list of remote N-PE devices, and for each remote N- PE device a list of U-PE devices that are attached to that remote N- PE device. 6.3.2 VPLS provisioning Each VPLS is provisioned per N-PE, with the following attributes: - VPN-ID - QoS attributes Upon receiving the provisioning request, the N-PE will do the following actions: - A VSI-n instance is created; - A VPN member-set is initialised - In the VPLS Core, a VPLS-mc-LSP is created between N-PE device and each remote N-PE - An Ext-mc-LSP is created between N-PE and each attached U-PE devices. Upon receiving the provisioning request, each local U-PE will do the following actions: - A VSI-u is created for that VPN - An Ext-mc-LSP is created between the U-PE device and the attached N-PE devices. As a result of the provisioning scheme, a Multicast Tree of LSPs is built between U-PE and N-PE devices. In a given VPLS, the unknown or multicast packet would be replicated only once between the originating U-PE device and the N-PE devices where is attached. From these N-PE devices the packet would be replicated only to those remote N-PE devices that are part of a given VPLS. Furthermore, from the remote N-PE devices, the packet is replicated only to those U-PE devices that are part of a given VPLS. 6.3.3 Auto-discovery of the VEPs The VEPs can be provisioned, or auto-discovered. The auto-discovery process can be done using BGP or LDP protocol. This work is for further study. 6.3.4 Auto-discovery with Control Word For learning and distribution of the VPN Membership, it is worthwhile to note the case when the SRC-ID of the packet is indicated on the data plane, using the CW. Radoaca, et. al Expires: April 2003 [Page 16] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 Adding [or removing] a VP [or VPN Member], on a given N-PE, can be done without knowledge of the other VPs [VPN Members] on a given VPLS. The only knowledge needed is related to the remote N-PE devices. When a new VP is added to a given VPLS/VPN-ID, the following values are relevant: - VEP - The VC-Label associated to the VEP - The remote N-PE devices Using this information, the M2P LSPs can be built in the VPLS core, using the LDP DU mechanism (the remote VEPs are not needed for this setup). Based on the above observation, the same LDP Mapping Message can be used to: - Learn and distribute the VEP information to the remote N-PE and U- PE devices. - Create the VC-LSP 6.4 Signaling This section describes the LDP signaling method. Section 10 describes the BGP signaling method. In [MARTINI-SIG] the LDP Label Mapping Message is used to signal the VC-Label and to create a new VC-LSP. GVPLS proposes to extend the Martini VFEC in order to implement VPLS. 6.4.1 Procedure LetÆs considers two devices, dev-1, and dev-2. A VC-LSP between these two devices (e.q. dev-2 -> dev-1) is identified by two EPs. Each EP has the following information: - dev-id - VEP-id (VEP, from where the vpls traffic originates or it is targeting) - VPN-ID LetÆs have two EPs, EP1 on the device dev-1, and EP2 on the device dev-2. In our example, an LSP between dev-1, and dev-2 (dev-2-> dev-1) is identified by <, > or by expanding the EP values, as the tuple <, >. Operations on the device dev-1 Radoaca, et. al Expires: April 2003 [Page 17] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The dev-1 initiates a signalling procedure in order to setup the LSP from dev-2 to dev-1 (dev-2 -> dev-1). Step 1 If the dev-1.src-cflg is VC_LABEL then { - a new VC-Label is generated - The VC-Label is associated with EP1, and EP2 - Type-of-circuit = P2P } else { - If a VC-Label is associated with the EP1 then re-use this label, otherwise generate a new VC-Label. - The VC-Label is associated with EP1. - Type-of-circuit = M2P } Step 2 The LDP Mapping Message is formed with the VC-Label and the information attached in the VFEC, and sent to the dev-2. The VFEC includes EP1, EP2, and type-of-circuit. Operations on the device dev-2 The dev-2 will map the VPN-ID to the corresponding VSI. If the dev-2 accepts the Label Mapping message, then it has to make check if the type-of-circuit is P2P. If yes { then it has to check if an LSP is setup in the opposite direction (dev-1. dev-2). If no such LSP exists then it will initiate a new setup LSP, using the same algorithm described above. } 6.4.2 VEP Provisioning and Signalling A VPLS Member is created by provisioning a VPN-ID in a specific VPLS Port [U-PE access port/logical interface or N-PE access port/logical interface]. The following rules should apply for Ext-LSPs: A given N-PE, requests for each possible remote destination (DST-ID) an ext-lsp (oriented from U-PE to N-PE) from all the U-PE devices attached to it. A given U-PE, requests for each possible remote destination (DST-ID) an ext-lsp (oriented from N-PE to U-PE) from all N-PE devices attached to it. LetÆs suppose the EPs are provisioned/auto-discovered to all the N- PE and U-PE devices. LetÆs take an EP, EP-X, on the local U-PE device and evaluates the operations on each device Radoaca, et. al Expires: April 2003 [Page 18] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The EP-x is learned on the local N-PE, the remote N-PE and remote U- PE devices. The local N-PE Actions: - In the VPLS core for each remote EP, a VC-LSP is created with the direction from the remote EndPoint to the EP-X - In the local N-PE topology for each remote EP (or local EP different from EP-x) a VC-LSP is created with the direction from the local EP-X/local U-PE. As a result of these actions, a set of LSPs is created to reach the VEPs from the core and from the local access network [U-PE devices]. The remote N-PE actions upon receiving a remote Vpls VPN membership: - In the local remote N-PE topology for each local EP, a VC-LSP is created with the direction from the local EP to the EP-X on the remote N-PE The local U-PE actions: - The EP-X is provisioned/auto-discovered on the U-PE - For each N-PE that is connected to the U-PE device a VC-LSP is created with EP-X and the remote EPs The remote U-PE actions upon receiving remote Vpls VPN membership: - for each N-PE that is connected to the U-PE device a VC-LSP is created with EP-X [on N-PE] and local EPs. 6.4.3 VFEC Element In [MARTINI-SIG], the VPLS information is carried in a Label Mapping message sent in downstream-unsolicited mode, which contains a VFEC TLV that is describes below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VFEC_TLV |C| VC-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameters ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | *** | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Radoaca, et. al Expires: April 2003 [Page 19] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 VFEC-TLV Specific formatting of Type/Length Variable structure that supports VPLS Service C-bit The Control bit ôCö is set to one, which means that an ATTRpw label will be part of this VC. VC-Type The VC-type as described in the [MARTINI-Trans]. Group ID An arbitrary 32-bit value that represents a group of VPLS End-points on a particular PE. The Group ID is used for, among other things, sending wild card label withdrawals to remote PE upon physical port failure. The Group-ID is locally significant and is used in the Withdraw Message. VPN-ID Identifies the VPN-ID associated with a specific VPLS. Interface parameters Parameter IDs that are forwarded in the VFEC are defined as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ParameterID Length Description 0x06 4 EP.VEP-ID (source) 0x07 4 EP.VEP-ID (destination) 0x08 4 Replication attribute 0x10 4 VPN-ID 0x11 4 src-cflag 0x12 4 type-of-circuit 0x13 variable VP 0x14 4 QoS Attribute The Replication attribute indicates the replication capability of the N-PE and U-PE devices. For example the N-PE device can replicate a packet on each outgoing VPLS-LSP, when the packet is sent to the VPLS core, or on each outgoing VC-LSP, when the packet is sent from the VPLS core to the local access. Radoaca, et. al Expires: April 2003 [Page 20] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 6.4.3.1 VFEC Extensions for the LDP sessions between U-PE and N-PE devices When LDP is used between the U-PE and N-PE devices then additional attributes can be used. The VP parameter has the length variable. Each VP is encoded as 16 bits value. The type of the message is encoded as 16 bits value and can have the following values: - Add VPs with VPN-ID - Enable VPs with VPN-ID (the U-PE VP are enabled to send/receive traffic) - Remove VPs with VPN-ID - Disable VPs with VPN-ID - Enable Multicast VPs with VPN-ID - Disable Multicast VPs with VPN-ID 6.5 Differences between GVPLS model and [ROSEN] draft In [ROSEN] draft a new scheme is developed for PW and VPLS. Both [ROSEN] and GVPLS scheme are pretty much the same for VPLS without Control Word. However, in order to accommodate the CW option, [ROSEN] scheme needs to be changed adequately. The [ROSEN] notation can be used very well to explain the GVPLS solution. The Attachment Identifier is similar with the EP in GVPLS. The AII value can be U-PE-id, or N-PE-id. In [ROSEN] scheme the PWs are used to set the paths between VPLS EPs. In order to accommodate CW, GVPLS uses the VC-LSPs to describe the paths between VEPs. This gives the possibility to create optimized paths between the VEP, in a multipoint to point configuration. [ROSEN] signalling scheme (see 5.5.1) is also different from GVPLS. The GVPLS signalling scheme re-use the [MARTINI-SIG] VFEC format with some extensions to allow carrying the VPN Membership information. 7. Data Plane 7.1 Encapsulation GVPLS proposes VC to be based on [MARTINI-ENCAP]. However, others encapsulation types may be used as well. The Control Word (CW) option can be signalled during the LDP Label advertising. If an N-PE/U-PE does not support the CW, it can return a standard error code defined in [LDP]. If the CW is used, it must represent the SRC-ID of the customer packet, in a given VPLS with the following format. Radoaca, et. al Expires: April 2003 [Page 21] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Flags |C | SRC-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above diagram the first 4 bits are reserved for future use. They MUST be set to 0 when transmitting, and MUST be ignored upon receipt. The next 4 bits provide space for carrying protocol specific flags. These are defined in the protocol-specific details below. The next 2 bits provide the following: - C û if set represents a continuity check for the VPN The last 16 bits provide the SRC-ID indication. 7.2 Forwarding We assume that for each VPLS provisioned, the followings are created: - A set of VPLS-LSPs in the core - A set of Ext-LSPs between U-PE/N-PE devices, and between N-PE/U-PE devices The U-PE device is capable to do MAC learning and forwarding as following. When a packet is coming in a specific Ext-LSP, it learns the Source SRC-ID and the source MAC address. Based on the matching of the DST ID attribute of an outgoing Ext-LSP, with the learned SRC-ID from the incoming Ext-LSP, the Source MAC address is attached to the outgoing Ext-LSP. In order to forward the customer traffic to the remote VEPs, a VSI-u learns the sources and destinations MAC addresses, for each Ext-LSP as explained above. On an N-PE, a customer traffic that is coming into N-PE is forwarded to the VSI-n, where the switching between the Ext-LSP and the Vpls-LSP is performed. In the same way a customer traffic that is coming into Vsi-n from the VPLS backbone, is forwarded to the corresponding Ext-LSP attached to that VSI. The selection of the outgoing LSP is based on matching of the incoming LSP DST-ID with the outgoing DST-ID of the LSP. During the forwarding process, the VC-Label indicates the DST-ID of the U-PE device. Radoaca, et. al Expires: April 2003 [Page 22] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 7.3 Unknown/multicast packets For unknown unicast packets or multicast packets, a VPLS Multicast VC-LSP is used in order to indicate to the N-PE or U-PE how to replicate the customer packets, in a given VPLS scope. The required replication can be done as following: - The U-PE sends a customer packet, using Ext-mc-lsp to the Local N- PE - The local N-PE replicates the customer packet, using the VPLS-mc- lsp, that belong to the given VPLS scope - The remote N-PE replicates the customer packet to all attached U- PEs that are in the same VPLS - Each remote U-PE replicates the customer packet to all the VEPs in the same VPLS A replication attribute may be related with the U-PE and N-PE. This attribute, if present should indicate if the device is capable to replicate a packet or not. The Source of the packet (SRC-ID) is encoded using the CW or the VC- Multicast label. 7.4 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 stimulate 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 cleared. The OAM without Control Word is for further study. 8. Deployment Scenarios In the same network DPE and HPE topologies may be deployed and inter-work together. This allows a SP to scale a network in incremental way, and to allow different types of U-PE devices to be deployed in different access networks in a transparent manner. The Control Word option can be turn on if all the devices support this option. This would be signaled via LDP or BGP. 8.1 The DPE Topology - MAC Learning only in the U-PE/VSI-u The DPE topology uses U-PE-rs that is VPLS aware, and is capable of forwarding the customer packets on different Ext-lsp. Radoaca, et. al Expires: April 2003 [Page 23] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The forwarding process is distributed between the U-PE-rs and the N- PE. The N-PE can use the forwarding information received from the U- PE-rs in order to make its forwarding decision. The Extension VC-label, in the N-PE, indicates the DST-ID as the remote U-PE-ID. The Vpls VC-label indicates the DST-ID as the local U-PE-ID. 8.2 The HPE Topology The HPE solution provides MAC learning and forwarding in the N-PE [VSI = VSI-u and VSI-n]. Without U-PE devices, the VSI-u is part of the N-PE device. In this case the VEPs are provisioned on the N-PE device with the SRC-ID or DST-ID attributes, having the N-PE-ID value. The Ext-LSPs are null. Also, the HPE can be deployed with U-PE-s devices that can be used to extend the Layer 2 aggregation capability. In this case, for each VPLS there are two EPs provisioned for U-PE device and N-PE device. The EP on the N-PE device has the VEP-ID = N-PE-id and the EP on the U-PE device has VEP-ID = U-PE-id. Between these two EPs an Ext-LSP is built, using the alg. Described in section 6.3.1. Each VPLS-LSP (between N-PE devices) has the EPs, on the N-PE devices, built as following. Each EP on the N-PE device has the VPLS VEP-ID value equal with the corresponding U-PE-id of the local U-PE device. In this respect a VPLS-LSP would indicate the U-PE device attached to the N-PE device and the U-PE device from where is originating. The following section explains packet forwarding for the HPE with the U-PE device configuration. 8.2.1 Packet forwarding When the customer packet is coming from the U-PE, the VSI is forwarding the packet based on the Customer Destination MAC address. When the customer packet is coming from the VPLS core, the VSI performs label switching between the VPLS-LSP and Ext-LSP. No MAC based forwarding is needed. Based on the above assumptions, the VSI performs the forwarding decision as following: - From the U-PE-s to N-PE based on the MAC Destination address - From the N-PE to the U-PE-s based on the Vpls-LSP indication As we can see, the N-PE VSI learns only the remote MAC address, instead of all MAC addresses that occurs usually in L2 switch. This Radoaca, et. al Expires: April 2003 [Page 24] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 would decrease significantly the number of MAC addresses that need to be learned by the N-PE. 8.2.2 Known Packet address When the packet is coming from the U-PE to the N-PE, the N-PEÆs VSI selects the Vpls-LSP based on the customer packet MAC Address Destination. When the packet is coming from the N-PE to the U-PE, the VSI selects the U-PE based on the DST-ID of the Vpls-LSP. 8.2.3 Un-known Packet address For unknown destinations, the local N-PE replicates the customer packets for all the Vpls-mc-LSPs in a given VPLS Instance. When the multicast packet arrives at remote N-PE, the corresponding VSI would replicate the packet for each Ext-mc-LSP attached to it. When the packets return from a designated destination, the local N- PE learns the MAC Source address of the packet against the Vpls LSP, the remote U-PE-ID based on the SRC-ID indication. 9. Interoperability between GVPLS and HVPLS solutions The HVPLS [HVPLS] topology can be categorized as an HPE topology. In the same network or in the same PE, GVPLS and HVPLS solutions may be deployed and inter-work together. This allows a SP to scale a network in incremental way, and to allow different types of U-PE devices to be deployed in different access networks in a transparent manner. The GVPLS allows inter-working with HVPLS. The basic assumption is that GVPLS and HVPLS would use the same Vpls VC-LSPs full mesh configuration, without Control Word. The HVPLS N-PE sees the VSI as a Virtual Bridge and vice versa. In the data plane, HVPLS donÆt use the CW or SRC-TAG. The Source Indication is generated from the VC-Label. In order to accommodate this, the GVPLS N-PE node will generate for one DST-ID, a set of ôNö remote VC-Labels, based on the algorithm presented in section 6.3.1. LetÆs suppose a GVPLS topology, with ônö U-PE-rs(s), that are VPLS aware. Also, letÆs suppose an HVPLS access network with ômö U-PEs that are Layer 2 aggregation devices. Radoaca, et. al Expires: April 2003 [Page 25] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 In this scenario, the HVPLS would see the GVPLS topology as an ônö set of VBs. Neither is the HVPLS aware that it is talking with a GVPLS topology nor is the GVPLS aware about HVPLS. The behavior would be the same if we replace DPE with HPE topology. 10. BGP Based Signalling BGP version 4 ([BGP]) can also be used as the auto-discovery and signaling protocol for GVPLS. In BGP, the Multi-protocol Extensions [BGP-MP] are used to carry GVPLS signaling information. [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. N-PEs receiving VPN information may filter advertisements based on the extended communities, thus controlling CE-to-CE connectivity. The format of the GVPLS NLRI is as shown in Figure below. One or more such NLRIs can be carried in a single MP_REACH_NLRI or MP_REACH_NLRI attribute. Typically, the NLRI message would be generated upon the Source MAC learning across the N-PE for a U-PE-s model or U-PE for a U-PE-rs model. Figure: BGP NLRI for GVPLS Information +---------------------------------------+ | Length (2 octets) | +---------------------------------------+ | Route Distinguisher (8 octets) | +---------------------------------------+ | VP ID (2 octets) | +---------------------------------------+ | Device-ID (6 octets) | +---------------------------------------+ | VP_SL (3 octets) | +---------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +---------------------------------------+ Where Length describes the length in octets of VPLS address information, Route Distinguisher (RD) carries the VPN-ID, VP-ID identifies the VPLS port which connects to the customer device, Device-Id identifies the device that contains the VP which may be U- PE-ID, VP SL identifies the service label value that should be used for sending traffic towards the VP. Radoaca, et. al Expires: April 2003 [Page 26] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 Besides the obvious fields, Variable TLVs could be defined as [Note: This is just an example, we may want to introduce more fields for resiliency model etc]: +---------------------------------------+ | U-PE_Type Length = 4 | +---------------------------------------+ | U-PE_Type | +---------------------------------------+ | QoS Parameters Length = 4 | +---------------------------------------+ | QoS Param1 (1 Octet) | +---------------------------------------+ | QoS Param2 (1 Octet) | +---------------------------------------+ | QoS Param3 (1 Octet) | +---------------------------------------+ | QoS Param4 (1 Octet) | +---------------------------------------+ Also, a new extended community, GVPLS-Info, is introduced to allow carrying GVPLS specific information in a VPN. This extended community MUST be carried as part of path attribute in all BGP update messages carrying GVPLS NLRIs. Figure: GVPLS-Info Extended Community +------------------------------------+ | Extended community type (2 octets) | +------------------------------------+ | Encaps Type (1 octet) | +------------------------------------+ | Cntrl Flags (1 octet) | +------------------------------------+ | Reserved (2 octets) | +------------------------------------+ Encapsulation Type: Value Encapsulation 12 VPLS Control Flags: This is a bit vector 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |Q|F|C|S| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+ Radoaca, et. al Expires: April 2003 [Page 27] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 The following bits are defined; the MBZ bits MUST be set to zero. C: If set to 1(0); CW label is (not) required when encapsulating Layer 2 frames. S: If set to 1(0), Sequenced delivery of frames is (not) required. The Q and F flags are reserved for other use. 11. 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 security (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. 12. References 12.1 Normative References [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". [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. [802.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". RFC 2547, March 1999 [RFC3036] "LDP Specification", Andersson, et al RFC 3036, January 2001. 12.2 Informative References [MARTINI-ENCAP] "Encapsulation Methods for Transport of Ethernet Frames Over IP and MPLS", draft-martini-ethernet-encap-mpls- 01.txt, Work in progress, April 2002. [MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft- martini-l2circuit-trans-mpls-10.txt, Work in progress, April 2002. Radoaca, et. al Expires: April 2003 [Page 28] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", draft-ietf-ppvpn-vpls-requirements-00.txt Work in progress. [DNS] "DNS/LDP Based VPLS", Juha Heinanen, draft-heinanen- dns-ldp-vpls-00.txt, Work in Progress, January 2002. [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto- 02.txt, Work in Progress, January 2002. [FINN-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging- vpls-00.txt, Work in Progress, June 2002. [DTLS] Kompella, K., et al. "Decoupled Virtual Private LAN Services", draft-kompella-ppvpn-dtls-01.txt, work in progress, November 2001. [HVPLS] Lasserre, M. et al., " Virtual Private LAN Services over MPLS ", draft-lasserre-vkompella-ppvpn-vpls-02.txt, work in progress, June 2002. [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. [SBC-MEF-Vpls-requirements] Serbest Yetick, ôVPLS Requirementsö MEF presentation, April 2002 [L2-FRW] L2 PPVN framework, draft-ietf-ppvn-l2-framework-01.txt, work in progress, September 2002 [ROSEN] Eric Rosen ôLDP-based signaling for L2VPNsö, draft-rosen- ppvpn-l2-sign-02.txt, work in progress, September 2002 [VPLS-COMP] Michael Chen, Mohan Dinesh, Vasile Radoaca ôVPLS solutions: Commonalities and Differencesö, work in progress, February 2003, draft-chen-ppvn-dvpls-compare-04.txt, February 2003 13. 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. 14. Intellectual Property Considerations Radoaca, et. al Expires: April 2003 [Page 29] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 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. 15. 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 Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Andy.Malis@vivacenetworks.com Radoaca, et. al Expires: April 2003 [Page 30] Internet Draft draft-radoaca-ppvpn-gvpls-00.txt Oct 2002 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) 16. 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. Radoaca, et. al Expires: April 2003 [Page 31]