draft-ietf-mpls-multicast-00.txt   draft-ietf-mpls-multicast-01.txt 
MPLS Working Group D. Ooms, W. Livens
Internet Draft B. Sales, M. Ramalho Network Working Group D. Ooms, B. Sales
Expiration Date: December 1999 Alcatel Internet Draft Alcatel
A. Acharya, F. Griffoul Expiration Date: November 2000 W. Livens
NEC Colt Telecom
A. Acharya
IBM
F. Griffoul
Ulticom
F. Ansari F. Ansari
Bell Labs Bell Labs
June 1999 May 2000
Framework for IP Multicast in MPLS Framework for IP Multicast in MPLS
draft-ietf-mpls-multicast-00.txt
draft-ietf-mpls-multicast-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 15 skipping to change at page 3, line 17
DVMRP Distant Vector Multicast Routing Protocol DVMRP Distant Vector Multicast Routing Protocol
FR Frame Relay FR Frame Relay
IGMP Internet Group Management Protocol IGMP Internet Group Management Protocol
IP Internet Protocol IP Internet Protocol
L2 layer 2 (e.g. ATM, Frame Relay) L2 layer 2 (e.g. ATM, Frame Relay)
L3 layer 3 (e.g. IP) L3 layer 3 (e.g. IP)
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
LSRd Downstream LSR LSRd Downstream LSR
LSRu Upstream LSR LSRu Upstream LSR
MIP Multicast Internet Protocol
MOSPF Multicast OSPF MOSPF Multicast OSPF
mp2mp multipoint-to-multipoint mp2mp multipoint-to-multipoint
p2mp point-to-multipoint p2mp point-to-multipoint
PIM-DM Protocol Independent Multicast-Dense Mode PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode PIM-SM Protocol Independent Multicast-Sparse Mode
QoS Quality of Service QoS Quality of Service
RP Rendezvous Point RP Rendezvous Point
RPF Reverse Path Forwarding RPF Reverse Path Forwarding
RSVP Resource reSerVation Protocol RSVP Resource reSerVation Protocol
SSM Source Specific Multicast
TCP Transmission Control Protocol TCP Transmission Control Protocol
UDP User Datagram Protocol UDP User Datagram Protocol
VC Virtual Circuit VC Virtual Circuit
VCI Virtual Circuit Identifier VCI Virtual Circuit Identifier
VP Virtual Path VP Virtual Path
VPI Virtual Path Identifier VPI Virtual Path Identifier
Changes - clean up references - changes to section of Explicit
Routing - added SSM to multicast protocol taxonomy
1. Introduction 1. Introduction
In an MPLS cloud the routes are determined by a L3 routing protocol. In an MPLS cloud the routes are determined by a L3 routing protocol.
These routes can then be mapped onto L2 paths to enhance network These routes can then be mapped onto L2 paths to enhance network
performance. Besides this, MPLS offers a vehicle for enhanced performance. Besides this, MPLS offers a vehicle for enhanced
network services such as QoS/CoS, traffic engineering, etc. network services such as QoS/CoS, traffic engineering, etc.
Current unicast routing protocols generate a same (optimal) shortest Current unicast routing protocols generate a same (optimal) shortest
path in steady state for a certain (source, destination)-pair. Remark path in steady state for a certain (source, destination)-pair. Remark
that unicast protocols can behave slightly different with regard to that unicast protocols can behave slightly different with regard to
skipping to change at page 6, line 4 skipping to change at page 6, line 10
a) Volatile. Due to the Flood & Prune nature of the protocol, very a) Volatile. Due to the Flood & Prune nature of the protocol, very
volatile tree structures are generated. Solutions to map a dynamic volatile tree structures are generated. Solutions to map a dynamic
L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of
signaling overhead and LSP setup time. The volatile L2 LSP will signaling overhead and LSP setup time. The volatile L2 LSP will
consume a lot of labels throughout the network, which is a consume a lot of labels throughout the network, which is a
disadvantage when label space is limited. disadvantage when label space is limited.
b) Traffic-driven. The router only creates state for a certain group b) Traffic-driven. The router only creates state for a certain group
when data arrives for that group. Routers also independently decide when data arrives for that group. Routers also independently decide
to remove state when an inactivity timer expires. to remove state when an inactivity timer expires.
- Thus LSPs can not be pre-established as is usually done in - Thus LSPs can not be pre-established as is usually done in
unicast. To minimize the time between traffic arrival and LSP unicast. To minimize the time between traffic arrival and LSP
establishment a fast LSP setup method is favorable. establishment a fast LSP setup method is favorable.
- Since creation and deletion of a L3 route at each node is - Since creation and deletion of a L3 route at each node is
triggered by traffic, this suggests that the LSP associated with the triggered by traffic, this suggests that the LSP associated with the
route be setup and torn down in a traffic-driven manner as well. route be setup and torn down in a traffic-driven manner as well.
- If an LSR does not support L3 forwarding this traffic-driven - If an LSR does not support L3 forwarding this traffic-driven
nature even requires that the upstream LSR takes the initiative to nature even requires that the upstream LSR takes the initiative to
create an LSP (upstream or downstream-on-demand label advertisement). create an LSP (Upstream Unsolicited or Downstream on Demand label
advertisement).
3.3. Source/Shared trees 3.3. Source/Shared trees
IP multicast routing protocols create either source trees (S, G), IP multicast routing protocols create either source trees (S, G),
i.e. a tree per source (S) and per multicast group (G), or shared i.e. a tree per source (S) and per multicast group (G), or shared
trees (*, G), i.e. one tree per multicast group (Figure 1). trees (*, G), i.e. one tree per multicast group (Figure 1).
R1 R1 R1 R1 R1 R1
S1 / / / S1 / / /
\ / / / \ / / /
skipping to change at page 6, line 41 skipping to change at page 6, line 47
Figure 1. Shared tree and Source trees Figure 1. Shared tree and Source trees
The advantage of using shared trees, when label switching is applied, The advantage of using shared trees, when label switching is applied,
is that shared trees consume less labels than source trees (1 label is that shared trees consume less labels than source trees (1 label
per group versus 1 label per source and per group). per group versus 1 label per source and per group).
However, mapping a shared tree end-to-end on L2 implies setting up However, mapping a shared tree end-to-end on L2 implies setting up
multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing
mp2mp LSPs boils down to the merging problem discussed earlier. mp2mp LSPs boils down to the merging problem discussed earlier.
Note that in practice shared trees are often only used to discover
new sources of the group and a switchover to a source tree is made at
very low bitrates.
3.4. Co-existence of Source and Shared Trees 3.4. Co-existence of Source and Shared Trees
Some protocols support both source and shared trees (e.g. PIM-SM) and Some protocols support both source and shared trees (e.g. PIM-SM) and
one router can maintain both (*, G) and (S, G) state for the same one router can maintain both (*, G) and (S, G) state for the same
group G. Two cases of state co-existence are described below. group G. Two cases of state co-existence are described below.
Assume topologies with senders Si and receivers Ri. RP is the Assume topologies with senders Si and receivers Ri. RP is the
Rendezvous Point. Ni are LSRs. The numbers are the interface Rendezvous Point. Ni are LSRs. The numbers are the interface
numbers, Reg is the Register interface. All IGMP and PIM Join/Prune numbers, Reg is the Register interface. All IGMP and PIM Join/Prune
messages are shown in the figures. It is also indicated whether the messages are shown in the figures. It is also indicated whether the
RPT-bit is set for the (S, G) state. RPT-bit is set for the (S, G) state.
skipping to change at page 11, line 21 skipping to change at page 11, line 35
3.7. Loop-free-ness 3.7. Loop-free-ness
Multicast routing protocols which depend on a unicast routing Multicast routing protocols which depend on a unicast routing
protocol suffer from the same transient loops as the unicast protocol suffer from the same transient loops as the unicast
protocols do, however the effect of loops will be much worse in the protocols do, however the effect of loops will be much worse in the
case of multicast. The reason being, each time a multicast packet case of multicast. The reason being, each time a multicast packet
goes around a loop, copies of the packet may be emitted from the loop goes around a loop, copies of the packet may be emitted from the loop
if branches exist in the loop. if branches exist in the loop.
Note that there exist multicast routing protocols which are Currently loop detection is a configurable option in LDP and a
guaranteed loop free [PARS]. Currently loop detection is a decision on the mechanism for loop prevention is postponed.
configurable option in LDP and a decision on the mechanism for loop
prevention is postponed. If loops appear to be a major issue and
MPLS does not handle them properly these guaranteed loop free
protocols have an advantage.
3.8. RPF Check 3.8. RPF Check
Some protocols perform a Reverse Path Forwarding (RPF) check on the Some protocols perform a Reverse Path Forwarding (RPF) check on the
received multicast packets. This mechanism checks whether the packet received multicast packets. This mechanism checks whether the packet
is received on the interface which is on the shortest path to the is received on the interface which is on the shortest path to the
source (or root). This mechanism can introduce problems when source (or root). This mechanism can introduce problems when
explicit routing is used (see section 7). Indeed, explicit routing explicit routing is used (see section 7). Indeed, explicit routing
can construct a tree yielding another incoming interface than the can construct a tree yielding another incoming interface than the
RPF-compatible one. RPF-compatible one.
skipping to change at page 11, line 39 skipping to change at page 12, line 4
Some protocols perform a Reverse Path Forwarding (RPF) check on the Some protocols perform a Reverse Path Forwarding (RPF) check on the
received multicast packets. This mechanism checks whether the packet received multicast packets. This mechanism checks whether the packet
is received on the interface which is on the shortest path to the is received on the interface which is on the shortest path to the
source (or root). This mechanism can introduce problems when source (or root). This mechanism can introduce problems when
explicit routing is used (see section 7). Indeed, explicit routing explicit routing is used (see section 7). Indeed, explicit routing
can construct a tree yielding another incoming interface than the can construct a tree yielding another incoming interface than the
RPF-compatible one. RPF-compatible one.
3.9. Mapping of characteristics on existing protocols 3.9. Mapping of characteristics on existing protocols
The above characteristics are summarized in Table 1 for a non- The above characteristics are summarized in Table 1 for a non-
exhaustive list of existing IP multicast routing protocols: DVMRP exhaustive list of existing IP multicast routing protocols: DVMRP
[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], MIP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM
[PARS], SM [PERL]. [HOLB], SM [PERL].
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|MIP |SM | | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Aggregation |no |no |no |no |no |no |no | |Aggregation |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Flood & Prune |yes |no |no |yes |no |no |option| |Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Tree Type |source|source|shared|source|both |both |shared| |Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |yes |no | |State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |both |bi | |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |yes |yes | |Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |yes |no | |Loop Free |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
|RPF check |yes |yes |no |yes |yes |no |no | |RPF check |yes |yes |no |yes |yes |yes |no |
+------------------+------+------+------+------+------+-----+------+ +------------------+------+------+------+------+------+------+------+
Table 1. Taxonomy of IP Multicast Routing Protocols Table 1. Taxonomy of IP Multicast Routing Protocols
From Table 1 one can derive e.g. that DVMRP will consume a lot of From Table 1 one can derive e.g. that DVMRP will consume a lot of
labels when the Flood & Prune L3 tree is mapped onto a L2 tree. labels when the Flood & Prune L3 tree is mapped onto a L2 tree.
Furthermore since DVMRP uses source trees it experiences no merging Furthermore since DVMRP uses source trees it experiences no merging
problem when label switching is applied. The table can be problem when label switching is applied. The table can be
interpreted in the same way for the other protocols. interpreted in the same way for the other protocols.
4. Mixed L2/L3 forwarding in a single node 4. Mixed L2/L3 forwarding in a single node
skipping to change at page 14, line 26 skipping to change at page 14, line 26
| A N | | A N |
|/ \ \ | |/ \ \ |
| \ \ | | \ \ |
/| \ | /| \ |
B | C | B | C |
| | | |
+-------------+ +-------------+
Figure 8. Mixed L2/L3 forwarding in node A Figure 8. Mixed L2/L3 forwarding in node A
b) Allows a return to L3 for branches which requested lower QoS b) Enables the use of the traffic driven trigger with the Downstream
(section 8). Unsolicited or Upstream on Demand label distribution mode, as
explained in section 5.3.1.
c) Enables the use of the traffic driven trigger with the downstream
or upstream on demand label distribution mode, as explained in
section 5.4.
5. Taxonomy of IP multicast LSP triggers 5. Taxonomy of IP multicast LSP triggers
The creation of an LSP for multicast streams can be triggered by The creation of an LSP for multicast streams can be triggered by
different events, which can be mapped on the well known categories of different events, which can be mapped on the well known categories of
'request driven', 'topology driven' and 'traffic driven'. 'request driven', 'topology driven' and 'traffic driven'.
a) Request driven: intercept the sending or receiving of control a) Request driven: intercept the sending or receiving of control
messages (e.g. multicast routing messages, resource reservation messages (e.g. multicast routing messages, resource reservation
messages). messages).
b) Topology driven: map the L3 tree, which is available in the b) Topology driven: map the L3 tree, which is available in the
Multicast Routing Table, to a L2 tree. The mapping is done even if Multicast Routing Table, to a L2 tree. The mapping is done even if
there is no traffic. there is no traffic.
c) Traffic driven: the L3 tree is mapped onto a L2 tree when data c) Traffic driven: the L3 tree is mapped onto a L2 tree when data
arrives on the tree. arrives on the tree.
Whether the trigger by multicast routing messages is categorized as
request or topology driven is debatable. The constructed L2 tree
will be identical to the one constructed by topology driven methods,
but the definition of request driven [CALL] includes all label
assignments in response to control traffic. In [KATS] the multicast
routing messages trigger is categorized as request driven, so we will
continue using this convention.
5.1. Request driven 5.1. Request driven
5.1.1. General 5.1.1. General
The establishment of LSPs can be triggered by the interception of The establishment of LSPs can be triggered by the interception of
outgoing (requiring that the label is requested by the downstream outgoing (requiring that the label is requested by the downstream
LSR) or incoming (requiring that the label is requested by the LSR) or incoming (requiring that the label is requested by the
upstream LSR) control messages. Figure 9 illustrates these two upstream LSR) control messages. Figure 9 illustrates these two
cases. cases.
LSRu LSRd LSRu LSRd LSRu LSRd LSRu LSRd
-------+ +--- ---+ +------- -------+ +--- ---+ +-------
| control | | control | | control | | control |
<---*<-----message------- <-------message-------*---- <---*<-----message------- <-------message-------*----
skipping to change at page 15, line 42 skipping to change at page 15, line 31
|----data----->| |-----data---->| |----data----->| |-----data---->|
incoming outgoing incoming outgoing
Figure 9. Request driven trigger Figure 9. Request driven trigger
(interception of resp. incoming and outgoing control messages) (interception of resp. incoming and outgoing control messages)
The downstream LSR (LSRd) sends a control message to the upstream LSR The downstream LSR (LSRd) sends a control message to the upstream LSR
(LSRu). In the case that incoming control messages are intercepted (LSRu). In the case that incoming control messages are intercepted
and the MPLS module in LSRu decides to establish an LSP it will send and the MPLS module in LSRu decides to establish an LSP it will send
an LDP bind (upstream mode) or an LDP bind request (downstream-on- an LDP bind (Upstream Unsolicited mode) or an LDP bind request
demand mode) to LSRd. (Downstream on Demand mode) to LSRd.
Currently, for multicast, we can identify two important types of Currently, for multicast, we can identify two important types of
control messages: the multicast routing messages and the resource control messages: the multicast routing messages and the resource
reservation messages. reservation messages.
5.1.2. Multicast routing messages 5.1.2. Multicast routing messages
In principle, this mechanism can only be used by IP multicast routing In principle, this mechanism can only be used by IP multicast routing
protocols which use explicit signaling: e.g. the Join messages in protocols which use explicit signaling: e.g. the Join messages in
PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to
support this type of trigger [FARI], however, at the cost of support this type of trigger [FARI], however, at the cost of
modifying the IP multicast routing protocol itself ! modifying the IP multicast routing protocol itself !
IP multicast routing messages can create both hard states (e.g. CBT IP multicast routing messages can create both hard states (e.g. CBT
Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent
periodically). The latter generates more control traffic for tree periodically). The latter generates more control traffic for tree
maintenance and thus requires more processing in the MPLS module. maintenance and thus requires more processing in the MPLS module.
Triggers based on the multicast routing protocol messages have the Triggers based on the multicast routing protocol messages have the
disadvantage that the routing calculations performed by the multicast disadvantage that the 'routing calculations' performed by the
routing daemon to determine the Multicast Routing Table are repeated multicast routing daemon to determine the Multicast Routing Table are
by the MPLS module. The former determines the tree that will be used repeated by the MPLS module. The former determines the tree that will
at L3, the latter calculates an identical tree to be used by L2. be used at L3, the latter calculates an identical tree to be used by
Since the same task is performed twice, it is better to create the L2. Since the same task is performed twice, it is better to create
multicast LSP on the basis of information extracted from the the multicast LSP on the basis of information extracted from the
Multicast Routing Table itself (see section 5.2 and 5.3). The Multicast Routing Table itself (see section 5.2 and 5.3). The
routing calculations become more complex for protocols which support routing calculations become more complex for protocols which support
a switch-over from a (*, G) tree to a (S, G) tree because more a switch-over from a (*, G) tree to a (S, G) tree because more
messages have to be interpreted. messages have to be interpreted.
When a host has a point-to-point connection to the first router one When a host has a point-to-point connection to the first router one
could create 'LSPs up to the end-user' by intercepting not only the could create 'LSPs up to the end-user' by intercepting not only the
multicast routing messages but the IGMP Join/Prune messages ([FENN]) multicast routing messages but the IGMP Join/Prune messages ([FENN])
as well. as well.
skipping to change at page 16, line 48 skipping to change at page 16, line 35
trigger to establish LSPs. A source of a multicast group will send trigger to establish LSPs. A source of a multicast group will send
an RSVP Path message down the tree, the receivers can then reply with an RSVP Path message down the tree, the receivers can then reply with
an RSVP Resv message. RSVP scales equally well for multicast as it an RSVP Resv message. RSVP scales equally well for multicast as it
does for unicast because: does for unicast because:
a) RSVP Resv messages can merge. a) RSVP Resv messages can merge.
b) RSVP Resv messages are only sent up to the first branch which made b) RSVP Resv messages are only sent up to the first branch which made
the required reservation. the required reservation.
More on RSVP in the sections on Piggy-backing (section 6) and QoS
(section 8).
5.2. Topology driven 5.2. Topology driven
The Multicast Routing Table (MRT) is maintained by the IP multicast The Multicast Routing Table (MRT) is maintained by the IP multicast
routing protocol daemon (e.g. PIM/pimd, DVMRP/mrouted). The MPLS routing protocol daemon. The MPLS module maps this L3 tree topology
module maps this L3 tree topology information to L2 p2mp LSPs. information to L2 p2mp LSPs.
The MPLS module can poll the MRT to extract the tree topologies. The MPLS module can poll the MRT to extract the tree topologies.
Alternatively, the multicast daemon can be modified to notify the Alternatively, the multicast daemon can be modified to notify the
MPLS module directly of any change to the MRT. MPLS module directly of any change to the MRT.
The disadvantage of this method is that labels are consumed even when The disadvantage of this method is that labels are consumed even when
no traffic exists. no traffic exists.
5.3. Traffic driven 5.3. Traffic driven
skipping to change at page 17, line 21 skipping to change at page 17, line 4
The MPLS module can poll the MRT to extract the tree topologies. The MPLS module can poll the MRT to extract the tree topologies.
Alternatively, the multicast daemon can be modified to notify the Alternatively, the multicast daemon can be modified to notify the
MPLS module directly of any change to the MRT. MPLS module directly of any change to the MRT.
The disadvantage of this method is that labels are consumed even when The disadvantage of this method is that labels are consumed even when
no traffic exists. no traffic exists.
5.3. Traffic driven 5.3. Traffic driven
5.3.1. General 5.3.1. General
A traffic driven trigger method will only construct LSPs for trees A traffic driven trigger method will only construct LSPs for trees
which carry traffic. It consumes less labels than the topology which carry traffic. It consumes less labels than the topology
driven method, as labels are only allocated when there is traffic on driven method, as labels are only allocated when there is traffic on
the multicast tree. the multicast tree.
If the mixed L2/L3 forwarding capability (see section 4) is not If the mixed L2/L3 forwarding capability (see section 4) is not
supported, the traffic driven trigger requires a label distribution supported, the traffic driven trigger requires a label distribution
mode in which the label is requested by the LSRu (downstream-on- mode in which the label is requested by the LSRu (Downstream on
demand or upstream mode). In Figure 10, suppose an LSP for a certain Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP
group exists to LSRd1 and another LSRd2 wants to join the tree. In for a certain group exists to LSRd1 and another LSRd2 wants to join
order for LSRd2 to initiate a trigger, it must already receive the the tree. In order for LSRd2 to initiate a trigger, it must already
traffic from the tree. This can be either at L2 or at L3. The former receive the traffic from the tree. This can be either at L2 or at
case is a chicken and egg problem. The latter case requires a mixed L3. The former case is a chicken and egg problem. The latter case
L2/L3 forwarding capability in LSRu to add the L3 branch. requires a mixed L2/L3 forwarding capability in LSRu to add the L3
branch.
+--------+ +--------+
| LSRd1 | | LSRd1 |
| | | |
+--------+ | L3 | +--------+ | L3 |
| LSRu | +--------+ | LSRu | +--------+
| | | | | | | |
| L3 | +--------------------------> | L3 | +-------------------------->
+--------+ / | L2 | +--------+ / | L2 |
| | / +--------+ | | / +--------+
skipping to change at page 19, line 12 skipping to change at page 18, line 27
anymore. To retain the normal MFC behavior, the L3 counters of the anymore. To retain the normal MFC behavior, the L3 counters of the
MFC need to be updated by L2 measurements. MFC need to be updated by L2 measurements.
5.4. Combinations of triggers and label distribution modes 5.4. Combinations of triggers and label distribution modes
Table 2 shows the valid combinations of label distribution modes and Table 2 shows the valid combinations of label distribution modes and
trigger types which were discussed in the previous sections. The (X) trigger types which were discussed in the previous sections. The (X)
means that the combination is valid when the mixed L2/L3 forwarding means that the combination is valid when the mixed L2/L3 forwarding
feature is supported in the LSR. feature is supported in the LSR.
+----------------+-------------------------------------------+ +----------------+---------------------------------------------+
| | label requested by | | | label requested by |
| | LSRu | LSRd | | | LSRu | LSRd |
| +---------------------+---------------------+ | +----------------------+----------------------+
| | upstream |downstream|downstream| upstream | | | upstream |downstream|downstream| upstream |
| | |on demand | | on demand| | |unsolicited|on demand |unsolicited|on demand |
+----------------+----------+----------+----------+----------+ +----------------+-----------+----------+-----------+----------+
|Request Driven | | | | | |Request Driven | | | | |
|(incoming msg) | X | X | | | |(incoming msg) | X | X | | |
+----------------+----------+----------+----------+----------+ +----------------+-----------+----------+-----------+----------+
|Request Driven | | | | | |Request Driven | | | | |
|(outgoing msg) | | | X | X | |(outgoing msg) | | | X | X |
+----------------+----------+----------+----------+----------+ +----------------+-----------+----------+-----------+----------+
|Topology Driven | X | X | X | X | |Topology Driven | X | X | X | X |
+----------------+----------+----------+----------+----------+ +----------------+-----------+----------+-----------+----------+
|Traffic Driven | X | X | (X) | (X) | |Traffic Driven | X | X | (X) | (X) |
+----------------+----------+----------+----------+----------+ +----------------+-----------+----------+-----------+----------+
Table 2. Valid combinations of triggers and label distribution modes Table 2. Valid combinations of triggers and label distribution modes
6. Piggy-backing 6. Piggy-backing
In Figure 9 (outgoing case) one can observe that instead of sending 2 In Figure 9 (outgoing case) one can observe that instead of sending 2
separate messages the label advertisement can be piggy-backed on the separate messages the label advertisement can be piggy-backed on the
existing control messages. For multicast two piggy-back candidates existing control messages. For multicast two piggy-back candidates
exist: exist:
a) Multicast routing messages: protocols as PIM-SM and CBT have a) Multicast routing messages: protocols as PIM-SM and CBT have
explicit Join messages which could carry the label mappings. This explicit Join messages which could carry the label mappings. This
approach is described in [FARI]. When different multicast routing approach is described in [FARI]. When different multicast routing
protocols are deployed, an extension to each of these protocols has protocols are deployed, an extension to each of these protocols has
to be defined. to be defined.
b) RSVP Resv messages: a label mapping extension object for RSVP, b) RSVP Resv messages: a label mapping extension object for RSVP,
also applicable to multicast, is proposed in [DAVI]. also applicable to multicast, is proposed in [AWDU].
The pro and cons of piggy-backing on multicast routing messages will The pro and cons of piggy-backing on multicast routing messages will
be described now. be described now.
Piggy-backing has following advantages: Piggy-backing has following advantages:
a) If label advertisement is piggy-backed on multicast routing a) If the label advertisement is piggy-backed on multicast routing
messages, then the distribution of routes and the distribution of messages, then the distribution of routes and the distribution of
labels is tightly synchronized. This eliminates difficult corner labels is tightly synchronized. This eliminates difficult corner
cases such as "what do I do with a label if I don't (yet) have a cases such as "what do I do with a label if I don't (yet) have a
routing table entry to attach it to?". It also minimizes the routing table entry to attach it to?". It also minimizes the
interval between the establishment of the multicast route and the interval between the establishment of the multicast route and the
mapping of a label to the route. mapping of a label to the route.
b) The number of control messages needed to support label b) The number of control messages needed to support label
advertisement beyond those needed to support the multicast routing advertisement beyond those needed to support the multicast routing
itself is zero. itself is zero.
skipping to change at page 20, line 31 skipping to change at page 19, line 48
messages to dense-mode protocols for the purpose of label messages to dense-mode protocols for the purpose of label
advertisement, which is a heavy impact on the multicast routing advertisement, which is a heavy impact on the multicast routing
protocol and it eliminates the message conserving benefit of piggy- protocol and it eliminates the message conserving benefit of piggy-
backing. backing.
b) The second solution for the state co-existence problem (section b) The second solution for the state co-existence problem (section
3.4) can not be applied in combination with piggy-backing. 3.4) can not be applied in combination with piggy-backing.
c) Piggybacking requires extending the multicast routing protocol, c) Piggybacking requires extending the multicast routing protocol,
and hence becomes less attractive if label advertisement needs to be and hence becomes less attractive if label advertisement needs to be
supported for multiple routing protocols. Especially when not only supported for multiple multicast routing protocols. Especially when
the label advertisement but also the other two LDP functions not only the label advertisement but also the other two LDP functions
(discovery and adjacency) are piggy-backed. (discovery and adjacency) are piggy-backed.
d) Piggy-backing assumes the downstream label distribution mode, this d) Piggy-backing assumes the Downstream Unsolicited label
excludes a number of trigger methods (see Table 2). distribution mode, this excludes a number of trigger methods (see
Table 2).
e) LDP normally runs on top of TCP, assuring a reliable communication e) LDP normally runs on top of TCP, assuring a reliable communication
between peer nodes. Piggy-backed label advertisement often replaces between peer nodes. Piggy-backed label advertisement often replaces
the reliable communication with periodic soft-state label the reliable communication with periodic soft-state label
advertisements. Because of this periodic label advertisement the advertisements. Because of this periodic label advertisement the
control traffic (in number of bytes) will increase. control traffic (in number of bytes) will increase.
f) If a VCID notification mechanism [NAGA] is required, the (in-band) f) If a VCID notification mechanism [NAGA] is required, the (in-band)
notification can normally be done by sending the LDP bind through the notification can normally be done by sending the LDP bind through the
newly established VC. This way only one message is required. This newly established VC. This way only one message is required. This
skipping to change at page 21, line 12 skipping to change at page 20, line 31
So whether piggy-backing makes sense or not depends heavily on which So whether piggy-backing makes sense or not depends heavily on which
and how many multicast routing protocols are deployed, whether LDP is and how many multicast routing protocols are deployed, whether LDP is
already used for unicast, which trigger mechanism is used, ... . already used for unicast, which trigger mechanism is used, ... .
Piggybacking is just one possible component of an MPLS multicast Piggybacking is just one possible component of an MPLS multicast
solution. solution.
7. Explicit routing 7. Explicit routing
Explicit routing for unicast refers to overriding the unicast routing Explicit routing for unicast refers to overriding the unicast routing
table by using LSPs. A first way to interpret "multicast explicit table by using LSPs.
routing" is overriding the multicast routing table by another LSP
tree (e.g. a centrally calculated Steiner tree). A first way to interpret "multicast explicit routing" is overriding
the tree established by the multicast routing protocol by another LSP
tree (e.g. a centrally calculated Steiner tree). In this
interpretation the current 'shortest path' multicast routing protocol
becomes obsolete and can be replaced by label advertisement messages
that follow an explicit route which is e.g. calculated by an offline
tool.
A second way of interpreting "multicast explicit routing" is that A second way of interpreting "multicast explicit routing" is that
multicast routing protocols use the explicit unicast routes to multicast routing protocols use the explicit unicast routes to
construct trees. However this approach creates some problems: construct trees. This approach requires that the RPF check also
takes the explicit path into account.
1) The unicast explicit paths need to be bidirectional so that the
multicast data (from source to receiver) and the multicast routing
messages (from receiver to source) follow the same path.
2) The RPF check also has to take into account the explicit path.
8. QoS/CoS 8. QoS/CoS
8.1. DiffServ 8.1. DiffServ
The Differentiated Services approach can be applied to multicast as The Differentiated Services approach can be applied to multicast as
well. It introduces finer stream granularities (Class of Service well. It introduces finer stream granularities (DiffServ Codepoint
(CoS) as an extra differentiator). A sender can construct one or (DSCP) as an extra differentiator). A sender can construct one or
more trees with different CoS bits. more trees with different DSCPs.
These (S, G, CoS) or (*, G, CoS) trees can be mapped very easily onto These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily
LSPs when the traffic driven trigger is used. In this case one can onto LSPs when the traffic driven trigger is used. In this case one
create LSPs with different attributes for the various classes. Note can create LSPs with different attributes for the various DSCPs.
however that these LSPs still use the same route as long as the tree Note however that these LSPs still use the same route as long as the
construction mechanism does not support a class identifier, this tree construction mechanism itself does not take the DSCP as an
means that the multicast routing protocol has to interpret the CoS input.
bits in the join messages and create (S, G, CoS) state in the
routers.
8.2. IntServ and RSVP 8.2. IntServ and RSVP
RSVP can be used to setup multicast trees with QoS. An important RSVP can be used to setup multicast trees with QoS. An important
multicast issue is the problem of how to map the 'heterogeneous multicast issue is the problem of how to map the 'heterogeneous
receivers' paradigm onto L2 (remark that it is not solved in IP receivers' paradigm onto L2 (remark that it is not solved in IP
either). This subject is tackled in [CRAW]. Pragmatic approaches either). This subject is tackled in [CRAW]. Pragmatic approaches
are the 'Limited Heterogeneity Model' which allows a best effort are the 'Limited Heterogeneity Model' which allows a best effort
service and a single alternate QoS (e.g. a QoS proposed by the sender service and a single alternate QoS (e.g. a QoS proposed by the sender
in a RSVP Path message) and the 'Homogeneous Model' which allows only in a RSVP Path message) and the 'Homogeneous Model' which allows only
a single QoS. a single QoS.
The first approach will construct full trees for each service class. The first approach will construct full trees for each service class.
The sender has to send its traffic twice across the network (1 best- The sender has to send its traffic twice across the network (e.g. 1
effort and 1 QoS tree). Both trees can be label switched. best-effort and 1 QoS tree). Both trees can be label switched.
The second approach constructs one tree and the best-effort users are The second approach constructs one tree and the best-effort users are
connected to the QoS tree. If the branches created for best-effort connected to the QoS tree. If the branches created for best-effort
users are not to be label switched, (thus carried by a hop-by-hop users are not to be label switched, (thus carried by a hop-by-hop
default LSP) the QoS multicast traffic has to be merged onto these default LSP) the QoS multicast traffic has to be merged onto these
default LSPs. This function can be provided by the 'mixed L2/L3 default LSPs. This function can be provided by the 'mixed L2/L3
forwarding' feature described in section 4. If this is not available forwarding' feature described in section 4. If this is not available
merging is necessary to avoid a return to L3 in the QoS LSP. merging is necessary to avoid a return to L3 in the QoS LSP.
The mapping of the IntServ service categories onto L2 for ATM service The mapping of the IntServ service categories onto L2 for ATM service
skipping to change at page 22, line 47 skipping to change at page 22, line 18
it can allocate labels itself. If LSRs allocate a label 'at the same it can allocate labels itself. If LSRs allocate a label 'at the same
moment' the LSR with the highest IP address could keep it, while the moment' the LSR with the highest IP address could keep it, while the
other LSRs withdraw the label. other LSRs withdraw the label.
2) Each LSR gets its own label range to allocate labels from. A 2) Each LSR gets its own label range to allocate labels from. A
mechanism for label partitioning is described in [FAR2]. If an LSR mechanism for label partitioning is described in [FAR2]. If an LSR
is added to the multi-access link the label ranges have to be is added to the multi-access link the label ranges have to be
negotiated again and possibly existing LSPs are teared down and are negotiated again and possibly existing LSPs are teared down and are
reconstructed with other labels. reconstructed with other labels.
3) Per multi-access link one LSR could be elected to be responsibe 3) Per multi-access link one LSR could be elected to be responsible
for label allocation. When an LSR needs a label, it can request it for label allocation. When an LSR needs a label, it can request it
from this Label Allocation LSR. from this Label Allocation LSR.
Unlike the unicast case, a multicast stream can have more than one Unlike the unicast case, a multicast stream can have more than one
downstream LSR which all have to use the same label. Two solutions downstream LSR which all have to use the same label. Two solutions
for label advertisement can be thought of: for label advertisement can be thought of:
1) [FARI] proposes to multicast the label advertisements to all LSRs 1) [FARI] proposes to multicast the label advertisements to all LSRs
on the shared link. Since multicast is not reliable this requires on the shared link. Since multicast is not reliable this requires
periodic label advertisements, yielding label advertisement periodic label advertisements, yielding label advertisement
skipping to change at page 23, line 24 skipping to change at page 22, line 41
2) Another approach is that an LSR unicasts its label advertisements 2) Another approach is that an LSR unicasts its label advertisements
in a reliable way (TCP) to all other (or to all interested) LSRs on in a reliable way (TCP) to all other (or to all interested) LSRs on
the shared link. In this approach the hard-state character of LDP the shared link. In this approach the hard-state character of LDP
can be maintained but the label advertisement is duplicated in space. can be maintained but the label advertisement is duplicated in space.
Since LSPs are only rewarding if they have a long lifetime and since Since LSPs are only rewarding if they have a long lifetime and since
the number of LSRs on a shared link is limited the second approach the number of LSRs on a shared link is limited the second approach
seems advantageous. seems advantageous.
Another issue with multicast in multi-access networks is whether to Another issue with multicast in multi-access networks is whether to
use upstream or downstream label advertisement. For multicast use upstream or downstream label assignment. For multicast traffic,
traffic, upstream label allocation is simpler since there can be only upstream label allocation is simpler since there can be only one
one upstream node per link that belongs to a multicast tree. This upstream node per link that belongs to a multicast tree. This
(upstream) node can assign a label without any contention. With (upstream) node can assign a label without any contention. With
downstream allocation, there may be multiple downstream nodes for a downstream allocation, there may be multiple downstream nodes for a
given tree on a multi-access link; each node may propose a label given tree on a multi-access link; each node may propose a label
assignment leading to contention and a contention resolution scheme assignment leading to contention and a contention resolution scheme
is required to chose one of them as the label allocator. is required to chose one of them as the label allocator.
Once a label has been assigned, it is possible that the label Once a label has been assigned, it is possible that the label
assigner leaves the tree. With downstream label assignment, this assigner leaves the tree. With downstream label assignment, this
could happen when the label allocator leaves the group. With could happen when the label allocator leaves the group. With
upstream assignment this could happen when the upstream LSR changes upstream assignment this could happen when the upstream LSR changes
skipping to change at page 25, line 12 skipping to change at page 24, line 29
advertised the label) are allocated and maintained. In the Liberal advertised the label) are allocated and maintained. In the Liberal
Mode labels are advertised and maintained to all neighbors. Mode labels are advertised and maintained to all neighbors.
Liberal Mode does not make sense in multicast. Two reasons can be Liberal Mode does not make sense in multicast. Two reasons can be
identified for this: identified for this:
1) All LSRs have a route for each unicast FEC. This is not true for 1) All LSRs have a route for each unicast FEC. This is not true for
multicast FECs. multicast FECs.
2) For multicast an LSR always knows to which neighbor to send the 2) For multicast an LSR always knows to which neighbor to send the
label request or the label map messages. In e.g. unicast downstream label request or the label map messages. In e.g. unicast Downstream
mode (see below) the LSR does not know where to send the label Unsolicited mode (see below) the LSR does not know where to send the
mappings and thus has to send the mapping to all its neighbors. In label mappings and thus has to send the mapping to all its neighbors.
this case supporting the Liberal Mode does not generate extra In this case supporting the Liberal Mode does not generate extra
messages (it still requires extra state information and label space) messages (it still requires extra state information and label space)
and thus the threshold to support Liberal Mode could be considered and thus the threshold to support Liberal Mode could be considered
lower. lower.
Table 3 shows the cases where it is known by an LSR where to send its Table 3 shows the cases where it is known by an LSR where to send its
label requests. label requests.
+---------+----------------------------------+ +---------+----------------------------------+
| | label requested by | | | label requested by |
| | LSRu | LSRd | | | LSRu | LSRd |
skipping to change at page 25, line 33 skipping to change at page 25, line 4
+---------+----------------------------------+ +---------+----------------------------------+
| | label requested by | | | label requested by |
| | LSRu | LSRd | | | LSRu | LSRd |
+---------+----------------+-----------------| +---------+----------------+-----------------|
|unicast | Yes | No | |unicast | Yes | No |
+---------+----------------+-----------------| +---------+----------------+-----------------|
|multicast| Yes | Yes | |multicast| Yes | Yes |
+---------+----------------+-----------------+ +---------+----------------+-----------------+
Table 3. Does an LSR know where to send its label requests ? Table 3. Does an LSR know where to send its label requests ?
For a unicast flow, an LSR can determine the next hop LSR, which is For a unicast flow, an LSR can determine the next hop LSR, which is
the one to send the request to in case of upstream or downstream-on- the one to send the request to in case of Upstream Unsolicited or
demand mode. The LSR is however not able to find the previous hop. Downstream on Demand mode. The LSR is however not able to find the
The previous hop is not necessarily the next hop towards the source, previous hop. The previous hop is not necessarily the next hop
because the path from A to B is not necessarily the same as the path towards the source, because the path from A to B is not necessarily
from B to A. Such a situation can occur as a result of asymmetric the same as the path from B to A. Such a situation can occur as a
link measures or in the event that multiple equal cost paths exist result of asymmetric link measures or in the event that multiple
[PAXS]. equal cost paths exist [PAXS].
In the case of multicast, an LSR knows both the next hop(s) and the In the case of multicast, an LSR knows both the next hop(s) and the
previous hop. Because multicast trees are constructed using the previous hop. Because multicast trees are constructed using the
reverse shortest path method, the previous hop is always the next hop reverse shortest path method, the previous hop is always the next hop
towards the source or towards the root of the tree. towards the source or towards the root of the tree.
10.4. Downstream vs. Upstream Label Allocation 10.4. Downstream vs. Upstream Label Allocation
The label can be allocated by either the downstream LSR (downstream- The label can be allocated by either the downstream LSR (Downstream
on-demand, downstream) or the upstream LSR (upstream-on-demand, on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on
upstream, implicit). The advantages of downstream label allocation Demand, Upstream Unsolicited, implicit). The advantages of
are: downstream label allocation are:
a) It is the same mode as for unicast LDP, thus eliminating the need a) It is the same mode as for unicast LDP, thus eliminating the need
to develop upstream label distribution procedures. to develop upstream label distribution procedures.
b) The same label can be kept when the upstream LSR changes due to a b) The same label can be kept when the upstream LSR changes due to a
route change, which is an advantage on multi-access networks (see route change, which is an advantage on multi-access networks (see
section 9). section 9).
c) Compatible with piggybacking (especially the downstream c) Compatible with piggybacking (especially the downstream
distribution mode). distribution mode).
skipping to change at page 26, line 47 skipping to change at page 26, line 19
Implicit label distribution is not applicable if the FEC-to-label Implicit label distribution is not applicable if the FEC-to-label
binding has been advertised prior to traffic arrival, e.g. explicit binding has been advertised prior to traffic arrival, e.g. explicit
routing (i.e. if all the information necessary to identify the FEC is routing (i.e. if all the information necessary to identify the FEC is
not present in the packet). not present in the packet).
Explicit distribution allows pre-establishment (before the arrival of Explicit distribution allows pre-establishment (before the arrival of
data) of LSPs with topology or request driven triggers. data) of LSPs with topology or request driven triggers.
11. Security Considerations 11. Security Considerations
Security considerations are not discussed in this version of the This document raises no security issues.
document.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip
Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard
Gastaud for the fruitful discussions and/or their thorough revision Gastaud for the fruitful discussions and/or their thorough revision
of this document. of this document.
References References
[ACHA] A. Acharya, F. Griffoul, F. Ansari, "IP Multicast Support in [ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM
MPLS Networks", IETF Draft, draft-acharya-ipsofacto-mpls-mcast- Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE
00.txt, February 1999. Globecom '97.
[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva-
san, "Extensions to RSVP for LSP Tunnels", Work In Progress
[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas,
"Label Distribution Protocol", IETF Draft, draft-mpls-ldp- "Label Distribution Protocol", Work In Progress.
03.txt, January 1999.
[BALL] A. Ballardie, B. Cain, Z. Zhang, "Core Based Trees (CBT, v3) [BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi-
Multicast Routing - Protocol Specification", IETF Draft, draft- tecture", RFC2201, September 1997.
ietf-idmr-cbt-spec-v3-01.txt, August 1998.
[CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. [CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A.
Viswanathan, "A Framework for Multiprotocol Label Switching", Viswanathan, "A Framework for Multiprotocol Label Switching",
IETF Draft, draft-ietf-mpls-framework-02.txt, November 1997. Work In Progress.
[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame [CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
Relay Networks", IETF Draft, draft-ietf-mpls-fr-03.txt, November Relay Networks", Work In Progress.
1998.
[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden
and J. Krawczyk, "A Framework for Integrated Services and RSVP and J. Krawczyk, "A Framework for Integrated Services and RSVP
over ATM", IETF Draft, RC2382, August 1998. over ATM", RFC2382, August 1998.
[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
Swallow and P. Doolan, "MPLS using ATM VC switching", IETF Swallow and P. Doolan, "MPLS using ATM VC switching", Work In
Draft, draft-ietf-mpls-atm-01.txt, November 1998. Progress.
[DAV2] B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan
and S. Blake, "Use of Label Switching With RSVP", IETF Draft,
draft-ietf-mpls-rsvp-00.txt, March 1998
[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.
Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2117, June 1997. Specification", RFC 2117, June 1997.
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol
Independent Multicast Version 2 Dense Mode Specification", IETF Independent Multicast Version 2 Dense Mode Specification", Work
Draft, draft-ietf-pim-v2-dm-01.txt, November, 1998. In Progress.
[FARI] D. Farinacci and Y. Rekhter, "Multicast Tag Binding and Distri- [FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute
bution using PIM", IETF Draft, draft-farinacci-multicast-tagsw- MPLS Labels for Multicast Routes", Work In Progress.
00.txt, December 1996.
[FAR2] D. Farinacci and Y. Rekhter, "Partitioning Tag Space among Mul- [FAR2] D. Farinacci and Y. Rekhter, "Partitioning Label Space among
ticast Routers on a Common Subnet", IETF Draft, draft- Multicast Routers on a Common Subnet", Work In Progress.
farinacci-multicast-tag-part-00.txt, December 1996.
[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", IETF Draft, RFC2381, Service and Guaranteed Service with ATM", RFC2381, August 1998.
August 1998.
[KATS] Y. Katsube, Y. Ohba and K. Nagami, "Two Modes of MPLS Explicit [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work
Label Distribution Protocol", IETF Draft, draft-katsube-mpls- In Progress.
two-ldp-00.txt, September 1997.
[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994.
[NAGA] K. Nagami, N. Demizu, H. Esaki and P. Doolan, "VCID Notification [NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID
over ATM link", IETF Draft, draft-ietf-mpls-vcid-atm-00.txt; Notification over ATM link for LDP", Work In Progress.
March 1998.
[PERL] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Maufer, "Simple Multicast", IETF Draft, draft-perlman-simple-
multicast-02.txt, February 1999.
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", IETF [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Draft, draft-ietf-idmr-dvmrp-v3-05, October 1997. Maufer, "Simple Multicast", Work In Progress.
[PARS] M. Parsa and J. Garcia-Luna-Aceves, "A protocol for scaleable [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work
loop-free multicast routing", IEEE JSAC, vol.15, no.3, p.316- In Progress.
331, April 1997
[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet",
IEEE/ACM Transactions on Networking 5(5), pp. 601-615. IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
[ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. [ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T.
Li, A. Conta, "MPLS Label Stack Encoding", IETF draft, draft- Li, A. Conta, "MPLS Label Stack Encoding", Work In Progress.
ietf-mpls-label-encaps-03.txt, September 1998.
Authors Addresses Authors Addresses
Dirk Ooms Dirk Ooms
Alcatel Corporate Research Center Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-4732 Phone : 32 3 2404732
Fax : 32-3-240-9932 Fax : 32 3 2409879
E-mail: Dirk.Ooms@alcatel.be E-mail: Dirk.Ooms@alcatel.be
Wim Livens
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-7570
E-mail: Wim.Livens@alcatel.be
Bernard Sales Bernard Sales
Alcatel Corporate Research Center Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-9574 Phone : 32 3 2409574
E-mail: Bernard.Sales@alcatel.be E-mail: Bernard.Sales@alcatel.be
Maria Fernanda Ramalho Wim Livens
Alcatel Corporate Research Center Colt Telecom
Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Zweefvliegtuigstraat 10, 1130 Brussel, Belgium
Phone : 32-3-240-9725 Phone : 32 2 7901705
E-mail: Maria.Ramalho@alcatel.be Fax : 32 2 7901711
E-mail: WLivens@colt-telecom.be
Arup Acharya Arup Acharya
C&C Research Labs, NEC USA IBM TJ Watson Research Center
4 Independence Way, Princeton, NJ, USA 30 Saw Mill River Road, Hawthorne
Phone : 1 609 951 2992 NY 10532
Fax : 1 609 951 2499 Phone : 1 914 784 7481
E-mail: arup@ccrl.nj.nec.com E-mail: arup@us.ibm.com
Frederic Griffoul Frederic Griffoul
C&C Research Labs, NEC Europe Ltd. Ulticom, Inc.
Adenauerplatz 6, D-69115 Heidelberg, Germany Les Algorithmes, 2000 Route des Lucioles, BP29
Phone : 49 6221 905 1120 06901 Sophia-Antipolis, FRANCE
Fax : 49 6221 905 1155 E-mail: griffoul@ulticom.com
E-mail: griffoul@ccrle.nec.de
Furquan Ansari Furquan Ansari
Bell Labs Bell Labs
101 Crawfords Corner Rd., Holmdel, NJ 07733 101 Crawfords Corner Rd., Holmdel, NJ 07733
Phone : 1 732 949 5149 Phone : 1 732 949 5149
Fax : 1 732 332 6511 Fax : 1 732 332 6511
E-mail: furquan@dnrc.bell-labs.com E-mail: furquan@dnrc.bell-labs.comy
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/