Network Working Group Dino Farinacci
Internet Draft Procket Networks, Inc.
Expiration Date: December 2000
Yakov Rekhter
Eric C. Rosen
Ted Qian
Cisco Systems, Inc.
June 2000
Using PIM to Distribute MPLS Labels for Multicast Routes
draft-farinacci-mpls-multicast-02.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 obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a method of distributing MPLS labels [MPLS-
ARCH, MPLS-MUL-FR] for multicast routes.
The labels are distributed in the same PIM messages that are used to
create the corresponding routes. The method is media-type
independent, and therefore works for multi-access/multicast capable
LANs, point-to-point links, and NBMA networks.
Farinacci, et al. [Page 1]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
Table of Contents
1 Overview ........................................... 2
2 Label Distribution for PIM-SM ...................... 3
2.1 Piggybacking ....................................... 3
2.2 LANs with Multiple Downstream Nodes ................ 5
2.2.1 Partitioning the Label Space ....................... 5
2.2.1.1 Partitioning Procedure ............................. 5
2.2.1.2 Effect of Partition in Layer 2 Topology ............ 6
2.2.1.3 Effect of Exceeding the Label Range ................ 7
2.2.2 Assigning the Labels ............................... 7
2.3 Labels for Point-to-Point Links .................... 8
2.4 Labels for NBMA Networks ........................... 8
2.5 When NOT to Send a Labelled Multicast Packet ....... 9
2.6 No Conflict between Unicast and Multicast Labels ... 9
2.7 Supporting Bidirectional PIM ....................... 9
3 Modifications to PIMv2 ............................. 10
3.1 Join/Prune Packets ................................. 10
3.2 Hello Packets ...................................... 11
4 Label Distribution for PIM-DM ...................... 13
5 Security Considerations ............................ 13
6 Acknowledgments .................................... 14
7 References ......................................... 15
1. Overview
PIM [PIMv1, PIMv2] is used to combine MPLS label distribution with
the distribution of (*,G) join state, (S,G) join state, or (S,G)RPT-
bit prune state. Labels and multicast routes are sent together in one
message.
This design has the following goals:
o If an interface attaches to a network with data-link broadcast
capability, an LSR should never have to send more than one copy
of a given multicast data packet out that interface. However, it
is NOT a goal for that LSR to be able to send the same packet,
with the same label, out multiple interfaces.
o When an interface supports data link multicasting, it must be
possible for the receiver of a labeled packet to interpret the
label without knowing who the transmitter is.
Farinacci, et al. [Page 2]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
o When a LAN contains multiple label distribution peers, it should
be possible to use data link multicast to distribute the label
distribution control packets themselves. Other aspects of label
distribution methodology should remain as consistent with unicast
label distribution as possible.
o Multicast label distribution procedures should not depend on the
media type.
o Once the label for a particular multicast tree on a given LAN has
been assigned, unicast routing changes should not cause
redistribution or reassignment of the label for that group on
that LAN.
o When a multicast routing table change requires a label
distribution change, the latency between the two should be
minimized, both to improve performance and to minimize the
possibility of race conditions.
o The procedures should work with either dense-mode or sparse mode
operation.
2. Label Distribution for PIM-SM
2.1. Piggybacking
An LSR that supports multicast sends PIM Join/Prune messages on
behalf of hosts that join groups. It sends Join/Prune messages to
upstream neighboring LSRs toward the RP for the shared-tree (*,G) or
toward a source for a source-tree (S,G). Labels are distributed by
being associated with addresses in the join list or the prune list.
In particular:
1. If an LSR, Rd, joins the shared tree for a group, the
Join/Prune message it sends upstream will contain the group
address followed by a join-list. The join-list will contain an
element which contains the address of the RP. This element
will also contain a a label, and this label can be used by the
upstream LSR, Ru, when it sends multicast data down the shared
tree. Intuitively, this label represents the route downstream
from the current node along the shared tree.
Note that if Rd joins the shared tree for group G, but Ru
happens to have (S,G) state for some S, then Ru must merge its
(*,G) output interface list into its (S,G) output interface
list. This is necessary in order to ensure that Rd will
receive packets sent from S to G, even though Ru only gets
Farinacci, et al. [Page 3]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
these packets on the source tree. In this case, when Ru
receives an (S,G) packet, it should forward it to Rd using the
same label that Rd assigned for (*,G) packets, AS LONG AS THE
Ru-Rd LINK IS NOT AN LC-ATM interface [MPLS-ATM]. The case
where the link is an LC-ATM interface is not considered in the
current version of this document, but will be described in a
future version. (The procedure described in this paragraph
would create a mulitpoint-to-multipoint VC, which ATM-LSRs
might not be able to support.)
2. If an LSR, Rd, joins a source tree for a group, the Join/Prune
message it sends upstream will contain the group address
followed by a join-list. The join-list will contain an element
which contains the address of the source. This element will
also contain a label, and this label can be used by the
upstream LSR, Ru, when it sends multicast data down the source
tree. Intuitively, this label represents the route downstream
from the current node along the specified source tree.
3. Suppose an LSR, Rd, has (S,G)RPT-bit state with a null output
interface list. This indicates that all of its downstream
neighbors on the shared tree for G have pruned source S from
the shared tree. Rd sends a Join/Prune message upstream (on
the shared tree), containing the group address followed by a
prune-list. The prune-list contains an element which contains
the address of the source. In this case, no label is included
in the element.
Similarly, if an LSR has (S,G) state, and also has (*,G) state
with a non-null output interface list, it will send a
Join/Prune message upstream on the shared tree, with S in the
prune-list, and will not include a label.
4. Suppose an LSR, Rd, as the result of receiving, from a
downstream neighbor on the shared tree, a Join/Prune message
such as described in 3, creates (S,G)RPT-bit state with a non-
null output interface list. In this case, it may send a
Join/Prune message upstream on the shared tree, containing the
group address followed by a prune-list. An element of the
prune list will contain the address S and a corresponding
label. However, a special bit (the "Label Only" bit, or "L-
bit") in the element will be set indicating to the upstream LSR
that the source S is not really to be pruned from the shared
tree. The result is that the upstream LSR, Ru, will still send
packets from S to G to Rd, and will label those packets as
specified. When Rd receives such packets, it forwards them
according to the output interface list of the (S,G)RPT-bit
entry. Intuitively, this label represents a route along the
Farinacci, et al. [Page 4]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
shared tree, but only for packets from the specified source.
5. An LSR which receives a Join/Prune message as described in 4
may send a corresponding Join/Prune message (with the L-bit
set) to its upstream LSR on the shared tree. Again, this label
represents a route along the shared tree, but only for packets
from the specified source.
Rules 3-5 above ensure that if a source is pruned off the shared tree
at some point, any packets from that source which is sent down the
shared tree will have a label that implicitly identifies the source.
Thus if those packets encounter a node with (S,G)RPT-bit state, they
will be sent according to the output interface list of the (S,G)RPT-
bit entry, NOT according to the output interface list of the (*,G)
entry.
2.2. LANs with Multiple Downstream Nodes
2.2.1. Partitioning the Label Space
Only one copy of a given multicast data packet is sent downstream.
On a LAN, this packet will be received by all the LSRs on the LAN.
The label it carries is used, by the receiving LSRs, to find the
packet's multicast distribution tree. The label it carries must have
a unique association, on that LAN, with a multicast distribution
tree.
Therefore, once an LSR assigns a label to a particular multicast
distribution tree on a particular LAN, all other LSRs on that LAN are
prohibited from making any other use of that label. The prohibition
remains in effect as long as the distribution tree in question
exists.
In order to meet this requirement, the LSRs on a LAN must divide up
the label space, such that each LSR has a particular unique range of
labels which it may distribute.
2.2.1.1. Partitioning Procedure
Each multicast LSR on a LAN is configured with the total number of
labels (N) that may be used to represent multicast distribution trees
on the LAN. It is also configured with an approximate count (R) of
the routers on the LAN. The router divides the multicast label space
into a number of equal-sized ranges, where the size of a range is
T/R. Each router will randomly select one of these ranges.
Farinacci, et al. [Page 5]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
When a multicast LSR boots up or enables the LAN interface to do
multicast routing, it will advertise in PIM Hello messages the total
number of multicast labels, the router count, the label range it
randomly selects, and optionally its priority. The lower range label
value and the higher range label value accompany the advertisement.
If a LSR doesn't advertise its priority, it is treated as if the LSR
would advertise the highest possible priority.
If the total number of multicast labels for the LAN is not configured
consistently on all LSRs connected to a LAN, the smallest number
advertised by any LSR will be used.
If the router count is not configured consistently on all LSRs
connected to a LAN, the smallest router count value advertised by any
LSR will be used.
If there is another LSR that has selected the same range, then the
following procedures are used to determine which of the two LSRs
would be able to keep its range, and which would be required to
allocate another label range. If the two LSRs have different
priority, then the one with the lower priority is required to
allocate another label range. If the two LSRs have the same priority,
then the one with the lower IP address on the LAN is required to
allocate another label range. In both cases the label range is
allocated randomly. If as a result of these procedures a LSR has to
allocate another label range, then the LSR has to withdraw its label
bindings from its currently allocated range, and then (after it
allocates another range) reallocate its bindings.
A LSR can be configured to use more than one label range if one
believes it will be an upstream LSR for many flows. It just inserts
additional advertisements in the same PIM Hello message. The label
table size and router-count should be the same in all advertisements
contained in a message.
2.2.1.2. Effect of Partition in Layer 2 Topology
When a subnet partitions (due to, say, the failure of a layer 2
switch) and new multicast LSRs come up, they will allocate label
ranges that are unique to their partition. When the partition heals,
there may be conflicts. Once the PIM Hellos messages are received by
LSRs on the other side of the partition, they will determine there is
a label range allocation conflict and immediately perform the tie
breaking rules described above.
Farinacci, et al. [Page 6]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
2.2.1.3. Effect of Exceeding the Label Range
When a LSR cannot allocate a label range because all ranges within
the label table size have been allocated, it will not participate in
binding labels to multicast routes. Packets for these routes will not
be label switched. However, the LSR is still capable of label
switching a packet as either an upstream or downstream LSR on that
LAN. This is the case when another router is binding labels for the
multicast route and has an allocated a label range successfully.
2.2.2. Assigning the Labels
Since PIM Join/Prune messages are multicast on a LAN, other
downstream LSRs that are interested in the group will hear the
message. They must cache the binding of multicast routing table
state and label state together. Since the upstream LSR is going to
forward data packets using the advertised label, they must be ready
to accept the data packet with that advertised label.
The first downstream LSR that joins a group is the label assigner on
that LAN for that multicast route. All other downstream LSRs that
send PIM Join/Prune messages will use the same label that the
assigner selected. A LSR that sends a PIM Join/Prune message with a
label of 0 means that it doesn't know the label for the associated
multicast routing table entry. When this occurs, the assigner can
trigger a PIM Join/Prune message making the label known.
When the label assigner leaves the group, the label that it assigned
still remains active. The next highest IP addressed downstream LSR
becomes the owner of that label and may change it if it sees fit.
However, it is not required to change it. All downstream LSRs can
continue to use the assignment in their Join messages.
If two systems simultaneously join a distribution tree for the first
time (they do not have state for that tree), and each chooses a
different label value, the highest IP addressed downstream LSR's
label will be used by the upstream LSR. The lower addressed LSR will
hear the higher addressed LSR's Join too and will also use it's
label.
If the label assigner crashes, the highest IP addressed downstream
LSR assigns a new label to the multicast routes, which were assigned
by the crashing LSR, and triggers a Join message so all other LSRs on
the LAN to use the new label.
When a LAN partitions due to a layer-2 switch failure, it follows the
same logic for the case when a LSR stops joining for a group. When
Farinacci, et al. [Page 7]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
the partition heals, there may be an RPF neighbor change in one of
the partitions. When there is an RPF neighbor change and the
downstream routers trigger joins to their new RPF neighbor with a
different label assignment than the other partition is using, one of
two resolutions occur:
1) The LSR which is the allocator in the partition of the new RPF
neighbor will trigger a join if it has a higher IP address than
the allocator in the other region. The downstream routers in
the other partition use the new label assignment immediately.
2) If the LSR which is the allocator in the partition of the new
RPF neighbor has a lower IP address, all downstream routers and
the new RPF neighbor will switch to the label assigned by the
allocator in the other partition.
If an RPF change occurs (the topology changed so the upstream LSR is
different), the PIM protocol spec indicates that a PIM Join may be
triggered to get on the new distribution tree as soon as possible. In
this case, if the label assigner becomes the upstream LSR, then the
new highest IP addressed downstream LSR may become the label
assigner. It may change the label if it sees fit. Otherwise, the same
label is used.
2.3. Labels for Point-to-Point Links
The procedure of section 2.2 works on point-to-point links because
there is only one downstream LSR on the link which always becomes the
label assigner.
2.4. Labels for NBMA Networks
On NBMA networks, all PIM routers are known to each other through
pseudo-broadcast mechanisms provided by the data-link layer. However,
PIM Join messages are unicast to the upstream LSR. Therefore, other
downstream LSRs will not hear the label assigner's advertisement.
Therefore we treat an NBMA network with one upstream and n downstream
LSRs as n point-to-point links, from the upstream LSR to each of the
downstream LSRs. Each downstream LSR then assigns its own label, and
the upstream LSR must replicate the multicast data packets.
Therefore the procedure of section 2.2 applies.
Note that this is not incompatible with the use of native point-to-
multipoint capabilities at the data link layer.
Farinacci, et al. [Page 8]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
2.5. When NOT to Send a Labelled Multicast Packet
PIM Hello messages, sent periodically by all PIM-capable routers,
will indicate if the router is MPLS-capable. An upstream router on a
LAN will therefore know if all routers on the same LAN are LSRs or
not. If there are ANY MPLS-incapable routers which are interested in
a particular group, the upstream router will transmit to the LAN only
unlabelled multicast data packets for that group.
If there are any group members on a LAN, only unlabelled multicast
data for that group will be transmitted onto that LAN.
Routers that support non-PIM multicast are assumed, for the purposes
of this procedure, to be MPLS-incapable.
2.6. No Conflict between Unicast and Multicast Labels
MPLS uses different data-link layer code-points [MPLS-ENCAPS] to
distinguish multicast labeled packets from unicast labeled packets.
Therefore, the assignment of labels for unicast routes is completely
independent from the assignment of labels for multicast routes. For
example, the same label value could be allocated for a unicast route
and for a multicast route, without any possibility of ambiguity.
2.7. Supporting Bidirectional PIM
We consider support of Bidirectional PIM [PIM-BIDIR] only in LSRs
which are not ATM-LSRs. In the absence of an ATM multipoint-to-
multipoint capability, bidirectional PIM over ATM will not have the
favorable scaling properties that make it interesting.
On links which are not sender-only links, support for Bidirectional
PIM is straightforward. Labels are assigned in the usual manner by
downstream LSRs. However, a label can be used in either direction
(i.e., can be carried by packets traveling either upstream or
downstream). On a given link, the label is bound to the same
multicast route (*,G) or (S,G) in both directions. As long as the
procedures of section 2.2 are always used to partition the label
space (even on point-to-point links), it is possible to use the same
label in both directions.
Sender-only links present a bit more of a difficulty since PIM
Join/Prune messages are not generally sent on those links. In order
to assign labels to these links, a downstream node on a sender only
link should send a PIM Join message, as if it were going to join the
tree, but should set the newly defined "label only" bit (L-bit). In
Farinacci, et al. [Page 9]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
essence, these nodes will contain (*,G) state, and will associate the
(*,G) state with a label that is distributed upstream. However,
there will be no output interface list associated with the (*,G)
state, and packets will just be forwarded towards the RP.
3. Modifications to PIMv2
3.1. Join/Prune Packets
PIMv2 has a packet format for each address type it may support when
encoding both multicast and unicast addresses. We will define a new
address type called "Label Address" for unicast address encoding.
The label will accompany the source address in the Encoded Source
Address format as specified in [PIMv2]. The label value will be in a
32-bit quantity following the source address. We also take one bit
from the PIMv2 reserved field to be the "label only" bit (shown below
as the "L-bit"). So, for example, an IPv4 Label Address format would
look like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsrvd |L|S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Multicast Route Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label
If the high-order bit is clear, the low-order 20 bits are a label
value (as described in [5]) assigned by the LSR sending the
Join/Prune message. All other bits should be set to 0 by the
sender and should be ignored by the receiver.
If the high-order bit is set, the low-order 28 bits are a label
value in the VPI/VCI format of (as described in [MPLS-ATM])
assigned by the LSR sending the Join/Prune message. All other
bits should be set to 0 by the sender and should be ignored by the
receiver.
Current Multicast Route Timer
The sender of a Join/Prune message inserts the current time left
Farinacci, et al. [Page 10]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
before expiration for the multicast route table entry described by
the Source Address (either the (S,G) or (*,G) entry). This is
needed so all routers on a common multi-access subnet can time-out
the entry close to the same time without each other recreating the
state when the source goes inactive.
Refer to [PIMv2] for other field descriptions not specified here.
3.2. Hello Packets
The PIM Hello message will carry 2 new OptionTypes (called "Label
Parameters" and "VCI Capability") as specified in [PIMv2]. A router
that sends a PIM Hello with the Label Parameters option is regarded
as being label-capable. This Option can appear multiple times in a
Hello packet if a LSR wants to allocate multiple ranges. When this
option appears multiple times in the Hello message, the Label Table
Size and Router Count must be the same for each Label Parameters
Option supplied in the message.
When sent on point-to-point links, this option should have Router
Count, Lower Label Range, and Upper Label Range set to 0. These
fields are ignored on receipt.
Label Parameters TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = 17 | OptionLength = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Number of Multicast Labels for this LAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower Label Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper Label Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType "Label Parameters"
Set to value 17 decimal.
OptionLength
The option is 16 bytes in length.
Farinacci, et al. [Page 11]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
Total Number of Multicast Labels
The total number of multicast labels the sending router can
support on the interface the Hello is sent on.
Router Count
The approximate maximum number of routers that may be connected to
the subnet the Hello is sent on.
Lower Label Range
The lower label value in the label range that was been randomly
selected by the sending router. This value must be less than the
Upper Label Range value.
Upper Label Range
The upper label value in the label range that was been randomly
selected by the sending router. This value must be greater than
the Lower Label Range value.
VCI Capability TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = 18 | OptionLength = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Direction |
+-+-+-+-+-+-+-+-+
Direction
When set to 0, VCI capability is bidirectional. When set to 1, VCI
capability is unidirectional. Bidirectional capability indicates
an ATM-LSR issuing this option can, within a single VPI, support
binding of the same VCI to different routes on the different
directions of the link. Unidirectional capability indicates an
ATM-LSR issuing this option can, within a single VPI, a single VCI
may appear in one binding only. In such systems when a VCI has
been bound in one direction on the link it may not be used in the
other.
Priority TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = 19 | OptionLength = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Farinacci, et al. [Page 12]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Priority
When several LSRs on a LAN allocate the same label range, this
field is used to determine which one of those LSRs may keep the
allocation. The Priority field is treated as a 32-bits unsigned
integer. Higher value is associated with higher Priority.
4. Label Distribution for PIM-DM
In dense-mode PIM, there is no downstream Join message traveling
upstream to perform the binding of multicast routes with labels.
However, since we don't want a separate algorithm for dense-mode
groups, we extend this basic design for dense-mode PIM.
When a downstream LSR creates (S,G) state from the receipt of 1)
data, or 2) Join/Prune or Graft messages, it will start a periodic
timer to send Join messages with label assignment information
present. The messages look no different and are treated on receipt no
differently than in the sparse-mode case.
The periodic Join message will be multicast on the LAN with an
upstream target address of 0.0.0.0. All multicast LSRs on the LAN
must know the group operates in dense-mode. This is accomplished
using standard PIM mechanisms.
5. Security Considerations
The security considerations for MPLS in general and label
distribution in particular are discussed in [MPLS-ARCH] and [LDP]
respectively. Security considerations for PIM are discussed in
[PIMv2].
The use of IPSEC for securing the PIM messages, as suggested in
[PIMv2], provides adequate security for this application.
Farinacci, et al. [Page 13]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
6. Acknowledgments
The authors would like to thank Fred Baker for his comments. We also
thank the authors of [MPLS-MUL-FR] for their critique of an earlier
version.
9.0 Author's Addresses
Dino Farinacci
Procket Networks, Inc.
3850 North First Street
San Jose, CA 95134
Email: dino@procket.com
Yakov Rekhter
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
Email: yakov@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
Email: erosen@cisco.com
Ted Qian
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
Email: tqian@cisco.com
Farinacci, et al. [Page 14]
Internet Draft draft-farinacci-mpls-multicast-02.txt June 2000
7. References
[LDP] "LDP Specification", draft-ietf-mpls-ldp-7.txt, Andersson,
Doolan, Feldman, Fredette, Thomas, June 2000.
[MPLS-ARCH] "Multiprotocol Label Switching Architecture", draft-
ietf-mpls-arch-06.txt, Rosen, Viswanathan, Callon, August 1999.
[PIMv1] "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol" Specification", RFC 2362, Estrin, Farinacci, Helmy, Thaler,
Deering, Handley, Jacobson, Liu, Sharma, Wei, June 1998.
[PIMv2] "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", draft-ietf-pim-v2-sm-01.txt, Wei, et. al.,
November, 1999.
[PIM-BIDIR] "Bi-directional Protocol Independent Multicast", <draft-
ietf-pim-bidir-00.txt>, Handley, Kouvelas, and Vicisano, March 2000.
[MPLS-ENCAPS] "MPLS Label Stack Encoding", <draft-ietf-mpls-label-
encaps-07.txt>, Rosen, Rekhter, Farinacci, Tappan, Fedorkow, Li,
Conta, September 1999.
[MPLS-MUL-FR] "Framework for IP Multicast in MPLS", <draft-ietf-
mpls-multicast-01.txt>, Ooms, Sales, Livens, Acharya, Griffoul,
Ansari, May 2000.
[MPLS-ATM] "MPLS using LDP and ATM VC Switching", <draft-ietf-mpls-
atm-02.txt>, Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow,
Doolan, April 1999.
Farinacci, et al. [Page 15]