PPVPN Working Group Ali Sajassi Internet Draft Hussein Salama Expiration Date: May 2003 Cisco Systems November 2002 VPLS based on IP Multicast draft-sajassi-mvpls-00.txt 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 obsolete 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. Abstract Virtual Private LAN Service (VPLS) is a type of Layer-2 Provider Provisioned Virtual Private Network (L2 PPVPN) offered service, which has been described in [PPVPN-FRWK]. If the Service Provider network provides IP multicast functionality, then this network capability can be leveraged in providing very efficient VPLS service and yet simplifying the implementation of such service. This document describes a solution for providing VPLS service based on IP multicast feature referred to as Multicast Virtual Private LAN Service (MVPLS). [Page 1] Internet Draft draft-sajassi-mvpls-00.txt November 2002 1. Boilerplate for Sub-IP Area Drafts RELATED DOCUMENTS draft-ietf-ppvpn-l2-framework-00.txt draft-lasserre-vkompella-ppvpn-vpls-02.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 for Virtual Private LAN Service (VPLS), which is a type of Provider-Provisioned Layer 2 VPN offered services. JUSTIFICATION This document describes a solution for providing VPLS, which is a type of Layer-2 Provider Provision Virtual Private Network (L2 PPVPN) offered service described in [PPVPN-FRWK] 2. Introduction Virtual Private LAN Service (VPLS) is a type of Layer-2 Provider Provisioned Virtual Private Network (L2 PPVPN) offered service, which has been described in [PPVPN-FRWK]. VPLS emulates a LAN segment across providerÆs MAN/WAN network such that to CE devices of a customer (switches, routers, or hosts), it looks as if they are all on the same LAN. A solution for providing such service is presented in [VPLS] that describes how an architecture with a two-level hierarchy can be used to provide this service in a scalable way. [VPLS] solution neither discusses nor makes any assumptions regarding the auto-discovery approach since the architecture is independent of it. However, it makes an explicit assumption regarding the type of Pseudowire (PW) used in the solution, which is Point-to-Point. If the Service Provider network provides IP multicast functionality, then this network capability can be leveraged in providing very efficient VPLS service and yet simplifying the implementation of such service. This document describes an alternative solution for providing VPLS service based on IP multicast feature referred to as Multicast Virtual Private LAN Service (MVPLS). MPVLS utilizes both access and core network bandwidth very efficiently by replicating broadcast/multicast and unknown unicast frames as close Sajassi, et al Expires May 2003 [Page 2] Internet Draft draft-sajassi-mvpls-00.txt November 2002 to the egress PE as possible. It also simplifies the service implementation since it has an inherent auto-discovery mechanism and thus there is no need for explicit mechanisms such as [BGP-AUTODISC] or [DNS-AUTODISC]. Also for the default case of IP network, the operation gets further simplified since there is no need for signaling of PWs (e.g., L2TPv3 encapsulation can be used without the corresponding signaling protocol). MVPLS relies on two key components: MultiPoint-to-Point Pseudowire (MPtP PW): This PW is intended for known unicast Ethernet frames and it is associated with a single Attachment Circuit (AC) of a VPLS. Using this PW, the ingress PE can forward a packet to a specific AC on the egress PE. MultiPoint-to-MultiPoint Pseudowire (MPtMP PW): This PW is intended for unknown unicast frames or broadcast/multicast frames and it is associated with a VPLS instance. Using this PW, the ingress PE can forward a packet to all the ACs on the egress PEs associated with this VPLS instance. Each MPtP PW is represented by a unique unicast IP address and each MPtMP PW is also represented by a unique IP multicast group address. A MPtP PW usually represents a single AC (although there are some exceptions as will be seen later) and a MPtMP PW represents a single VPLS instance. Since the IP address for MPtP PW corresponds to a specific AC on the egress PE (e.g., to a sub-interface on the egress PE), there is no need to do MAC address lookup for packet forwarding at the egress PE, which makes the operation more efficient for the egress PE. However, at the ingress PE, the MAC address lookup is needed in order to select the proper MPtP PW associated with a given destination MAC address (MAC DA). Therefore, in contrast to [VPLS], the forwarding operation of MVPLS is asymmetric and MAC address lookup for packet forwarding is only used at the ingress PE. 3. Overview The following figure shows the MVPLS topology. The service provider backbone network can be either IP-based or MPLS-based. In the following sections, we discuss the operation of MVPLS over an IP backbone. Special considerations for the case of an MPLS backbone are discussed in Section 10.1. As shown in the figure, the CEs can either be directly connected to a PE or they can be connected via an aggregator device referred to as U- Sajassi, et al Expires May 2003 [Page 3] Internet Draft draft-sajassi-mvpls-00.txt November 2002 PE (User facing PE) in which case the PE itself is referred to N-PE (Network facing PE) with respect to those CEs. For example, CE1, CE1Æ, CE2, CE2Æ, and CE3 are directly connected to their corresponding PEs. For this case, a customer AC can be identified by the physical port identifier or, in the case of customers using VLANs, by the combination of the physical port plus the customerÆs VLAN identifier. This draft uses this case as a basis for discussion. Also in the figure below, the U-PE aggregates the ACs from CE4 and CE4Æ and tunnels them to the N-PE using QinQ. Special considerations for this case are discussed in Section 10.2. +----+ +----+ +CE1 +--+ +---------------|CE2 | +----+ | ........................ | +----+ MVPLS A | +------+ +------+ | MVPLS A +--| PE |-- Service ----| PE |-+------+ +----+ +------+ Provider | N-PE | +-------|CE2Æ| / . Backbone +------+ +----+ / . | . \ MVPLS B +----+ / . | . \ +CE1Æ+--+ . | . \ +----+ . +----+ . \ QinQ MVPLS B .........| PE |......... \ +----+ \ | \ | \ +----+ +------+ +----+ |CE3 | | U-PE |---|CE4 | +----+ +------+ +----+ MVPLS A | MVPLS A | | +----+ +------|CE4Æ| +----+ MVPLS B A customer CE is attached to a PE via the corresponding AC. Each AC is associated with one VPLS instance and furthermore a unique IP address is assigned to each AC. This IP address is used for pseudo-wire identification and is used by the ingress PE to forward a unicast packet directly to a specific AC on the egress PE without the need for MAC address lookup on the egress PE. This will be discussed in detail in Section 4. Sajassi, et al Expires May 2003 [Page 4] Internet Draft draft-sajassi-mvpls-00.txt November 2002 Some devices do not have the ability to have a unique IP address assigned to each AC (e.g., interface/sub-interface). Such a device should be configured with one IP address for each VPLS instance that is active on that device. The Forwarding operation at the egress PE is different in that case and will be discussed in Section 9. MVPLS associates one IP multicast group with each VPLS instance. Each PE that participates in a given VPLS must join the corresponding IP multicast group. The resulting multicast tree(s) is a MPtMP PW. All multicast frames, broadcast frames, and frames to an unknown destination for a given VPLS instance are forwarded to the multicast group address corresponding to that VPLS. MVPLS has several advantages when compared to the unicast-based VPLS schemes. The use of multicast results in efficient packet replication. Packets are replicated as close as possible to the egress PE(s), which results in efficient use of the network bandwidth and relieves the ingress PE from having to replicate the packets to all destinations. The use of IP multicast also eliminates the need for a dedicated auto- discovery mechanism. In MVPLS, a PE does not need to discover the IDs and/or addresses of the other PEs participating in the same VPLS instance. When a PE joins the multicast group corresponding to a given VPLS instance, it can reach all other PEs participating in the same VPLS instance without needing to have explicit knowledge of their identities. Another reason why a PE does not need to explicitly know the identities/IP addresses of the other PEs is that there is no PE- specific pseudo-wire signaling in MVPLS. Finally, MVPLS does not use VPN-ids. In MVPLS, pseudo-wires are uniquely identified using IP addresses only. Therefore, there is no need to carry VPN-id or session-id inside the PW PDU. The multicast group address associated with a given VPLS must be provisioned on each PE which participates in that VPLS. Therefore, a multicast group address in a PE identifies a VPLS instance and its associated forwarding table on that PE. When an AC is configured in a PE, it is associated with a VPN-id, which in turn corresponds to a unique multicast group address. The VPN-id can be the same as multicast group address or it can be a standard ID that corresponds to a multicast group address. Sajassi, et al Expires May 2003 [Page 5] Internet Draft draft-sajassi-mvpls-00.txt November 2002 4. Pseudo-Wires 4.1. Multipoint-to-Point Pseudo-Wire One MPtP PW is created for every AC. No explicit signaling is required for creating this MPtP PW. The pseudo-wire is identified using the IP address assigned to that AC (i.e., the IP address assigned to the interface/sub-interface corresponding to that AC). An ingress PE encapsulates a unicast frame to a known destination (i.e., a MAC DA for which an entry exists in the forwarding table at the ingress PE) with an IP header. The ingress PE sets the destination IP address in the IP header to the IP address associated with the destination AC (-i.e., the AC over which the MAC DA has been learned). 4.2. Multipoint-to-Multipoint Pseudo-Wire A single MPtMP PW is created for each VPLS instance. This PW is identified by a unique IP multicast group address. A PE connects to the MPtMP PW for a given VPLS instance by joining the corresponding multicast group using standard multicast tree construction mechanisms (e.g., by initiating a PIM Join). When the first AC is configured for a VPLS instance in a PE, that PE joins the multicast group. All subsequent ACs that get configured for that VPLS instance donÆt trigger any additional join messages to be sent from that PE. However, the ACs do join the multicast group on that PE but this is an internal process for that PE. When ACs for a VPLS instance get decommissioned, no withdrawal messages get sent out from that PE unless the last AC for that VPLS instance get decommissioned. In this case, the PE withdraws from the multicast group (e.g., the PE sends out a PIM Prune message). Multiple multicast tree protocols exist. The choice of a specific multicast protocol will be discussed in Section 12. All broadcast frames, multicast frames, and unicast frames to unknown destinations (i.e., MAC addresses for which no entry exists in the forwarding table at the ingress PE) are forwarded over the MPtMP PW to all destination PEs associated with that VPLS. These frames are encapsulated with an IP header. The ingress PE sets the destination IP address in the IP header to the IP multicast group address associated with that VPLS instance. 5. Encapsulation Both MPtP and MPtMP PWs have the same encapsulation format. An Ethernet frame is encapsulated with an L2TPV3 header (or modified version of it) Sajassi, et al Expires May 2003 [Page 6] Internet Draft draft-sajassi-mvpls-00.txt November 2002 and an IP header. The source IP address is set to the address associated with the AC from which the ingress PE received the frame. The destination IP address is set to the IP address identifying the associated PW. In case of a MPtP PW, this is a unicast IP address and in case of a MPtMP PW, this is an IP multicast group address. 6. The Forwarding Table Although the MAC address lookup is performed only on the ingress PE as mentioned previously, the MAC address learning is done at both ingress and egress PEs. In the ingress PE, source MAC addresses (MAC SAs) are learned in relationship to the ACs over which they are received; whereas, in the egress PE, MAC SAs are learned in relationship to the PWs over which they are received. Therefore, the forwarding table for a given VPLS instance contains MAC addresses and their corresponding adjacencies information. An adjacency information entry can represent either an AC or a PW. In case of an AC, it represents port-id or port- id + VLAN-id and in case of a PW, it represents PW IP-address. 7. Auto-Discovery and Pseudo-Wire Signaling In [VPLS], auto-discovery is used to discover member PEs belonging to the same VPLS instance and then a PtP signaling channel is established for PW signaling between a given PE and all other discovered PEs. However, as previously noted, MVPLS does not use any explicit auto- discovery mechanisms since PEs participating in the same VPLS instance do not need to setup any point-to-point signaling channel and thus they do not need to gain explicit knowledge of one another. Auto-discovery for MVPLS is done implicitly through the IP multicast mechanism and a PE becomes a member of the VPLS by joining the corresponding multicast tree. When a PE is configured with a new AC, it is also configured with the VPN-id that corresponds to the multicast group address of the MPtMP PW for that VPLS instance. Assuming no other ACs associated with the same VPLS instance are already configured on that PE, the PE immediately joins that multicast group, and starts receiving IP multicast packets whose MPtMP PW payload contains Ethernet broadcast/multicast frames and unknown unicast frames. The PE uses a MPtMP PW associated with a VPLS instance to discover the MPtP PWs associated with the same VPLS instance and also to announce to other PEs the MPtP PW associated with the newly configured AC. Sajassi, et al Expires May 2003 [Page 7] Internet Draft draft-sajassi-mvpls-00.txt November 2002 8. Forwarding and Learning Operations 8.1. MAC Address Learning at Ingress PE When an ingress PE receives an Ethernet frame from a specific AC, it looks up the MAC SA of the frame in the corresponding forwarding table. If the MAC SA is not found, the PE learns the new source address and adds an entry to the forwarding table for that new address. The forwarding information for that new entry is set to AC-id over which the MAC SA is learned. The AC-id can be either a port-id or port-id + vlan-id. In cases where, the AC is a non-Ethernet type (e.g., ATM or FR VC), then the AC-id is the id of the corresponding VC. The ingress PE then continues processing the frame as will be discussed in Sections 8.3 and 8.4. 8.2. MAC Address Learning at Egress PE When an egress PE receives an MVPLS packet from the core, it determines which VPLS this packet is associated with based on the destination IP address of the packet. The egress PE then looks up the MAC SA of the frame in the forwarding table. If the source address is not found, the PE learns the new source address and adds an entry for that new address to the table. The forwarding information for that new entry is set to MPtP PW-id which is the unicast IP address associated with the MPtP PW. The egress PE then continues processing the frame as will be discussed in Sections 8.3 and 8.4. 8.3. Forwarding of Known-MAC-DA Unicast Frames After the ingress PE performs the MAC SA lookup, and learning (if needed), as has been described in Section 8.1, the ingress PE checks the MAC DA. If the destination address is a unicast address, the ingress PE looks up this address in the forwarding table for that VPLS instance. If an entry is found, one of the following two actions is taken: . If the entry is an AC-id, then encapsulating the Ethernet frame with L2TPv3 header and IP header may or may not be needed depending on the internal architecture of the PE. If needed, then it gets handled the same way as PW VC type. Otherwise, the frame is directly forwarded to the destination AC. Sajassi, et al Expires May 2003 [Page 8] Internet Draft draft-sajassi-mvpls-00.txt November 2002 . If the entry is a PW-id, then the ingress PE encapsulates the frame with an L2TPv3 header and an IP header. The source IP address is set to the address of the AC over which the frame arrived and the destination IP address is set to the PW IP address looked up in the VPLS forwarding table. The ingress PE then forwards the IP packet into the core. When an egress PE receives a unicast MVPLS packet from the core, it performs the MAC SA lookup, and possibly learning, as has been described in Section 8.2. The egress PE does not lookup the MAC DA of the received frame since the destination IP address of the received packet readily identifies the interface associated with the AC. The packet is immediately delivered to that interface. The IP header and the L2TPv3 header are removed before the Ethernet frame gets forwarded over the AC towards its destination. 8.4. Forwarding of Unknown-MAC-DA Unicast or Multicast/Broadcast Frames After the ingress PE performs the MAC SA lookup, and learning (if needed), as has been described in Section 8.1, the ingress PE checks the MAC DA. If the destination address is a unicast address, the ingress PE looks up this address in the forwarding table for that VPLS instance. If no entry exists for this destination address, the frame must be broadcast to all sites participating in that VPLS. The following actions must be taken: . The ingress PE replicates the frame to all local ACs participating in the same MVPLS, except the AC over which the frame has arrived. . The ingress PE encapsulates the frame with an L2TPv3 header and an IP header. The source IP address is set to the address of the Attachment VC over which the frame arrived and the destination IP address is set to the IP multicast group address associated with the VPLS instance. The ingress PE then forwards the packet into the core. Replication of this multicast packet is done efficiently by the multicast enabled PE routers and the core routers. All PEs participating in a given VPLS, except the ingress PE, receive the multicast packet. When an egress PE receives an MVPLS packet from the core, it identifies the corresponding VPLS instance based on the destination multicast group address and it replicates and forwards the packet to all the destination ACs associated with that multicast group address (with that VPLS instance). It also performs the MAC SA lookup, and learning if needed, as has been described in Section 8.2. Sajassi, et al Expires May 2003 [Page 9] Internet Draft draft-sajassi-mvpls-00.txt November 2002 9. MAC Address Lookup on Egress PEs So far, we assumed that each AC is assigned to a unique IP address and thus can be associated with a unique MPtP PW. This implies that the packet encapsulation/ decapsulation is done at the ACs (customer-facing interfaces). However, some PEs are not capable of performing PW processing at their ACs and thus a MPtP PW can not be extended all the way to an AC. In this case, the PE assigns a unique IP address to each VPLS instance instantiated on it. Therefore, the MPtP PW is associated with a VPLS instance for that PE instead of an AC. In such scenarios, the packet forwarding on the egress PE for a MPtP PW requires MAC address lookup on the egress PE in order to select the appropriate AC. Besides this difference, the rest of the operation for MPtP and MPtMP remains same as before. 10. Other Network Types 10.1. MPLS Network So far, our discussion only considered implementing MVPLS over an IP core. However, MVPLS is independent of the core transport. It can also be implemented over an MPLS core. In that case each MPtP PW will correspond to one MPLS LSP (one-to-one mapping). To make this possible, the IGP running in the core must not aggregate the IP addresses used to identify the MPtP PWs. Since thereÆs a one-to-one mapping between MPtP PWs and MPLS LSPs, an egress PE can forward an MPLS packet arriving from the core to the appropriate AC based on the MPLS label without having to look it up in the forwarding table. This forwarding behavior for MPtP PW is the same as the one in IP networks. The situation is more complicated for transporting IP multicast over an MPLS core. A framework for transporting IP multicast over MPLS is presented in [MC-MPLS]. However, no standard solutions for that problem exist yet. Therefore, we propose transporting the MPtMP PWÆs traffic using IP multicast packets across the core as before, i.e., without MPLS encapsulation. 10.2. QinQ Access Network MVPLS supports QinQ access network very easily and the operation is basically the same as before with just one small change to AC identification. Since the packets that come to the N-PE, carry double VLAN tags and the outer tag (ProviderÆs VLAN û P-VLAN) represents the VPLS instance, then the P-VLAN needs to be used in the AC Sajassi, et al Expires May 2003 [Page 10] Internet Draft draft-sajassi-mvpls-00.txt November 2002 identification of the N-PE. If the offered service is TLS and thus transparent to the customerÆs VLANs, then the AC on the N-PE is identified by Port + P-VLAN. However, if the offered service is per customer VLAN (C-VLAN), then the AC needs to be identified by port + P- VLAN + C-VLAN. Once an AC is identified, then the association of that AC to MPtP PW or MPtMP PW is done exactly as described before. Also forwarding of unicast and broadcast/multicast packets from/to the AC to/from the MPtP PW or the MPtMP PW is performed same as before. MAC address learning associated with the ACs also works the same way except the AC is now represented by this new id. 11. Packet Ordering Since MVPLS uses a MPtMP PW (for unknown unicast frames) which is different from MPtP PW, there can be situations where the unicast frames arrive at the destination out of sequence. For example, a unicast frames with unknown MAC DA gets sent over MPtMP PW; whereas, as soon as that MAC DA is learned it gets sent over the MPtP PW. If the MPtMP path has longer delay than MPtP path, then there can be situations where two consecutive frames can arrive at the destination out of sequence. To alleviate this situation, the delay through MPtMP path should be minimized and be close to the one for MPtP path. The closer the delay of MPtMP path to MPtP path, the less chances of out- of-sequence delivery such that if the delay between the two paths is the same, then there is no possibility for out-of-sequence delivery in steady state. 12. Multicast choice Multiple IP multicast mechanisms exist. One main differentiation of IP multicast today is the service available to a host. [IP-MC] describes the traditional IP multicast service model, which today is being called ASM (Any Source Multicast). In ASM, a receiver host simply joins an IP multicast group and receives the traffic from all source sending to that group. [SSM] describes a different service model, SSM (Source Specific Multicast), which differs from ASM in that it requires a receiver to explicitly specify from which source it wants to receive IP multicast traffic sent to a particular IP multicast group. In MPVLS, the PE function requires ASM because it relies on the automatic discovery of sources (i.e., other MVPLS PE devices) sending to an IP multicast group. Sajassi, et al Expires May 2003 [Page 11] Internet Draft draft-sajassi-mvpls-00.txt November 2002 For ASM, various IP multicast routing protocols exist. Choosing the right one has effects on the performance of the MVPLS service. Two ASM-based IP multicast routing protocols that have existing implementations and exhibit scaling and performance characteristics that make them suitable for deployment in a service providerÆs backbone network are PIM SM and PIM Bidir. Both protocols can be used with MVPLS. PIM SM constructs one shortest path tree for each (S,G) pair, where S is a source address and G is a multicast group address. PIM Bidir, on the other hand, constructs a single tree to be shared by all sources transmitting to the same multicast group G. The shared tree is denoted a (*,G) tree. The use of multiple trees in the case of PIM SM requires the network to maintain more state than the use of a single tree in the case of PIM Bidir. However, PIM SMÆs shortest path trees result in more optimal forwarding paths. In PIM SM, a destination initially joins a shared (*,G) tree for a given multicast group. The destination then discovers the active sources for that multicast group via the shared (*,G) tree and joins the shortest path (S,G) tree of each of these active sources. Note that even though PIM Bidir constructs a sub-optimal shared forwarding tree, MVPLS using PIM Bidir still results in more efficient utilization of the network bandwidth than the unicast-based VPLS solutions, which require the ingress PE to replicate all broadcast frames, multicast frames, and frames to unknown destinations to all egress PEs associated with the same VPLS. MVPLS implementations should use multicast group addresses from the administratively scoped address range, 239.0.0.0 to 239.255.255.255 [SCPD-MC]. The MVPLS multicast trees should be bounded by the service providers PE routers. Hosts or routers outside the service providerÆs backbone should not be permitted to join the MVPLS multicast trees. Mechanisms for bounding the scope of a multicast tree exist but are outside the scope of this draft. 13. Security Considerations The security aspects of this solution will be discussed at a later time. 14. Acknowledgements Sajassi, et al Expires May 2003 [Page 12] Internet Draft draft-sajassi-mvpls-00.txt November 2002 The authors would like to thank Toerless Eckert for his helpful discussions and feedbacks. 15. References [VPLS] ôVirtual Private LN Service over MPLSö, Lasserre et al, draft- lasserre-vkompella-ppvpn-vpls-02.txt, June 2002 (work in progress) [PPVPN-FRWK] ôPPVPN L2 Frameworkö, Loa Anderson, draft-ietf-ppvpn-l2- framework-01.txt [BGP-AUTODISC] ôUsing BGP as an Auto-Discovery Mechanism for Network Based VPNsö, Ould-Brahim et al., draft-ietf-ppvpn-bgpvpn-auto-02.txt, February 2002, (work in progress) [DNS-AUTODISC] ôDNS/LDP Based VPLSö, Juha Heinanen, draft-heinanen-dns- ldp-vpls-00.txt, January 2002 (work in progress) [MC-MPLS] "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment", D. Ooms, RFC 3353 [IP-MC] "Host Extensions for IP Multicasting", S. Deering et. al., RFC 1112 [PIM-SM] "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", D. Estrin et. al., RFC 2362 [PIM-BIDIR] "Bi-directional Protocol Independent Multicast (BIDIR- PIM)", M. Handley et. al., draft-ietf-pim-bidir-04.txt [SSM] "An Overview of Source-Specific Multicast (SSM)", S. Bhattacharyya et. al., draft-ietf-ssm-overview-04.txt [SCPD-MC] "Administratively Scoped IP Multicast", D. Meyer, RFC 2365 16. Authors' Addresses Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com Hussein Salama Sajassi, et al Expires May 2003 [Page 13] Internet Draft draft-sajassi-mvpls-00.txt November 2002 Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: hsalama@cisco.com Sajassi, et al Expires May 2003 [Page 14]