Himanshu Shah K. Arvind Internet Draft Tenor Networks draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt Sunil Khandekar Vach Kompella TiMetra Networks Ashwin Moranganti Dave Ward Appian Communications Giles Heron PacketExchange, Ltd. Expires: August 2002 February 2002 Signaling between PE and L2PE/MTU for Decoupled VPLS and Hierarchical VPLS draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt 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. 2. Abstract The [DTLS] draft identifies the need for an information exchange mechanism between a PE device and its adjunct L2PE devices in the decoupled transparent LAN architecture. For example, the PE needs to provide information to an L2PE about the existence of remote site(s), and the MPLS label(s) that the L2PE needs to use to reach those site(s). The [HVPLS] draft requires signaling between the PE- rs and the MTU-s device to setup the spoke VC connection for the VPLS service. Shah Informational - Expires May 2002 1 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 This draft proposes an LDP based approach for such exchange mechanisms. The mechanisms proposed here allow: - The L2PE, in case of [DTLS], to provide an acceptable set of incoming labels to PE. - The MTU-s, in case of [HVPLS], to negotiate the spoke VC labels with the PE. Optionally, this draft also allows the PE to provide TLS specific configuration to an L2PE or MTU-s device. 3. ID Summary SUMMARY This ID describes information exchange between PE and adjunct L2PE devices, which together offer transparent LAN services for Layer 2 VPN solution. RELATED DOCUMENTS draft-kompella-ppvpn-dtls-00.txt, draft-khandekar-ppvpn-hvpls-00.txt draft-knight-l2vpn-lpe-ad-00.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Belongs in PPVPN WHY IS IT TARGETED AT THIS WG This document describes a mechanism to assist in Provider- Provisioned Layer 2 VPNs. JUSTIFICATION We believe that when VPLS is offered using the layer 2 VPN solution, it is desirable to accommodate network topologies where PE and an adjunct [DTLS]L2PE or [HVPLS]MTU-s device together offer connectivity to the customer devices. In such scenario, PE and L2PE/MTU-s need to exchange label information needed for packet forwarding and optionally customer specific information. This document provides this exchange mechanism and interpretation guidelines for L2PE/MTU-s. 4. Introduction The [DTLS] draft describes methodologies by which a PE device can relegate traditional bridging functions to adjunct L2PE devices while restricting itself to L2VPN signaling activities. In such configurations, a PE device would be responsible for providing the remote site membership information to its attached L2PEs. Shah, et al. Expires August 2002 Page 2 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 The [HVPLS] draft describes a model where the base [VPLS] solution is enhanced with a hierarchical connectivity approach to eliminate the full mesh VC requirements. Since the PE is also performing bridging functions in this model, the need for an LSP per remote site between PE and adjunct MTU-s device is replaced by a single LSP per TLS. In either case, the PE and L2PE/MTU-s devices need to exchange label information for each VPLS. This document identifies the information elements employed for this purpose and describes how LDP is used as the distribution mechanism. It also describes how an L2PE/MTU-s device interprets and processes such information. The goal is to provide an interoperable way to facilitate vendor partnerships when offering the L2VPN DTLS and HVPLS solutions. The [DTLS] solution refers to the bridging device typically placed in the Multi-Tenant Unit(MTU) as the L2PE while the [HVPLS] solution refers to the same device as the MTU-s denoting a switching or a bridging capable MTU device. To avoid confusion, the rest of this document will refer to this device simply as the MTU device. 5. Information Elements 5.1. DTLS The [DTLS] document identifies various pieces of information pushed by a PE device to its adjunct MTU devices: (1) Virtual Private LAN Service (VPLS)-related MTU configuration information: Distribution of the information is optional and is described later in the document in Section 5.2. (2) Label information: The set of labels that the PE device and MTU device will use to identify various remote sites. Label information is specified as a set of label ranges, where each label range consists of a base label value, an offset that identifies the site corresponding to the base label, and the number of sites in the range. Each label in the range corresponds to a connection to a remote site. [DTLS] deviates from traditional MPLS in that the label distributed by the PE to the MTU is considered a bi-directional label. Suppose a PE device P distributes label X (associated with remote site R) to an adjunct MTU device L. In traditional MPLS label distribution, this is a signal from P to L that L should use label X in all packets that it routes to R via P. [DTLS] specifies that P will also use label X in all packets from R that are directed towards L. However, incoming labels are resources that are usually allocated by the receiving node (L) rather than the transmitting node (P). Depending on the available label space in the receiving node L, Shah, et al. Expires August 2002 Page 3 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 label allocation by the transmitting node P may create issues. This draft proposes that an MTU device optionally be able to notify or negotiate an acceptable label range with its PE device. [TBD - The need for the bi-direcionality requirement for labels used between the PE and MTU that [DTLS] specifies is not clear. If this requirement can be relaxed, one could fall back to the traditional LDP label exchange mechanism, where each side proposes labels that it is happy with]. The proposed approach provides a twofold advantage. Firstly, it allows an MTU to signal its limitations (if any) on handling the bit-size for the incoming label width. Secondly, if an MTU device is dual-homed to two PE devices on a shared LAN, the MTU device can provide disjoint label ranges to each PE device. This can be used to avoid overlap and hence eliminate the confusion at the MTU device about the origin of data packets received on the LAN. This document recommends exclusion of the circuit status bit vector information from the distributed label information. This is replaced by the explicit withdrawal of the corresponding label when the connection to a remote site is interrupted. This works well with the [HVPLS] architecture, as the notion of a circuit status bit vector is absent. Also, in [HVPLS], the label per remote site paradigm does not exist eliminating the need for notification when remote site reachability is interrupted. The [DTLS] draft also requires that a PE device advertise a contiguous block of labels of size n to an MTU device, when it advertises a block of VPN labels of size n to remote PEs. This draft relaxes the requirement that the PE advertise the n labels to the MTU device in a single block. It allows the advertisement of multiple label blocks that need not be contiguous to each other, as long as the total number of labels advertised to the MTU device is equal to n. 5.2. HVPLS HVPLS works with either an MTU that is capable of signaling and can participate in DTLS, or with a legacy MTU that is capable of imposing customer-delimiting VLAN tags. Since a PE-rs in the HVPLS terminology can do replication, it does not require the MTU to send multiple packets with different labels in a label range to effect a replication. The PE therefore has to send only a single label to a DTLS-enabled MTU. 6. MTU related configuration on PE The [DTLS] document suggests MTU specific configuration on PE to be, <> < > Shah, et al. Expires August 2002 Page 4 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 < . . .> < > < . . .> . . . > Here, PE is configured with MTU's router ID and interface that connects to the MTU. Additionally, for each VPLS/TLS and MTU site ID pair, a set of MTU's customer facing port ID and VLAN tag pairs are configured on the PE. The configuration of MTU port ID and VLAN tag specific information on the PE is optional. The distribution of this optional configuration information is discussed in section 6.2. 7. Exchange Mechanism using LDP There are several protocols that can be used to exchange TLS specific information between PE and MTU. Among them LDP seems most suitable for exchanging information that essentially consists of labels. 7.1. MTU FEC Element An MTU FEC Element is encapsulated in a FEC TLV. The following MTU FEC Element is sent in a Label Mapping message using downstream- unsolicited distribution. The MTU FEC Element has a one-to-one correspondence with the Label TLV that follows the MTU FEC Element. The MTU must process the L2PE FEC and Label TLV within the scope of the associated LDP session, which in turn may run within the scope of the interface that directly connects L2PE and PE. The association of the L2PE FEC and Label TLV with a specific interface is important for two reasons. Firstly, it allows labels to be interface-specific and secondly it provides an L2PE with information about the interface on which it should forward packets with the allocated label to the PE. . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU Type |H| Reserved | Site Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS ID (most significant 4-bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS ID (least significant 4-bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shah, et al. Expires August 2002 Page 5 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 7.1.1. MTU Type The MTU type field identifies the FEC Element as an MTU FEC Element. The value is TBD. 7.1.2. H bit The H bit, when set, is used to indicate to the MTU that the PE is an HVPLS PE. 7.1.3. Reserved This field is reserved for now and must be set to zero and ignored on receipt. 7.1.4. Site Identifier Site identifier is a 2-byte value assigned by a PE. The site identifier has VPLS scope and is used for administrative purposes. In [HVPLS], the Site Identifier value is not used. It must be set to zero when sending and ignored on receipt. 7.1.5. VPLS Identifier The VPLS identifier is an 8-byte value assigned by the PE. The value identifies a VPLS for the MTU. An MTU must treat each VPLS as a logical bridge instance with its own configuration, flooding scope, forwarding information base and spanning tree protocol. The PE treats each VPLS as a VPN instance and engages in locating and establishing connections to remote PE that participates in the same VPN (or VPLS). 7.2. Label Signaling A conventional LDP Label TLV is used to signal labels. However, since a label range needs to be signaled, two optional parameters are defined for the Label TLV. 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| Label TLV Type | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = RSID | Length = 2 | Remote Site ID Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = LS | Length = 2 | Label Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shah, et al. Expires August 2002 Page 6 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 Instead of a label, the Label Base is specified in the TLV. Following the Label Base, there are two optional parameters that MUST be present when the PE is a DTLS PE. Note that since HVPLS needs only one label, these two sub-TLVs are not necessary. The codepoints for the Remote Site ID Base TLV and Label Size TLV are TBD. 7.2.1. Remote Site ID Base TLV This field along with the Label Size field enables the association of remote sites with MTU labels. The site identified by the Remote Site ID Base field is associated with the label value specified in the Label TLV associated with this FEC. The site identified by the site ID obtained by incrementing the Remote Site ID Base value by n is associated with the label value obtained by incrementing the value specified in the Label TLV by n, where n ranges from 1 to Label Size-1. The knowledge of remote site IDs at an MTU is for administrative purposes only. The MTU does not use the remote site ID value in making data packet forwarding decisions. The MTU however uses the label value for data packet forwarding. In [HVPLS], the Remote Site ID Base TLV is ignored, and MAY be omitted. 7.2.2. Label Size TLV The Label Size TLV indicates the width of a contiguous set of labels starting from label base. The label base is indicated in the associated label TLV. Each label in the label set represents a possible connection to a remote site that is part of the VPLS L2VPN. In essence, an MTU should treat each label as a "logical interface" that is mapped to the physical interface directly connecting the MTU to the PE. The [DTLS] specification describes the special rules of operations for such logical interfaces, such as modified learning, modified forwarding, etc. It is important that an MTU treat each label as an individual entity even when it is advertised as a set. The advantage of this approach is that individual labels can be withdrawn without having to withdraw the entire list. When one or more labels are withdrawn, an MTU must unlearn all the MAC addresses associated with each label. Also, an MTU must maintain each label within the context of its LDP session for reasons mentioned earlier. The Label Size field is not necessary for [HVPLS] and MAY be set to zero on send and ignored on receipt, or set to 2 (indicating that Shah, et al. Expires August 2002 Page 7 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 there are 2 MTUs in this MTU's context, itself, and the rest of the VPLS behind the PE). No other values are defined for HVPLS. 7.3. Configuration TLV The configuration TLV is part of the set of optional parameters that is present in a Label Mapping message. The Configuration TLV associated with the MTU FEC provides configuration information to MTU that specifies customer-facing ports that are members of the TLS identified by the MTU FEC. The configuration TLV is optional for [DTLS] and [HVPLS] architecture. The organization of a configuration TLV is a hierarchy of sub-TLVs. The physical port attributes are set in the Port Config TLV. Following that, a logical port TLV defines further delimiters for logical ports. Logical port attributes such as bandwidth capacity of the logical port are also included. All logical port attributes are optional. In the cases when there is new configuration information but no new label information, the label size field in MTU FEC is set to zero, the label base value is set to one of the labels already advertised and only the configuration TLV information is relevant. This is also applicable to label withdraw message in which a label size field value of 0 in the MTU FEC should be treated as an indication to ignore the label values and apply withdraw to configuration TLV. This mechanism allows notifications of add and delete of customer facing ports independent of label notifications for the remote sites. Refer to the following diagram for the definition of the configuration TLV. 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| Config TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Port Config TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Reserved | MTU unit# | MTU slot# | MTU card# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU port# | MTU Channel# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Optional Logical Port Attribute TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Logical Port Config TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | Customer Delimiting Field | Shah, et al. Expires August 2002 Page 8 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Logical Port BW TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | | Other Optional Logical Port Attribute TLVs | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n | Reserved | MTU unit# | MTU slot# | MTU card# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU port# | MTU Channel# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Optional Logical Port Attribute TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Logical Port Config TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | Customer Delimiting Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Logical Port BW TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | | Other Optional Logical Port Attribute TLVs | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.3.1. Config TLV Type The field identifies the configuration TLV. The value is TBD. 7.3.2. Length The Length field represents the total number of bytes in the value field that follows the length field. 7.3.3. MTU port ID The MTU port ID is represented in hierarchical fashion. There are five sub-fields, with unit number at the top of the hierarchy and channel number at the bottom. The value zero in any of the sub-fields indicates absence of that category. The MTU port number is the only exception to this rule and must contain a non-zero value. [Note: We are not aware of any standard hierarchical way of identifying ports on a detached network device. Comments welcome] Shah, et al. Expires August 2002 Page 9 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 The MTU must identify the port ID before processing the associated VLAN tag and bandwidth information. The same port Id may repeat in different information elements to carry different VLAN tag and bandwidth information. However, when both port Id and VLAN tag pair are same in two information elements, the bandwidth value from later information element is used for update. 7.3.3.1. Reserved Not used at present. [TBD - This could be turned into a user definable field to allow vendors to add more information related to a given MTU port ID, if necessary]. 7.3.3.2. MTU unit number The MTU unit number field allows cascading of multiple ethermux boxes to be represented as single manageable device. For such configuration, unit number uniquely identifies a particular ethermux switch. If MTU is a single physical unit, this field should be set to zero. 7.3.3.3. MTU Slot number If an MTU device is slot-based, the non-zero value is used to identify a slot. The value zero indicates slot number field is not used. 7.3.3.4. MTU card number If an MTU device is slot-based and each slot can hold more than one card, a non-zero value must be set to identify the appropriate card. The value zero indicates the slot does not contain multiple cards. 7.3.3.5. MTU port number Every Ethernet device has Ethernet port. This value must be non-zero. The port value is relative to card, slot and unit values as described earlier. 7.3.3.6. MTU channel number The channel number represents a channel on a physical port. If an Ethernet port is not channelized, this field must be set to zero. 7.3.4. Logical Port Config TLV The Logical Port Config provides the logical port delimiter to be used for the customer access port. Shah, et al. Expires August 2002 Page 10 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 7.3.4.1. T bits The T bits identify the type of customer delimiter. Currently, only VLAN tags are defined. The value of T is TBD for VLAN tagging. When the T bits are set for VLAN tagging, the associated VLAN tag is used to tag any untagged Ethernet frame received on that port as required by the port-based 802.1Q VLAN operations. Similarly, the outgoing frame must be untagged if the VLAN tag were to be of the same value as the associated VLAN tag field. 7.3.4.2. Customer Delimiting Field Only VLAN tags are currently defined as Customer Delimiting Fields. A VLAN ID is a 12-bit field. Any value other than 0x000 and 0x0ff represents a valid 802.1Q VLAN id. The VLAN id field is used to either identify or tag an incoming frame based on the setting of the T bits. The MTU must register the presence of the VLAN tag within the scope of the VPLS and accord 802.1Q based services, such as flooding, spanning tree processing, etc. for the VLANs identified for the VPLS. The value 0x000 is used to indicate absence of a VLAN tag field. 7.3.5. Logical Port Bandwidth TLV The Logical Port Bandwidth TLV provides traffic parameters for the customer port. 7.3.5.1. Bandwidth Bandwidth is a 2-byte field. When non-zero, it represents a value in megabits per second (TBD: use IntServ floating point bandwidth format instead). If MTU is capable of discriminating traffic and provide resources to achieve bandwidth based traffic shaping, it should use the associated VLAN tag field and the bandwidth value to achieve this goal. 8. MTU to PE MTU may optionally notify its TLS membership to its directly attached PE. It may also optionally include the range of MTU labels that MTU is capable of processing for a given TLS for the given LDP session. For TLS membership notification, MTU uses label TLV and MTU TLV in the same format as described above. The MTU FEC contains a valid L2PE type, site ID, and TLS ID. All the rest of the fields are set to zero. When MTU also wants to relay the MTU label range, it provides the starting label value in label TLV and the size value in the label size field of the MTU FEC. For example, if MTU wants PE to use Shah, et al. Expires August 2002 Page 11 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 labels between 8K and 12K, it would set label value in label TLV to be 8K and the size value to be (4k-1) in the label size field of the MTU FEC. MTU may also optionally notify PE about its role for PE. The [DTLS] and [HVPLS] describes operation rules for primary and secondary role for the PE. 9. Two PEs connected to same MTU on shared LAN As stated earlier, MTU could be configured with disjoint label ranges for each PE. MTU would then advertise this information to PE at the beginning of the session. PE must advertise the label subsets from the range received from MTU for remote connections notifications. MTU can now identify distinctly a remote connection through a PE for a given TLS based on the incoming label in the received data packet. 10. One PE connected to two MTU supporting same TLS on shared LAN This is handled by PE and MTUs configured with distinct site identifier and MTU configured with disjoint label ranges. 11. Acknowledgments The authors would like to thank Tim Mancour, Bill Townsend, Arnold Sodder, Xavier Briard and David Bahi for their valued comments. 12. Security considerations The security aspects of this solution will be discussed at a later time. 13. References [L2VPN] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella- mpls-l2vpn-02.txt, November 2000. [DTLS] Kompella et al., "Decoupled Transparent LAN Services", draft- kompella-ppvpn-dtls-01.txt [HVPLS] Khandekar et al., "Hierarchical Virtual Private LAN Service", draft-khandekar-ppvpn-hvpls-mpls-00.txt. 14. Authors' Addresses Himanshu Shah Tenor Networks 100 Nagog Park Acton, MA 01720 Email: hshah@tenornetworks.com Shah, et al. Expires August 2002 Page 12 Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002 K. Arvind Tenor Networks 100 Nagog Park Acton, MA 01720 Email: arvind@tenornetworks.com Sunil Khandekar and Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Email: sunil@timetra.com Email: vkompella@timetra.com Ashwin Moranganti and Dave Ward Appian Communications 35 Nagog Park, Acton, MA 01720 Email: amoranganti@appiancom.com Email: dward@appiancom.com Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom e-mail: giles@packetexchange.net Shah, et al. Expires August 2002 Page 13