Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt May 2002 Internet Draft Document Marc Lasserre draft-lasserre-vkompella-ppvpn-vpls-00.txt Riverstone Networks Vach Kompella Nick Tingle Timetra Networks Pascal Menezes Loa Andersson Terabeam Networks Utfors Andrew Smith Pierre Lin Consultant Yipes Communication Lewis Eatherton Giles Heron Excite@Home PacketExchange Ltd. Juha Heinanen Tom S.C. Soon Song Networks SBC Communications Rick Wilder Luca Martini Masergy, Inc. Level 3 Communications Nick Slabakov Rob Nath Riverstone Networks Expires: May 2002 November 2001 Transparent VLAN Services over MPLS 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 Lasserre, Kompella et al. [Page 1]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 http://www.ietf.org/shadow.html. Abstract This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). VPLS simulates an Ethernet virtual 802.1d bridge [802.1D-ORIG] [802.1D-REV] for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VLS services can be supported from a single PE node. Conventions 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 Placement of this Memo in Sub-IP Area RELATED DOCUMENTS http:// search.ietf.org/internet-drafts/draft-martini-l2circuit- trans-mpls-06.txt http://search.ietf.org/internet-drafts/draft-martini-l2circuit- encap-mpls-02.txt http://search.ietf.org/internet-drafts/draft-augustyn-ppvpn-vpls- reqmts-00.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. Lasserre, Kompella et al. [Page 2]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................2 Conventions........................................................2 Table of Contents..................................................3 1. Overview........................................................4 2. Bridging Model for MPLS.........................................4 2.1 Flooding and Forwarding........................................5 2.2 Address Learning...............................................6 2.3 LSP Topology...................................................6 2.4 Loop free L2 VPN...............................................6 2.5 LDP Based Signaling............................................7 3. MAC Address Withdrawal..........................................9 3.1 MAV TLV.......................................................10 3.2 Address Withdraw Message Containing MAC TLV...................11 4. Operation of a VPLS............................................11 5. Security Considerations........................................13 6. Intellectual Property Considerations...........................13 7. Full Copyright Statement.......................................13 8. References.....................................................14 9. Author's Addresses.............................................14 Lasserre, Kompella et al. [Page 3]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 1. Overview Ethernet has become a predominant technology initially for Local Area Networks (LANs) and now as an access technology, specifically in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated to customers on Provider Edge (PE) routers acting as LERs. Customer traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs based upon the input port and/or VLAN. Broadcast and multicast services are available over traditional LANs. MPLS does not support such services currently. Sites that belong to the same broadcast domain and that are connected via an MPLS network expect broadcast, multicast and unicast traffic to be forwarded to the proper location(s). This requires MAC address learning/aging on a per LSP basis, packet replication across LSPs for multicast/broadcast traffic and for flooding of unknown unicast destination traffic. [MARTINI-ENCAP] defines how to carry L2 PDUs over point-to-point MPLS LSPs. This document describes extensions to [MARTINI-ENCAP] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic across multiple sites that belong to the same L2 broadcast domain. Note that the same model can be applied to other 802.1 technologies. It describes a simple and scalable way to offer Virtual LAN services, including the appropriate flooding of Broadcast, Multicast and unknown unicast destination traffic over MPLS, without the need for address resolution servers or other external servers, as discussed in [VPLS-REQ]. The following discussion applies to devices that serve as Label Edge Routers (LERs) on an MPLS network that is VPLS capable. It will not discuss the behavior of transit Label Switch Routers (LSRs) that are considered a part of MPLS network. The MPLS network provides a number of Label Switch Paths (LSPs) that form the basis for connections between LERs attached to the same MPLS network. The resulting set of interconnected LERs forms a private MPLS VPN where each LSP is uniquely identified at each MPLS interface by a label. 2. Bridging Model for MPLS An MPLS interface acting as a bridge must be able to flood, forward, and filter bridged frames. Lasserre, Kompella et al. [Page 4]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 +----+ +----+ + C1 +---+ ........................... +---| C1 | +----+ | . . | +----+ Site A | +----+ +----+ | Site B +---| PE |---- MPLS Cloud ----| PE |---+ +----+ | +----+ . | . . | . . +----+ . ..........| PE |........... +----+ ^ | | | +-- Logical bridge +----+ | C1 | +----+ Site C The set of PE devices interconnected via MPLS appears as a single 802.1d bridge/switch to customer C1. Each PE device will learn remote MAC addresses on LSPs (and keeps learning directly attached MAC addresses on customer facing ports). The scope of the VPLS lies within the PEs in the service provider network, highlighting the fact that apart from customer service delineation, the form of access to a customer site is not relevant to the VPLS [VPLS-REQ]. The PE device is typically an edge router capable of running a signaling protocol and/or routing protocols to exchange VC label information. In addition, it is capable of setting up transport tunnels to other PEs to deliver VC LSP traffic. 2.1 Flooding and Forwarding Flooding within the service provider network is performed by sending unknown unicast and multicast frames to all relevant PE nodes participating in the VPLS. In the MPLS environment this means sending the PDU through each relevant VC LSP. Note that multicast frames do not necessarily have to be sent to all VPN members. For simplicity, the default approach of broadcasting multicast frames can be used. Extensions explaining how to interact with 802.1 GMRP protocol, IGMP snooping and static MAC multicast filters will be discussed in a future revision. To forward a frame, a bridge must be able to associate a destination MAC address with a VC LSP. It is unreasonable and perhaps impossible Lasserre, Kompella et al. [Page 5]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 to require bridges to statically configure an association of every possible destination MAC address with a VC LSP. Therefore, MPLS bridges must provide enough information to allow an MPLS interface to dynamically learn about foreign destinations beyond the set of LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to the encapsulation described within [MARTINI-ENCAP]. 2.2 Address Learning Unlike BGP VPNs [BGP-VPN], reachability information does not need to be advertised and distributed via a control plane. Reachability is obtained by standard learning bridge functions in the data plane. Since VC LSPs are uni-directional, two LSPs of opposite directions are required to form a logical bi-directional link. When a new MAC address is learned on an inbound LSP, it needs to be associated with the outbound LSP that is part of the same pair. The state of this logical link can be considered as up as soon as both incoming and outgoing LSPs are established. Similarly, it can be considered as down as soon as one of these two LSPs is torn down. 2.3 LSP Topology PE routers typically run an IGP between them, and are assumed to have the capability to establish MPLS tunnels. Tunnel LSPs are set up between PEs to aggregate traffic. VC LSPs are signaled to demultiplex the L2 encapsulated packets that traverse the tunnel LSPs. In this Ethernet L2VPN, it becomes the responsibility of the service provider to create the loop free topology, since the PEs have to examine the Layer 2 fields of the packets, unlike Frame Relay or ATM, where the termination point becomes the CE node. Therefore, for the sake of simplicity, we assume that the topology of a VPLS is a full mesh of tunnel and VC LSPs. 2.4 Loop free L2 VPN In order to avoid running a STP instance per VPN, which would not scale, partial mesh configurations of VC LSPs are not allowed. Note that customers are allowed to run STP such as when a customer has a back door link used for backup. In such a case STP BPDUs are simply tunneled through the MPLS cloud. Each PE MUST create a rooted tree to every other PE router that serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme in order to prevent loops, that is, a PE MUST NOT forward traffic from one VC LSP to another in the same VPN (since each PE has direct connectivity to all other PEs in the same VPN). Lasserre, Kompella et al. [Page 6]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 2.5 LDP Based Signaling Once an LDP session has been formed between two PEs, all VC LSPs are signaled over this session. In [MARTINI-SIG], the L2 VPN information is carried in a Label Mapping message sent in downstream unsolicited mode, which contains the following VC FEC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC tlv |C| VC Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VC, C, VC Info Length, Group ID, Interface parameters are as defined in [MARTINI-SIG]. This document defines a new VC type value in addition to the following values already defined in [MARTINI-SIG]: VC Type Description 0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC 0x0007 PPP 0x8008 CEM [8] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport 0x000B Ethernet VPLS VC types 0x0004 and 0x0005 identify VC LSPs that carry tagged and untagged Ethernet traffic respectively, for point-to-point connectivity. Lasserre, Kompella et al. [Page 7]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 We define a new VC type, Ethernet VPLS, with codepoint 0x000B to identify VC LSPs that carry Ethernet traffic for multipoint connectivity. The Ethernet VC Type is described below. For VC types 0x0001 to 0x000A, The VC ID identifies a particular VC. For the VPLS VC type, the VC ID is a VPN identifier globally unique within a service provider domain. 2.6 Ethernet VPLS VC Type 2.6.1. VPLS Encapsulation actions In a VPLS, a customer Ethernet packet without preamble is encapsulated with a header as defined in [MARTINI-ENCAP]. A customer Ethernet packet is defined as follows: - If the packet, as it arrives at the PE, has an encapsulation that is used by the local PE as a service delimiter, then that encapsulation is stripped before the packet is sent into the VPLS. As the packet exits the VPLS, the packet may have a service-delimiting encapsulation inserted. - If the packet, as it arrives at the PE, has an encapsulation that is not service delimiting, then it is a customer packet whose encapsulation should not be modified by the VPLS. This covers, for example, a packet that carries customer specific tags that the service provider neither knows about nor wants to modify. By following the above rules, the Ethernet packet that traverses a VPLS is always a customer Ethernet packet. Note that the two actions, at ingress and egress, of dealing with service delimiters are local actions that neither PE has to signal to the other. They allow, for example, a mix-and-match of tagged and untagged services at either end, and do not carry across a VPLS a tag that may have only local significance. The service delimiter may be a VC label also, whereby an Ethernet VC given by [MARTINI-ENCAP] can serve as the access side connection into a PE. An RFC1483 PVC encapsulation could be another service delimiter. 2.6.2. VPLS Learning actions Learning is done based on the customer Ethernet packet, as defined above. The Forwarding Information Base (FIB) keeps track of the mapping of customer Ethernet packet addressing and the appropriate VC label to use. We define two modes of learning: qualified and unqualified learning. In qualified learning, the learning decisions at the PE are based on the customer Ethernet packet's MAC address and VLAN tag, if one exists. If no VLAN tag exists, the default VLAN is assumed. Lasserre, Kompella et al. [Page 8]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 Effectively, within one VPLS, there are multiple logical FIBs, one for each customer VLAN tag identified in a customer packet. In unqualified learning, learning is based on a customer Ethernet packet's MAC address only. In other words, a At any PE, there is only one FIB per VPLS, which maps the MAC address in a customer Ethernet packet to a VC label. 2.6.3. VPLS Forwarding actions The forwarding decisions taken at a PE couple with the learning mode. When using unqualified learning, unknown destination packets are flooded to the entire VPLS. When using qualified learning, the scope of the flooding domain may be reduced (to the scope of the customer VLAN). How this may be achieved is outside the scope of this draft. It is important to ensure that the above learning and forwarding modes are used consistently across the VPLS. For example, when the intention is to use qualified learning, duplicate MAC addresses with different VLAN tags should not trigger re-learn events, which will lead to incorrect forwarding decisions. We propose that signaling an optional parameter in the VC FEC will provide an adequate guard against such misconfigurations. By default, the behavior is unqualified learning. In order to signal the learning mode, we introduce a new interface parameter [MARTINI-SIG]. Optional Interface Parameter 0x06 VPLS Learning Mode Length: 1 byte. Value: 0 - unqualified learning 1 - qualified learning 3. MAC Address Withdrawal It MAY be desirable to remove MAC addresses that have been dynamically learned for faster convergence. We introduce a MAC TLV that is used to specify a list of MAC addresses that can be removed using the Address Withdraw Message. The Address Withdraw message with MAC TLVs MAY be supported in order to uninstall learned MAC addresses that have moved or gone away more quickly. Once a MAC address is unlearned, re-learning occurs through flooding, so the Address message only prevents flooding. Lasserre, Kompella et al. [Page 9]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 3.1 MAC TLV MAC addresses to be unlearned can be signaled using an LDP Address Withdraw Message. We define a new TLV, the MAC TLV. Its format is described below. The encoding of a MAC TLV address is a 2-byte 802.1q tag, followed by the 6-byte MAC address encoding specified by IEEE 802 documents [802.1D-ORIG] [802.1D-REV]. The 802.1q tag and the MAC address MUST appear in pairs. If no tag is required, the value of the tag field MUST be zero. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 802.1q Tag #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 802.1q Tag #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown bit. This bit MUST be set to 0. If the MAC address format is not understood, then the TLV is not understood, and MUST be ignored. F bit Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is Targeted, the TLV MUST NOT be forwarded. Type Type field. This field MUST be set to 0x0404 (subject to IANA approval). This identifies the TLV type as MAC TLV. Length Length field. This field specifies the total length of the TLV, including the Type and Length fields. Reserved Reserved bits. They MUST NOT be interpreted at the receiver, and MUST be set to zero by the sender. 802.1q Tag The 802.1q Tag. The value MUST be zero if the Ethernet VLAN encapsulation is used. If the Ethernet encapsulation is used, and the Ethernet address is associated with a VLAN, it MUST be set to Lasserre, Kompella et al. [Page 10]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 the VLAN tag. If the Ethernet encapsulation is used, and the MAC address is not associated with a VLAN, it MUST be set to zero. Since an 802.1q tag is 12-bits, the high 4 bits of the field MUST be set to zero. MAC Address The MAC address being removed. The LDP Address Withdraw Message contains a FEC TLV (to identify the VPLS in consideration), a MAC Address TLV and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. 3.2 Address Withdraw Message Containing MAC TLV When MAC addresses are being removed explicitly, e.g., an adjacent CE router has been disconnected, an Address Withdraw Message can be sent with the list of MAC addresses to be withdrawn. The processing for MAC TLVs received in an Address Withdraw Message is: For each (q-tag, MAC address) pair in the TLV: - Remove the association between the (q-tag, MAC address) pair and VC label. It does not matter whether the MAC address was installed as a static or dynamic address. The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. The address list MAY be empty. This tells the receiving LSR to delete any MAC addresses learned from the sending LSR for the VPLS specified by the FEC TLV. 4. Operation of a VPLS We conclude with an example of how VPLS should work. The following discussion uses the figure below, where a VPLS has been set up between PE1, PE2 and PE3. Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full- mesh of tunnels between them for carrying tunneled traffic. The VPLS service is assigned a VCID (a 32-bit quantity that is unique across the provider network across all VPLSs). (Allocation of domain-wide unique VCIDs is outside the scope of this draft.) Lasserre, Kompella et al. [Page 11]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 ----- / A1 \ ---- ____CE1 | / \ -------- ------- / | | | A2 CE2- / \ / PE1 \ / \ / \ / \___/ \ ----- ---- ---PE2 | | Service Provider Network | | ___ | \ / \ / ----- PE3 / \ / |Agg|_/ -------- ------- ____ -| | ____ ---- / ----- ---- / \/ \ / \ CE = Customer Edge Router | A3 CE3 --C4 A4 | PE = Provider Edge Router \____/ \ / Agg = Layer 2 Aggregation ---- ---- For the above example, say PE1 signals VC Label 102 to PE2 and 103 to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3. Assume a packet from A1 is bound for A2. When it leaves CE1, say it has a source MAC address of M1 and a destination MAC of M2. If PE1 does not know where M2 is, it will multicast the packet to PE2 and PE3. When PE2 receives the packet, it will have an inner label of 201. PE2 can conclude that the source MAC address M1 is behind PE1, since it distributed the label 201 to PE1. It can therefore associate MAC address M1 with VC Label 102. 4.1. MAC Address Aging PEs that learn remote MAC addresses need to have an aging mechanism to remove unused entries associated with a VC Label. This is important both for conservation of memory as well as for administrative purposes. For example, if a customer site A is shut down, eventually, the other PEs should unlearn A's MAC address. As with existing LAN bridges, two aging timers SHOULD be implemented on a PE. First, a local aging of MAC addresses learned from the customer-facing network SHOULD be implemented with a shorter value of the timer. Second, a remote aging of MAC addresses learned during the operation of the VPLS SHOULD be implemented with a considerably longer timer value. The remote aging timer keeps entries around longer, since the loss of an entry entails a broadcast across the VPLS to discover the MAC address location. As packets arrive from the customer-facing network, local MAC addresses SHOULD be remembered, along with aging. The aging timer for MAC address M SHOULD be reset when a packet is received from the customer-facing with source MAC address M. Lasserre, Kompella et al. [Page 12]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 As packets arrive from the remote PEs, remote MAC addresses SHOULD be learned. The aging timer for a remote MAC address M SHOULD be reset when a packet arrives from a remote PE with source MAC address M. 5. Security Considerations No new security issues result from this draft. It is recommended in [RFC3036] that LDP security (authentication) methods be applied. This would prevent unauthorized participation by a PE in a VPLS. Using VC labels effects traffic separation for VPLSs. However, for additional levels of security, the customer MAY deploy end-to-end security, which is out of the scope of this draft. 6. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 7. 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. Lasserre, Kompella et al. [Page 13]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 8. References [MARTINI-ENCAP] "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-03.txt (Work in progress) [MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft- martini-l2circuit-trans-mpls-07.txt (Work in progress) [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 [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", draft-augustyn-vpls-requirements-00.txt (Work in progress). [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. January 2001. 9. Author's Addresses Marc Lasserre Riverstone Networks 5200 Great America Pkwy Phone: 1-408-878-6550 Santa Clara, CA 95054 Email: marc@riverstonenet.com Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Email: vkompella@timetra.com Nick Tingle TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Email: ntingle@timetra.com Loa Andersson Lasserre, Kompella et al. [Page 14]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 Utfors Bredband AB Phone: +46 8 5270 50 38 Rasundavagen 12 169 29 Solna Email: loa.andersson@utfors.se Pascal Menezes TeraBeam Networks 2300 Seventh Ave Seattle, WA 98121 Email: Pascal.Menezes@Terabeam.com Andrew Smith Fax: +1 415 345 1827 Consultant Email: ah_smith@pacbell.net Pierre Lin Yipes Communication 114 Sansome St Phone: 415-218-9520 San Francisco, CA 94104 Email: pierre.lin@yipes.com Lewis Eatherton Excite@Home 450 Broadway Street Phone: 650-556-5022 Redwood City, CA 94063 Email: leathert@excitehome.net Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Email: giles@packetexchange.net Juha Heinanen Song Networks, Inc. Tom S. C. Soon SBC Technology Resources Inc. 4698 Willow Road Pleasanton, CA 94588 sxsoon@tri.sbc.com Rick Wilder Masergy Inc. 2901 Telestar Ct. Falls Church, VA 22042 Luca Martini Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 Email: luca@level3.net Nick Slabakov Riverstone Networks Lasserre, Kompella et al. [Page 15]
Internet Draft draft-lasserre-vkompella-ppvpn-tls-00.txt Nov 2001 5200 Great America Pkwy Phone: 1-303-471-6926 Santa Clara, CA 95054 Email: nslabakov@riverstonenet.com Rob Nath Riverstone Networks 5200 Great America Pkwy Phone: 1-408-878-6742 Santa Clara, CA 95054 Email: rnath@riverstonenet.com Lasserre, Kompella et al. [Page 16]