One document matched: draft-sajassi-mvpls-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:00:53 |