Network Working Group Arnold Sodder Internet Draft Tim Mancour Category: Informational Tenor Networks K.K. Ramakrishnan Charles Kalmanek AT&T Labs Christopher N. DelRegno Scott Kotrla WorldCom Joris Wils Coriolis Networks Document: draft-sodder-ppvpn-vhls-02.txt Expires: October 2003 April 2003 Virtual Hierarchical LAN Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching Sodder Expires - October 2003 [Page 1] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 architecture. The model is based on a MAC-in-MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. Conventions used in this document 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 [ii]. Table of Contents 1. Introduction...................................................2 2. Reference Model................................................3 3. Backbone Network...............................................6 4. QOS............................................................6 5. Frame Processing...............................................7 5.1 CE Frame Processing........................................8 5.2 L2PE Frame Processing......................................8 5.3 L2PE Frame Processing for frames with 802.1Q VLAN Tags....10 5.4 PE Frame Processing.......................................10 5.5 PE Frame Processing for MPLS based backbone networks......11 6. LDP Signaling.................................................12 6.1 PE Discovery..............................................12 6.2 VPN Auto Discovery........................................14 6.3 VC Label Signaling........................................15 Security Considerations..........................................16 References.......................................................16 Acknowledgments..................................................17 Intellectual Property Considerations.............................17 Full Copyright Statement.........................................17 Author's Addresses...............................................18 1. Introduction Service Providers require a low-cost, scalable method of providing ubiquitous data services. They have indicated that Ethernet-based services are the interface of choice to provide this service. The service must be "low-cost" in terms of the cost of operations for the Customer and Provider, and the cost of deployment for the Provider. This document describes a ôVirtual Hierarchical LAN Servicesö model. In this model an Ethernet L2VPN is supported by building a network based on a hierarchical architecture. At the lowest level of Sodder Expires - October 2003 [Page 2] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 hierarchy, customer edge devices (CE) communicate with service provider devices (L2PE) using standard Ethernet frames. This is also the service demark point. The second level of hierarchy is added by the service provider device (L2PE), which encapsulates the customer frame with an additional MAC header. As part of this additional MAC header a VPN identifier is also added to the frame encapsulation. This encapsulated frame can then be forwarded over a backbone network by a provider edge device (PE). In its simplest form the backbone network can be an Ethernet bridge. The backbone network can also be based on an MPLS architecture, made up of a mesh of pseudo wires that connect the set of provider edge devices in a split horizon manner. The pseudo wires can be MPLS tunnels or VC labels as defined in [PWE3-CTRL]. A fully connected mesh of VC's must be established to all PE devices. Per VPN per PE VC establishment over the backbone network is not required. Thus the hierarchical approach provides the following advantage: 1) Many customer MAC addresses are represented by the combination of an L2VPN identifier and a single provider-managed MAC address. This reduces the number of MAC addresses that need to be managed by the core network devices. 2) Simplification of the core network operation by reducing the number of pseudo-wires required for the L2VPN service. The model also describes a broadcast and multicast service that limits the replication of frames in the service providerÆs backbone network. This draft describes extensions to [PWE3-CTRL] to support the setup of the VC mesh between the PE devices. 2. Reference Model The following network diagram shows the elements needed to support the Ethernet-based L2VPN service. The reference model presents three logical functions represented by: Customer Edge (CE) devices, Layer 2 Provider Edge (L2PE) devices and Provider Edge (PE) devices. CE devices belong to a customer while the PE and L2PE devices belong to a service provider. The service provider backbone network can be based on any technology such as Bridging, MPLS, L2TP, GRE, IP in IP etc. The diagram shows customers connected to three L2VPNs represented by x, y and z. CE devices connect to L2PE devices, each of which Sodder Expires - October 2003 [Page 3] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 supports many L2VPNs. L2PE devices connect to PE devices that support connectivity to a backbone network. In the diagram below the Service Provider Backbone Network is demarked by the ". . .". The backbone network must be able to support point-to-point communication at a minimum. Support for point-to-multipoint communication is desirable but not required. Sodder Expires - October 2003 [Page 4] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 +----+ . . . . . . . . . . . . |CEx1|-+ +-----+ . . +----+ +----+ +-| | +-----+ +-----+ +-|CEx4| |L2PEa|-----| | | | +-----+ | +----+ +----+ +-| | +---| PE1 | | PE2 |--| |-+ |CEy1|-+ +-----+ | +-| | | | | | +----+ +----+ | | +-----+ +-----+ |L2PEd|---|CEy2| | | . . | | +----+ | | . . | |-+ | | . . +-----+ | +----+ +----+ +-----+ | | . . +-|CEy3| |CEz1|---|L2PEb|-+ | . . +----+ +----+ +-----+ | . Service . | . Provider . | . Backbone . | . Network . +----+ | . . |CEx2|-+ | . . +----+ | +-----+ | . +-----+ +-| | | . | | +-----+ +----+ +----+ | | | . | PE3 |--|L2PEe|--|CEx5| |CEz2|-+-|L2PEc|---+ . | | +-----+ +----+ +----+ | | . +-----+ +-| | . . +----+ | +-----+ . . . . . . . . . . . . |CEx3|-+ +----+ CE devices could be hosts, Layer 2 switches or Layer 3 routers. The model REQUIRES that the link that connects the CE devices to the L2PE devices carry Ethernet Frames. Frames with and without VLAN tags [IEEE-802.1Q] are supported. A CE device can connect to many L2PE devices, however the L2PE device MUST ensure that only one of these links is active at a time, with the other links in stand-by mode. L2PE devices are Virtual Hierarchical LAN switches. Typically there are many CE devices that connect to a single L2PE device. L2PE devices provide switching and replication services for the CE devices connected to them. All L2PE interfaces MUST support the transport of Ethernet frames. L2PE devices MUST have at least one active interface that connects to the PE device. When more than one interface connects to one or more PE devices, control mechanisms MUST be used to insure that only one is active and all others are in stand-by mode. Sodder Expires - October 2003 [Page 5] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 L2PE devices are assigned a single MAC address. When an L2PE device has two uplinks to different PE devices the same MAC address is used on both links. This allows redundancy to be implemented in a manner that does not require remote ends to know about a failure. PE devices support interfaces that connect to L2PE devices and interfaces that connect to the backbone network. The interfaces that connect to L2PE devices MUST support Ethernet frames. PE devices MUST be able to address each L2PE device that it is connected to using a unique MAC address. L2PE devices MUST be able to address a single PE device. Any network topologies that prevent this are not supported. Both PE and L2PE devices must support basic Ethernet services such as the frame replication of broadcast and multicast addressed frames. In the network reference diagram above, the provider device L2PEc provides frame replication services for customer devices CEx2 and CEx3. The provider device L2PEd provides replication services for customer devices CEy2 and CEy3. All other replication services are provided by PE1, PE2 or PE3. This replication hierarchy minimizes broadcast traffic on the service provider's backbone network. The L2VPN Backbone Network is configured by defining the VPNs that are supported by each PE device. The PE device may use an auto- discover procedure to determine the other PE devices in the backbone network that it must communicate with. One discovery procedure is described later in this draft. 3. Backbone Network The draft describes requirements for an MPLS based backbone network. As earlier mentioned other backbone architectures are also supported and details of these architectures can be developed if needed. 4. QOS It is desirable to offer multi-tiered QOS as part of the L2VPN service. It is especially useful to provide preferential treatment of control frames such as OAM and Spanning Tree Bridge PDUs at each intermediary node as well as within the core network. In some cases a service provider may want an altogether different path to carry certain packets, for example broadcast data. In all such cases, per QOS LSP Tunnels must be signaled. In addition when using VC labels an additional set of pseudo-wires is required to be signaled over the new LSP tunnel. Sodder Expires - October 2003 [Page 6] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 The VHLS architecture offers a more scalable solution than the VPLS architecture when additional pseudo-wires are needed. In VHLS, a PE node may signal a pseudo-wire to carry broadcasts of all VPNs as compared to VPLS where a PE node must signal a separate pseudo-wire to carry broadcast data for each VPN. 5. Frame Processing The following sections describe the frame encapsulations used by the VHLS model and how each intermediary device process such encapsulated frames for database maintenance and frame forwarding functions. The VHLS model is supported by the L2PE and PE devices. The VHLS model requires special frame formats between these VHLS devices. The frames received from CE devices are encapsulated by L2PE devices into hierarchical MAC frames that have enough information so that PE and L2PE devices can "learn" the source L2PE device of these frames. The frame must also include information that limits the replication of broadcast and multicast frames within the L2VPN. The hierarchical encapsulation frame headers used by the L2PE and PE devices are stripped before transmitting frames to the CE devices. Each L2PE device is assigned a single MAC address, which is used to uniquely identify the L2PE device within the service provider's network. In addition an L2VPN identifier is required. This identifier is used to determine frame handling characteristics, such as broadcast scope, that is particular to the L2VPN. The VHLS model defines a new Ethernet type to support the definition of a VHLS L2VPN identifier and control word (VIC). The value of the Ethernet type is TBD and is referred to as VHLS ether-type (VET). The VIC is a 32-bit field as described below: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-----------------------------------------------+ |O|C|r|r|r|Q|Q|Q| 24-bit L2VPN identifier | +-+-+-+-+-+-+-+-+-----------------------------------------------+ The first 8-bits define a VHLS Control Field. The next 24-bits define a VHLS L2VPN identifier that is administered by the Service Provider. This L2VPN identifier is used to separate data between customers, and is globally unique for a service provider's network. The VHLS L2VPN identifiers 0 and 16777215 are reserved. Sodder Expires - October 2003 [Page 7] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 Bit 0 of the 8-bit Control Field (O) is defined as an OAM indicator. Bit 1 is defined as a CRC indicator. Bits 2 through 4 (r) are reserved. Bits 5 through 7 (Q) define the QOS field. The use of the QOS field is dependent on the architecture of the service provider network. Details of the OAM indicator are TBD and the bit must be currently set to zero. Details of the CRC indicator are described in section 4.2. All reserved bits must be set to zero. 5.1 CE Frame Processing This model does not require that the CE devices perform any special frame processing in addition to that provided by a typical device attached to an Ethernet LAN. The following frame formats are supported: +-------+-------+-----+-------------------------------------+-------+ | MACDA | MACSA | T/L | Information | CRC32 | +-------+-------+-----+-------------------------------------+-------+ +-------+-------+----+------+-----+-------------------------+-------+ | MACDA | MACSA |8100| VLAN | T/L | Information | CRC32 | +-------+-------+----+------+-----+-------------------------+-------+ These frames are received and transmitted by the L2PE devices on CE facing interfaces and processed as described below. 5.2 L2PE Frame Processing All frames received or transmitted over L2PE to PE interfaces are encapsulated by the L2PE device within a hierarchical MAC frame as described below. +---------+---------+----+-----+------------------------------+-----+ |BCST-ADDR| L2PE-SA |88AC| VIC | CE Frame |CRC32| +---------+---------+----+-----+------------------------------+-----+ +---------+---------+----+-----+------------------------------+-----+ | L2PE-DA | L2PE-SA |88AC| VIC | CE Frame |CRC32| +---------+---------+----+-----+------------------------------+-----+ The first frame, which uses a broadcast MAC address (BCST-ADDR) is used when the CE frame contains a MAC destination address that is unknown. After a learning process, L2PE devices will map the CE MACDA to a L2PE-DA so using the second frame format. Sodder Expires - October 2003 [Page 8] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 In the above frame formats the CE frame SHOULD include the original CRC32 to allow detection of bit errors introduced by devices in the service provider network or devices attached to the service provider network. When the CRC32 of the CE frame is included the CRC indicator bit in the VIC must be set. If the L2PE device needs to modify the CE frame it MAY calculate and add a new CRC32 to the CE frame or it MAY strip the CRC32 of the CE frame and clear the CRC indicator bit in the VIC. The L2PE maintains a MAC address table per L2VPN defined. When transmitting a CE frame to a PE device, the L2PE-SA in the frame is the MAC address of the transmitting L2PE device. The L2PE must learn the addresses of remote L2PE devices and map these to the CE MAC addresses within the L2VPN. The L2PE device supports a forwarding data base. The data base is keyed using the CE MACDA and the L2VPN identifier. The data for each keyed entry that belongs to a CE connected interface contains the identity of the CE interface. The data for each keyed entry that belongs to a L2PE interface contains the L2PE-DA MAC address. The L2PE MUST use the configured L2VPN identifier for this interface and perform a lookup of the CE MACDA within the L2VPN forwarding table for the received frame. If the MACDA is unknown the frame is forwarded using an L2PE MACDA of FF-FF-FF-FF-FF-FF to all interfaces that belong to the L2VPN. If the MACDA is known it is forwarded to the appropriate interface. In both cases the interface could be a CE interface or a PE interface, also the appropriate frame format must be used. When forwarding frames to a PE interface it uses the hierarchical frame format. The MACDA in the hierarchical Ethernet header is the learnt L2PE-MACDA or the L2PE-BCST MAC address. The MACSA is the MAC address assigned to the L2PE device. The Ethernet type is set to 0x88AC and the next 4 bytes are the VIC field. The Q bits in the VIC field depend on the QOS architecture in use. The information field in this MAC frame is the CE MAC frame. The L2PE will also perform a lookup using the CE MACSA and the configured L2VPN identifier within the L2VPN forwarding table. This is required to learn the source of the CE frame. On receiving frames from the connected PE device, the L2PE will use the CE MACDA and the L2VPN identifier in the received frame to perform a lookup within the forwarding table. If the lookup returns a CE interface as the destination, the CE frame is forwarded to this interface. If the lookup returns a network-facing interface the frame is dropped. If the lookup results in a failure, the CE frame is flooded to all CE interfaces that support traffic to the particular Sodder Expires - October 2003 [Page 9] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 L2VPN. The L2PE will also perform the learning function on the CE MACSA and map it to the L2PE MAC address and L2VPN identifier as learnt from the received frame. The L2PE device performs "aging" on all MAC addresses learnt. 5.3 L2PE Frame Processing for frames with 802.1Q VLAN Tags When L2PE devices are connected to CE devices that support VLAN tags in a non-transparent manner, they must be configured as such and each VLAN tag MUST be assigned to a unique L2VPN identifier. This ensures that the PE devices can perform forwarding and control functions for both types of Ethernet frames in a similar and consistent manner. 5.4 PE Frame Processing PE devices support the following frame processing methods depending on which interface the frame is received, and the type of frame received. Frames received from PE devices over the backbone network MUST be forwarded to L2PE devices. Frames received from L2PE devices can be forwarded to other L2PE devices and/or remotely connected PE devices using the backbone network. PE frame processing assumes that the service provider's backbone network architecture supports point-to-point and multipoint frame processing. The backbone network architecture must support the ability to link a tunnel in one direction between end-points to a tunnel in the reverse direction between the same end-points so that learning in one direction can be used to forward data in the reverse direction. The PE device is responsible for providing replication services. The L2VPN topology is used to determine the destinations to which broadcast frames must be replicated. PE devices receiving broadcast frames on backbone interfaces will not forward these frames to other PE devices. PE devices maintain a forwarding database that have two types of keys. The first key is used for frames received from backbone interfaces and depends on the architecture of the backbone network. The data associated with this key typically will include information that results in the PE performing an additional lookup based on the second key. The second key is made up of the L2PE-DA address and the L2VPN identifier received in the frame. Frame processing details of the first key is dependent on the backbone network architecture and is thus beyond the scope of this draft, in fact in some architectures it may not be required. Sodder Expires - October 2003 [Page 10] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 The PE device processes frames received from L2PE devices in two different ways depending on the received MACDA in the frame. If the L2PE-MACDA is a Unicast MACDA then it MUST be a known MACDA. If it is unknown the frame is dropped. Known L2PE-MACDA frames are forwarded based on the lookup result. If the frame is forwarded to a backbone interface it is encapsulated if required based on the backbone network architecture. If the frame is forwarded on an L2PE facing interface no additional encapsulation is required. When the received L2PE-MACDA in the frame is a broadcast MAC address the PE device must replicate this frame to all L2PE devices that support connectivity for the L2VPN defined in the VIC. Frames received from backbone network interfaces should not be forwarded to other backbone network interfaces. When receiving frames the PE device will perform a lookup of the L2PE-SA address and the L2VPN identifier in order to learn the source interface of the frame. 5.5 PE Frame Processing for MPLS based backbone networks There are two methods for transferring frames on an MPLS based Service Provider Backbone network. The first uses a simple MPLS tunnel the second uses a pseudo-wire. The frame format for an MPLS tunnel based [MPLS-ARCH] Service Provider Backbone network is shown below: +--------------+----------------+-----------------------------+-----+ |MPLS-L2-header|L2PE-enet-header| CE Frame |CRC32| +--------------+----------------+-----------------------------+-----+ The frame format for a pseudo-wire based MPLS Service Provider Backbone network is as defined in [PWE3-ENET] and is replicated below for completeness. +--------------+------------+----------------+----------------+-----+ |MPLS-L2-header|PWE3-Header |L2PE-enet-header| CE Frame |CRC32| +--------------+------------+----------------+----------------+-----+ The format of the MPLS-L2-header [MPLS-ENCAPS] is specific to the protocol used in the PE uplink. The PWE3-Header includes a tunnel-label, an LSP label that has been signaled using RSVP-TE [RSVP-MPLS-TE] or any other MPLS signaling protocol in use by the service provider backbone network. The PWE3- Sodder Expires - October 2003 [Page 11] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 Header also includes a VC-Label that is signaled using the extensions to [PWE3-CTRL] as specified earlier in this draft. The L2PE-enet- header is the L2PE-MACDA, L2PE-MACSA, VET and VIC. The information field is the original CE frame. The Ethernet CRC32 added by the L2PE device is replaced by the CRC32 used by the tunneling protocol. When using MPLS for the tunneling protocol, the QOS bits in the VHLS L2VPN field are mapped to and from the EXP bits in the E-LSP tunnels as recommended in [MPLS-DIFFSERV]. 6. LDP Signaling The following section defines methods that allows LDP to be used to signal the following information between the PE nodes: 1. PE Discovery 2. VPN Discovery 3. VC Label Signaling 6.1 PE Discovery A method for performing service discovery signaling using LDP is covered within [DRAFT-STOKES]. A PE device may signal its service capabilities using a new optional Service Capabilities TLV that uses the LDP Label Mapping message. The complete TLV definition with the VHLS specific parameters is included here for convenience: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x0105) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | Service Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Service Parameters (variable length) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown bit. This bit MUST be set to 1. If the Node Type format is not understood, the remaining Label Mapping should be processed, and the Service Capabilities TLV MUST be ignored. F bit Sodder Expires - October 2003 [Page 12] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 Forward bit. This bit MUST be set to 1. Since the network topology is unknown and there may be non-VPLS nodes receiving the label message, the Service Capabilities TLV MUST be forwarded. Type Type field. This field MUST be set to 0x0105 (subject to IANA approval). This will identify the TLV type as a Service Capabilities TLV. Length Length field. This field specifies the total length of the Value fields in octets. Service Type Service Type field. This has the following values: Value Node Type ----------------- 0 Undefined 1 VPLS core node 2 VHLS PE (proposed) Note that a node may support multiple service types, in which case it will advertise multiple Service Capabilities TLVs. Service Instance Service Instance field. This field contains a 16-bit index used as an instance identifier for the service. This enables, for example, one Service Provider to create multiple sets of VPLS nodes providing different grades of service. Note that a node may have multiple service instances, in which case it will advertise multiple Service Capabilities TLVs. Note also that in the case of VPLS, one service instance may contain multiple VPLS services. This field must have a value of 0 when advertising a VHLS capable PE node. Service Parameters Optional Service Parameters. Some service types may have additional parameters that must be discovered for correct operation of the service. This field is not required for VPLS. Note that for a given service type and instance a node will only advertise one Service Capabilities TLV, with one set of Service Parameters. Currently there are no Optional Service Parameters defined when advertising a VHLS capable PE node. Sodder Expires - October 2003 [Page 13] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 6.2 VPN Auto Discovery Following the discovery of a remote PE node, either via configuration or signaling, the PE node may setup an extended LDP session for the purpose of signaling VPN membership. VPN membership is advertised using the Address Message and withdrawn using the Address Withdraw Message using a new TLV, the VPN List TLV. The VPN List TLV is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| VPN List | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | ~ VPN Identifiers ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VPN List VPN List type field. This field must be set to 0x0108 (subject to IANA approval), which identifies this as a VPN List TLV. Length Length field. This field specifies the total length of the TLV (including the Type and Length fields). VPN Type VPN Type field. This field may have the following values: Value VPN Type -------------------- 0 Undefined 1 VHLS VPN identifier (24-bit) 2 VPLS VC identifier (32-bit) 3 Global VPN identifier (7 octet) Sodder Expires - October 2003 [Page 14] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 VPN Auto Discovery Procedures: After the establishment of a extended LDP session with a peer node, the VHLS PE node should send one or more LDP Address Messages so that the complete list of active VPN identifiers have been advertised to the remote node. Upon receipt of the LDP Address Messages that contains a VPN identifier list TLV, a VHLS PE node will perform the following actions for each VPN identifier within the advertisement: Store both the remote VHLS PE node identifier (IP address) and VPN identifier in a local database Compare each remote VPN identifier with the VPN identifiers that are active on the local node. For each matching set (remote and local) of VPN identifiers activate the flooding of that VPN identifierÆs traffic to the remote VHLS PE using an appropriate tunnel (e.g. MPLS, GRE). Whenever a new VPN identifier becomes active on a VHLS PE, the node should send an LDP Address Message that contains the VPN identifier (or identifiers) to each of the remote VHLS PE nodes. Additionally, the node must determine if the VPN identifier is also active on any remote VHLS PE nodes and activate flooding for the VPN identifier for each matching set (same as #2 above). Whenever a VPN identifier transitions from active to inactive on a VHLS PE, the node should send an LDP Address Withdrawal Message that contains the previous active VPN identifier (or identifiers) to each of the remote VHLS PE nodes. Upon receiving a LDP Address Withdrawal Message that contains a VPN identifier list TLV, a node will perform the following actions for each VPN identifier within the withdrawal: If the VPN identifier is also active on the VHLS PE node, then flooding must be disabled to the tunnel that attaches to the remote VHLS PE node. All MAC addresses that have been learned from remote VHLS PE and VPN identifier pair should be removed from the forwarding database. The entry that represents both the remote VHLS PE node identifier (IP address) and VPN identifier must be removed from the local database. 6.3 VC Label Signaling When using the encapsulation method described in [PWE3-ENET], it will be necessary for each PE node to distribute a single VC label to all of the other remote PE nodes within the Service Provider Backbone Network. This VC label may be advertised using LDP downstream Sodder Expires - October 2003 [Page 15] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 unsolicited mode after the establishment of the extended LDP session with PE node. A new type of FEC element, the VHLS FEC, is defined for the purpose of distributing the VC labels to the remote PE nodes. The VHLS FEC is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VHLS FEC | reserved (mbz) | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VHLS FEC The VHLS FEC field. This field has a value of 123 (subject to IANA approval) and identifies this as a VHLS FEC element. Security Considerations The security aspects of this model will be discussed at a later time. References i Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [MPLS-DIFFSERV] F. Le Faucheur et al, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002 [RSVP-MPLS-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. Sodder Expires - October 2003 [Page 16] Internet Draft draft-sodder-ppvpn-vhls-02.txt April 2003 [PWE3-ENET] Martini, L., et al., "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3- ethernet-encap-00.txt, (work in progress), August 2002 [PWE3-CTRL] Martini, L. et al., "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-control-protocol-00.txt, (work in progress), August 2002 [VPLS] Lasserre, Kompella et al., "Virtual Private LAN Services over MPLS", draft-lasserre-vkompella-ppvpn-vpls-02.txt, (work in progress), June 2002 [IEEE-802.1Q] "IEEE Standards for Local and Bridged Metropolitan Area Networks, Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 1998 Edition. [IEEE-802.1D] "IEEE Standards, Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 1998 Edition. [IEEE-802.3] "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3, 2000 Edition. [DRAFT-STOKES] ôDiscovering Nodes and Services in a VPLS Networkö, draft-stokes-ppvpn-vpls-discover-00.txt, (work in progress), June 2002 Acknowledgments The authors would also like to thank Louie DiDiodato, Himanshu Shah and many others at Tenor Networks that provided valuable comments. Intellectual Property Considerations Tenor Networks may seek patent or other intellectual property protection for some or 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 Tenor Networks, Tenor Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Sodder Expires - October 2003 [Page 17] Internet Draft draft-sodder-ppvpn-vhls-01.txt April 2003 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. Author's Addresses Arnold Sodder Tenor Networks, Inc 100 Nagog Park Acton, MA 01720 Phone: 978-264-4900 Email: asodder@enterasys.com Tim Mancour Tenor Networks, Inc. 100 Nagog Park Acton, MA 01720 Phone: 978-264-4900 Email: tim_mancour@yahoo.com K.K. Ramakrishnan AT&T Labs-Research, Room A117 180 Park Avenue Florham Park, NJ 07932 Phone: 973-360-8764 Email: kkrama@research.att.com Sodder Expires - October 2003 [Page 18] Internet Draft draft-sodder-ppvpn-vhls-01.txt April 2003 Charles Kalmanek AT&T Labs-Research 180 Park Avenue Florham Park, NJ 07932 Phone: 973-360-???? Email: crk@research.att.com Christopher N. DelRegno WorldCom, Global Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-2886 Phone: 972-729-3411 Email: Nick.DelRegno@wcom.com Scott Kotrla WorldCom, Global Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-2886 Phone: 972-729-3407 Email: scott.kotrla@wcom.com Joris Wils Coriolis Networks 330 Codman Hill Rd Boxborough, MA 01719 Phone: 978-264-1904 x667 jwils@coriolisnet.com Sodder Expires - October 2003 [Page 19]