draft-ietf-mpls-multicast-08.txt   rfc3353.txt 
Network Working Group D. Ooms, B. Sales Network Working Group D. Ooms
Internet Draft Alcatel Request for Comments: 3353 Alcatel
Expiration Date: October 2002 W. Livens Category: Informational B. Sales
Alcatel
W. Livens
Colt Telecom Colt Telecom
A. Acharya A. Acharya
IBM IBM
F. Griffoul F. Griffoul
Ulticom Ulticom
F. Ansari F. Ansari
Bell Labs Bell Labs
August 2002
April 2002 Overview of IP Multicast in a
Multi-Protocol Label Switching (MPLS) Environment
Framework for IP Multicast in MPLS
draft-ietf-mpls-multicast-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document offers a framework for IP multicast deployment in an This document offers a framework for IP multicast deployment in an
MPLS environment. Issues arising when MPLS techniques are applied to MPLS environment. Issues arising when MPLS techniques are applied to
IP multicast are overviewed. The pros and cons of existing IP IP multicast are overviewed. The pros and cons of existing IP
multicast routing protocols in the context of MPLS are described and multicast routing protocols in the context of MPLS are described and
the relation to the different trigger methods and label distribution the relation to the different trigger methods and label distribution
modes are discussed. The consequences of various layer 2 (L2) modes are discussed. The consequences of various layer 2 (L2)
technologies are listed. Both point-to-point and multi-access technologies are listed. Both point-to-point and multi-access
networks are considered. networks are considered.
Table of Contents Table of Contents
1. Introduction 1. Introduction ............................................. 3
2. Layer 2 characteristics 2. Layer 2 Characteristics .................................. 4
3. Taxonomy of IP multicast routing protocols in the context of MPLS 3. Taxonomy of IP Multicast Routing Protocols
3.1. Aggregation in the Context of MPLS ................................... 5
3.2. Flood & Prune 3.1. Aggregation .............................................. 5
3.3. Source/Shared trees 3.2. Flood & Prune ............................................ 5
3.4. Co-existence of Source and Shared Trees 3.3. Source/Shared Trees ...................................... 6
3.5. Uni/Bi-directional Shared Trees 3.4. Co-existence of Source and Shared Trees .................. 7
3.6. Encapsulated multicast data 3.5. Uni/Bi-directional Shared Trees .......................... 10
3.7. Loop-free-ness 3.6. Encapsulated Multicast Data .............................. 11
3.8. Mapping of characteristics on existing protocols 3.7. Loop-free-ness ........................................... 11
4. Mixed L2/L3 forwarding in a single node 3.8. Mapping of Characteristics on Existing Protocols ......... 11
5. Taxonomy of IP multicast LSP triggers 4. Mixed L2/L3 Forwarding in a Single Node .................. 12
5.1. Request driven 5. Taxonomy of IP Multicast LSP Triggers .................... 14
5.1.1. General 5.1. Request Driven ........................................... 14
5.1.2. Multicast routing messages 5.1.1. General .................................................. 14
5.1.3. Resource reservation messages 5.1.2. Multicast Routing Messages ............................... 15
5.2. Topology driven 5.1.3. Resource Reservation Messages ............................ 15
5.3. Traffic driven 5.2. Topology Driven .......................................... 16
5.3.1. General 5.3. Traffic Driven ........................................... 16
5.3.2. An implementation example 5.3.1. General .................................................. 16
5.4. Combinations of triggers and label distribution modes 5.3.2. An Implementation Example ................................ 17
6. Piggy-backing 5.4. Combinations of Triggers and Label Distribution Modes .... 18
7. Explicit routing 6. Piggy-backing ............................................ 18
8. QoS/CoS 7. Explicit Routing ......................................... 20
8.1 DiffServ 8. QoS/CoS .................................................. 20
8.2 IntServ and RSVP 8.1. DiffServ ................................................. 20
9. Multi-access networks 8.2. IntServ and RSVP ......................................... 21
10. More issues 9. Multi-access Networks .................................... 21
10.1. TTL field 10. More Issues .............................................. 22
10.2. Independent vs. Ordered Label Distribution Control 10.1. TTL Field ................................................ 22
10.3. Conservative vs. Liberal Label Retention Mode 10.2. Independent vs. Ordered Label Distribution Control ....... 23
10.4. Downstream vs. Upstream Label Allocation 10.3. Conservative vs. Liberal Label Retention Mode ............ 24
10.5. Explicit vs. Implicit Label Distribution 10.4. Downstream vs. Upstream Label Allocation ................. 25
11. Security Considerations 10.5. Explicit vs. Implicit Label Distribution ................. 25
12. Acknowledgements 11. Security Considerations .................................. 26
12. Acknowledgements ......................................... 26
Informative References........................................... 27
Authors' Addresses .............................................. 28
Full Copyright Statement ........................................ 30
Table of Abbreviations Table of Abbreviations
ATM Asynchronous Transfer Node ATM Asynchronous Transfer Node
CBT Core Based Tree CBT Core Based Tree
CoS Class of Service CoS Class of Service
DLCI Data Link Connection Identifier DLCI Data Link Connection Identifier
DRrecv Designated Router of the receiver DRrecv Designated Router of the receiver
DRsend Designated Router of the sender DRsend Designated Router of the sender
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
MOSPF Multicast OSPF MOSPF Multicast OSPF
mp2mp multipoint-to-multipoint mp2mp multipoint-to-multipoint
MRT Multicast Routing Table
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
RPT-bit RP Tree bit [DEER] RPT-bit RP Tree bit [DEER]
RSVP Resource reSerVation Protocol RSVP Resource reSerVation Protocol
SPT-bit Shortest Path Tree [DEER] SPT-bit Shortest Path Tree [DEER]
SSM Source Specific Multicast SSM Source Specific Multicast
TCP Transmission Control Protocol TCP Transmission Control Protocol
skipping to change at page 3, line 42 skipping to change at page 3, line 50
VPI Virtual Path Identifier VPI Virtual Path Identifier
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.
that unicast protocols can behave slightly different with regard to Remark that unicast protocols can behave slightly different with
equal cost paths. regard to equal cost paths.
For multicast, the optimal solution (minimum cost to interconnect N For multicast, the optimal solution (minimum cost to interconnect N
nodes) would impose a Steiner tree computation. Unfortunately, no nodes) would impose a Steiner tree computation. Unfortunately, no
multicast routing protocol today is able to maintain such an optimal multicast routing protocol today is able to maintain such an optimal
tree. Different multicast protocols will therefore, in general, tree. Different multicast protocols will therefore, in general,
generate different trees. generate different trees.
The discussion is focused on intra-domain multicast routing The discussion is focused on intra-domain multicast routing
protocols. Aspects of inter-domain routing are beyond the scope of protocols. Aspects of inter-domain routing are beyond the scope of
this document. this document.
2. Layer 2 characteristics 2. Layer 2 Characteristics
Although MPLS is multiprotocol both at L3 and at L2, in practice IP Although MPLS is multiprotocol both at L3 and at L2, in practice IP
is the only considered L3 protocol. MPLS can run on top of several is the only considered L3 protocol. MPLS can run on top of several
L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...). L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...).
When label switching is mapped on L2 switching capabilities (e.g. When label switching is mapped on L2 switching capabilities (e.g.
VPI/VCI is used as label), attention is mainly focused on the mapping VPI/VCI is used as label), attention is mainly focused on the mapping
to ATM [DAVI]. ATM offers high switching capacities and QoS to ATM [DAVI]. ATM offers high switching capacities and QoS
awareness, but in the context of MPLS it poses several limitations awareness, but in the context of MPLS it poses several limitations
which are described in [DAVI]. Similar considerations are made for which are described in [DAVI]. Similar considerations are made for
Frame Relay on L2 in [CONT]. The limitations can be summarized as: Frame Relay on L2 in [CONT]. The limitations can be summarized as:
- Limited Label Space: either the standardized or the implemented - Limited Label Space: either the standardized or the implemented
number of bits available for a label can be small (e.g. VPI/VCI number of bits available for a label can be small (e.g. VPI/VCI
space, DLCI space), limiting the number of LSPs that can be space, DLCI space), limiting the number of LSPs that can be
established. established.
- Merging: some L2 technologies or implementations of these - Merging: some L2 technologies or implementations of these
technologies do not support multipoint-to-point and/or multipoint- technologies do not support multipoint-to-point and/or
to-multipoint 'connections', obstructing the merging of LSPs. multipoint-to-multipoint 'connections', obstructing the merging of
LSPs.
- TTL: L2 technologies do not support a 'TTL-decrement' function. - TTL: L2 technologies do not support a 'TTL-decrement' function.
All three limitations can impact the implementation of multicast in All three limitations can impact the implementation of multicast in
MPLS as will be described in this document. MPLS as will be described in this document.
When native MPLS is deployed the above limitations vanish. Moreover When native MPLS is deployed the above limitations vanish. Moreover
on PPP and Ethernet links the same label can be used at the same time on PPP and Ethernet links the same label can be used at the same time
for a unicast and a multicast LSP because different EtherTypes for for a unicast and a multicast LSP because different EtherTypes for
MPLS unicast and multicast are defined [ROSE]. MPLS unicast and multicast are defined [ROSE].
3. Taxonomy of IP multicast routing protocols in the context of MPLS 3. Taxonomy of IP Multicast Routing Protocols in the Context of MPLS
At the moment, an abundance of IP multicast routing protocols is At the moment, an abundance of IP multicast routing protocols is
being proposed and developed. All these protocols have different being proposed and developed. All these protocols have different
characteristics (scalability, computational complexity, latency, characteristics (scalability, computational complexity, latency,
control message overhead, tree type, etc...). It is not the purpose control message overhead, tree type, etc...). It is not the purpose
of this document to give a complete taxonomy of IP multicast routing of this document to give a complete taxonomy of IP multicast routing
protocols, only their characteristics relevant to the MPLS technology protocols, only their characteristics relevant to the MPLS technology
will be addressed. will be addressed.
Following characteristics are considered: The following characteristics are considered:
- Aggregation - Aggregation
- Flood & Prune - Flood & Prune
- Source/Shared trees - Source/Shared trees
- Co-existence of Source and Shared Trees - Co-existence of Source and Shared Trees
- Uni/Bi-directional shared trees - Uni/Bi-directional shared trees
- Encapsulated multicast data - Encapsulated multicast data
- Loop-free-ness - Loop-free-ness
The discussion of these characteristics will not lead to the The discussion of these characteristics will not lead to the
skipping to change at page 5, line 44 skipping to change at page 6, line 6
To establish a multicast tree some IP multicast routing protocols To establish a multicast tree some IP multicast routing protocols
(e.g. DVMRP, PIM-DM) flood the network with multicast data. The (e.g. DVMRP, PIM-DM) flood the network with multicast data. The
branches can then be pruned by nodes which do not want to receive the branches can then be pruned by nodes which do not want to receive the
data of the specific multicast group. This process is repeated data of the specific multicast group. This process is repeated
periodically. periodically.
Flood & Prune multicast routing protocols have some characteristics Flood & Prune multicast routing protocols have some characteristics
which significantly differ from unicast routing protocols: which significantly differ from unicast routing protocols:
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
L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of dynamic L3 p2mp tree to a L2 p2mp LSP need to be efficient in
signaling overhead and LSP setup time. The volatile L2 LSP will terms of signaling overhead and LSP setup time. The volatile L2
consume a lot of labels throughout the network, which is a LSP will consume a lot of labels throughout the network, which is
disadvantage when label space is limited. a 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
to remove state when an inactivity timer expires. decide to remove state when an inactivity timer expires.
- Thus LSPs can not be pre-established as is usually done in
unicast. To minimize the time between traffic arrival and LSP
establishment a fast LSP setup method is favorable.
- Since creation and deletion of a L3 route at each node is
triggered by traffic, this suggests that the LSP associated with the
route be setup and torn down in a traffic-driven manner as well.
- If an LSR does not support L3 forwarding this traffic-driven
nature even requires that the upstream LSR takes the initiative to
create an LSP (Upstream Unsolicited or Downstream on Demand label
advertisement).
3.3. Source/Shared trees - Thus LSPs can not be pre-established as is usually done in
unicast. To minimize the time between traffic arrival and LSP
establishment a fast LSP setup method is favorable.
- Since creation and deletion of a L3 route at each node is
triggered by traffic, this suggests that the LSP associated with
the route be setup and torn down in a traffic-driven manner as
well.
- If an LSR does not support L3 forwarding this traffic-driven
nature even requires that the upstream LSR takes the initiative
to create an LSP (Upstream Unsolicited or Downstream on Demand
label advertisement).
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 / / /
\ / / / \ / / /
\ / / / \ / / /
C---R2 S1---R2 S2---R2 C---R2 S1---R2 S2---R2
skipping to change at page 6, line 42 skipping to change at page 7, line 6
S2 \ \ \ S2 \ \ \
R3 R3 R3 R3 R3 R3
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 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 new sources of the group and a switchover to a source tree is made at
very low bitrates. 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
messages are shown in the figures. It is also indicated whether the Join/Prune messages are shown in the figures. It is also indicated
RPT-bit is set for the (S, G) state. whether the RPT-bit is set for the (S, G) state.
1) Figure 2 shows a switchover from shared to source tree. Assume 1) Figure 2 shows a switchover from shared to source tree. Assume
that the shortest path from R1 to RP is via N1-N2-N5. N1, the that the shortest path from R1 to RP is via N1-N2-N5. N1, the
Designated Router of receiver R1 (DRrecv), decides to initiate a Designated Router of receiver R1 (DRrecv), decides to initiate a
source tree for source S1. After the arrival of data via the source source tree for source S1. After the arrival of data via the
tree in N2, N2 will send a prune to N5 for source S1. State co- source tree in N2, N2 will send a prune to N5 for source S1.
existence occurs in the node where the overlap of shared and source State co-existence occurs in the node where the overlap of shared
tree starts (N2) and in the node where S1 does not need forwarding on and source tree starts (N2) and in the node where S1 does not need
the shared tree anymore (N5). forwarding on the shared tree anymore (N5).
PJ PJ
IJ PJS PJS IJ PJS PJS
-> 1 2 -> 1 2 -> 1 2 -> 1 2 -> 1 2 -> 1 2
R1-----N1------N2------N3----S1 R1-----N1------N2------N3----S1
3| |3 IJ=Igmp Join 3| |3 IJ=Igmp Join
||PPS | PJ=Pim Join (*,G) ||PPS | PJ=Pim Join (*,G)
|vPJ | PJS=Pim Join (S1,G) |vPJ | PJS=Pim Join (S1,G)
IJ PJ | PJ | PPS=Pim Prune (S1,G) IJ PJ | PJ | PPS=Pim Prune (S1,G)
-> -> |3 -> | -> -> |3 -> |
R2-----N4------N5------RP----S2 R2-----N4------N5------RP----S2
1 2 1 2 1 1 2 1 2 1
Figure 2 Figure 2
The multicast routing states created in the MRT are: The multicast routing states created in the Multicast Routing Table
(MRT) are:
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):2->1 in N1: (*,G):2->1
in N2: (*,G):3->1 in N2: (*,G):3->1
(S1,G):2->1 (S1,G):2->1
in N3: (S1,G):2->Reg,1 in N3: (S1,G):2->Reg,1
in N4: (*,G):2->1 in N4: (*,G):2->1
in N5: (*,G):2->1,3 in N5: (*,G):2->1,3
(S1,G)RPT-bit:2->1 (S1,G)RPT-bit:2->1
2) Figure 3 shows that even without a switchover, state co-existence 2) Figure 3 shows that even without a switchover, state co-existence
can occur. Multicast traffic from a sender will create (S, G) state can occur. Multicast traffic from a sender will create (S, G)
in the Designated Router of the sender (DRsend; N3 in Figure 3 is the state in the Designated Router of the sender (DRsend; N3 in Figure
DRsend of S). Each node on a shared-tree has (*, G) state. Thus an 3 is the DRsend of S). Each node on a shared-tree has (*, G)
on-tree DRsend has both (*, G) and (S, G) state. If the DRsend is state. Thus an on-tree DRsend has both (*, G) and (S, G) state.
on-tree it will also send a prune for S towards the RP, creating (S, If the DRsend is on-tree it will also send a prune for S towards
G) state in all nodes until the first router which has a branch (N1 the RP, creating (S, G) state in all nodes until the first router
and N2 in Figure 3). which has a branch (N1 and N2 in Figure 3).
S S
PPS PPS | PPS PPS |
PJ PJ PJ |2 PJ IJ PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join 1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G) ^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ PJ|| IJ
1| <- 1| <-
N5----R2 N5----R2
2 2
Figure 3 Figure 3
The multicast routing states created in the MRT are: The multicast routing states created in the MRT are:
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3 in N1: (*,G):1->2,3
(S,G)RPT-bit:1->2 (S,G)RPT-bit:1->2
in N2: (*,G):1->2 in N2: (*,G):1->2
(S,G)RPT-bit:1->none (S,G)RPT-bit:1->none
in N3: (*,G):1->3 in N3: (*,G):1->3
(S,G):2->Reg,3 (S,G):2->Reg,3
in N4: (*,G):1->2 in N4: (*,G):1->2
in N5: (*,G):1->2 in N5: (*,G):1->2
In the examples one can observe that two types of state co-existence In the examples one can observe that two types of state co-
occur: existence occur:
1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The 1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The
(*, G) and (S, G) state have different incoming interfaces, but some (*, G) and (S, G) state have different incoming interfaces, but
common outgoing interfaces. It is possible that the traffic of S some common outgoing interfaces. It is possible that the traffic
arrives on both the (*, G) and (S, G) interfaces. In normal L3 of S arrives on both the (*, G) and (S, G) interfaces. In normal
forwarding the (S, G)SPT-bit entry prohibits the forwarding of the L3 forwarding the (S, G)SPT-bit entry prohibits the forwarding of
traffic from S arriving on the (*, G) incoming interface. The the traffic from S arriving on the (*, G) incoming interface. The
traffic of S can only temporarily arrive on the incoming interfaces traffic of S can only temporarily arrive on the incoming
of both the (*, G) and (S, G) entries (until N5 in Figure 2 and N1 in interfaces of both the (*, G) and (S, G) entries (until N5 in
Figure 3 have processed the prune messages). To avoid the temporary Figure 2 and N1 in Figure 3 have processed the prune messages).
forwarding of duplicate packets L3 forwarding can be applied in this To avoid the temporary forwarding of duplicate packets L3
type of node. If one does not mind the temporary duplicate packets forwarding can be applied in this type of node. If one does not
L2 forwarding can be applied. In this case the (*, G) and (S, G) mind the temporary duplicate packets L2 forwarding can be applied.
streams have to be merged into the (*, G) LSP on their common In this case the (*, G) and (S, G) streams have to be merged into
outgoing interfaces. the (*, G) LSP on their common outgoing interfaces.
2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The (*, 2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The
G) and (S, G) state have the same incoming interface. The (S, G) (*, G) and (S, G) state have the same incoming interface. The (S,
traffic must be extracted from the (*, G) stream. In MPLS this state G) traffic must be extracted from the (*, G) stream. In MPLS this
co-existence can be handled in several ways. Four approaches to this state co-existence can be handled in several ways. Four
problem will be described: approaches to this problem will be described:
a) A first method to handle this state co-existence is to terminate a) A first method to handle this state co-existence is to
the LSPs and forward all traffic of this group at L3. However a terminate the LSPs and forward all traffic of this group at L3.
return to L3 can be avoided in case a (S, G) entry without outgoing However a return to L3 can be avoided in case a (S, G) entry
interface is added to the MRT (N2 in Figure 3). This entry will only without an outgoing interface is added to the MRT (N2 in Figure
receive traffic temporarily. In this particular case one could 3). This entry will only receive traffic temporarily. In this
ignore the (S, G) state and maintain the existing (*, G) LSP, the particular case one could ignore the (S, G) state and maintain
disadvantage being duplicate traffic for a very short time. the existing (*, G) LSP, the disadvantage being duplicate
traffic for a very short time.
b) A second approach is to assign source specific labels on the nodes b) A second approach is to assign source specific labels on the
of the shared tree. Multiple labels will be associated with one (*, nodes of the shared tree. Multiple labels will be associated
G) entry, corresponding to one label per active source. Since the with one (*, G) entry, corresponding to one label per active
nodes only know which sources are active when traffic from these source. Since the nodes only know which sources are active
sources arrives, the LSPs can not be pre-established and a fast LSP when traffic from these sources arrives, the LSPs cannot be
setup method is favorable. pre-established and a fast LSP setup method is favorable.
c) A third way is that only source trees are labelswitched and that c) A third way is that only source trees are labelswitched and
traffic on the shared tree is always forwarded at L3. This assumes that traffic on the shared tree is always forwarded at L3.
that the shared tree is only used as a way for the receivers to find This assumes that the shared tree is only used as a way for the
out who the sources are. By configuring a low bitrate switchover receivers to find out who the sources are. By configuring a
threshold one can obtain that the receivers switchover to source low bitrate switchover threshold, one can ensure that the
trees very quickly. receivers switchover to source trees very quickly.
d) In the fourth approach an LSR which has (S, G)RPT-bit state with a d) In the fourth approach, an LSR which has (S, G) RPT-bit state
non-null oif, advertises a label for (S, G) to the upstream LSR and with a non-null oif, advertises a label for (S, G) to the
this label advertisement is then propagated by each upstream LSR upstream LSR and this label advertisement is then propagated by
towards the RP. In this way a dedicated LSP is created for (S, G) each upstream LSR towards the RP. In this way a dedicated LSP
traffic from the RP to the LSR with the (S, G)RPT-bit state. In the is created for (S, G) traffic from the RP to the LSR with the
latter LSR the (S, G) LSP is merged onto the (*, G) LSP for the (S, G) RPT-bit state. In the latter LSR, the (S, G) LSP is
appropriate outgoing interfaces. This ensures that (S, G) packets merged onto the (*, G) LSP for the appropriate outgoing
traveling on the shared tree do not make it past any LSR which has interfaces. This ensures that (S, G) packets traveling on the
pruned S. shared tree do not make it past any LSR which has pruned S.
3.5. Uni/Bi-directional Shared Trees 3.5. Uni/Bi-directional Shared Trees
Bidirectional shared trees (e.g. CBT) have the disadvantage of Bidirectional shared trees (e.g. CBT [BALL]) have the disadvantage of
creating a lot of merging points (M) in the nodes (N) of the shared creating a lot of merging points (M) in the nodes (N) of the shared
tree. Figure 4 shows these merging points resulting from 2 senders S1 tree. Figure 4 shows these merging points resulting from 2 senders
and S2 on a bidirectional tree. S1 and S2 on a bidirectional tree.
S1 S2 S1 S2
|| || || ||
v| <- <- <- <- |v v| <- <- <- <- |v
<- <- | -> -> -> -> | -> <- <- | -> -> -> -> | ->
----N----M----M----M----M----M----N ----N----M----M----M----M----M----N
|| || || || || || || || || || || ||
|v |v |v |v |v |v |v |v |v |v |v |v
| | | | | | | | | | | |
Figure 4. Multicast traffic flows from 2 senders on a bidirectional tree Figure 4.
Multicast traffic flows from 2 senders on a bidirectional tree
In Figure 5 the same situation for unidirectional shared trees is In Figure 5 the same situation for unidirectional shared trees is
depicted. In this case the data of the senders is tunneled towards depicted. In this case the data of the senders is tunneled towards
the root node R, yielding only a single merging point, namely the the root node R, yielding only a single merging point, namely the
root of the shared tree itself. root of the shared tree itself.
S1 S1
tunnel || S2 tunnel || S2
<----- v| tunnel || <----- v| tunnel ||
to R<------------------------- v| to R<------------------------- v|
-> -> | -> -> -> -> | -> -> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N ----N----N----N----N----N----N----N
|| || || || || || || || || || || ||
|v |v |v |v |v |v |v |v |v |v |v |v
| | | | | | | | | | | |
Figure 5. Multicast traffic flows from 2 senders on a unidirectional tree Figure 5.
Multicast traffic flows from 2 senders on a unidirectional tree
3.6. Encapsulated multicast data 3.6. Encapsulated Multicast Data
Sources of unidirectional shared trees and non-member sources of Sources of unidirectional shared trees and non-member sources of
bidirectional shared trees encapsulate the data towards the root bidirectional shared trees encapsulate the data towards the root
node. The data is then decapsulated in the root node. The node. The data is then decapsulated in the root node. The
encapsulation and decapsulation of multicast data are L3 processes. encapsulation and decapsulation of multicast data are L3 processes.
Thus in case of encapsulation/decapsulation a path can never be Thus in case of encapsulation/decapsulation a path can never be
mapped onto an end-to-end LSP: the traffic can not be forwarded on L2 mapped onto an end-to-end LSP: the traffic can not be forwarded on
on the Register interface of the DRsend (encapsulation), nor can it L2 on the Register interface of the DRsend (encapsulation), nor can
cross the root (decapsulation) at L2. it cross the root (decapsulation) at L2.
Remarks: Remarks:
1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G) 1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G)
traffic in DRsend can still be forwarded on L2 on the outgoing traffic in DRsend can still be forwarded at L2 on all outgoing
interfaces which are not the Register interface. interfaces other than the Register interface.
2) The encapsulated traffic can also benefit from MPLS by label 2) The encapsulated traffic can also benefit from MPLS by label
switching the tunnels. switching the tunnels.
3) If the root node decides to join the source (to avoid 3) If the root node decides to join the source (to avoid
encapsulation/decapsulation), an end-to-end (S, G) LSP can be encapsulation/decapsulation), an end-to-end (S, G) LSP can be
constructed. constructed.
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.
Currently loop detection is a configurable option in LDP and a Currently loop detection is a configurable option in LDP and a
decision on the mechanism for loop prevention is postponed. decision on the mechanism for loop prevention is postponed.
3.8. Mapping of characteristics on existing protocols 3.8. 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
exhaustive list of existing IP multicast routing protocols: DVMRP non-exhaustive list of existing IP multicast routing protocols:
[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER],
[HOLB], SM [PERL]. SSM [HOLB], SM [PERL].
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |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 |source|shared| |Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
skipping to change at page 12, line 4 skipping to change at page 12, line 22
|Tree Type |source|source|shared|source|both |source|shared| |Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |no |no | |State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |no |yes | |Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+------+------+ +------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |no |no | |Loop Free |no |no |no |no |no |no |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
Since unicast traffic has one incoming and one outgoing interface the Since unicast traffic has one incoming and one outgoing interface the
traffic is either forwarded at L2 OR at L3 (Figure 6). Because traffic is either forwarded at L2 OR at L3 (Figure 6). Because
multicast traffic can be forwarded to more than one outgoing multicast traffic can be forwarded to more than one outgoing
interface one can consider the case that traffic to some branches is interface one can consider the case that traffic to some branches is
forwarded on L2 and to other branches on L3 (Figure 7). forwarded on L2 and to other branches on L3 (Figure 7).
+--------+ +--------+ +--------+ +--------+
| L3 | | L3 | | L3 | | L3 |
| +>>+ | | | | +>>+ | | |
skipping to change at page 12, line 44 skipping to change at page 13, line 17
| +>>++ | | +>>+ | | | | +>>++ | | +>>+ | | |
| | || | | | | | | | | | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+ +--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +----> | | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ | ->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +----> | L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2 Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
Nodes which support this 'mixed L2/L3 forwarding' feature allow that Nodes that support this 'mixed L2/L3 forwarding' feature allow
a multicast tree splits in branches of which some are forwarded at L3 splitting of a multicast tree into branches in which some are
while others are switched at L2. forwarded at L3 while others are switched at L2.
The L3 forwarding has to take care that the traffic is not forwarded The L3 forwarding has to take care that the traffic is not forwarded
on those branches that already get their traffic on L2. This can be on those branches that already get their traffic on L2. This can be
accomplished by e.g. providing an extra bit in the Multicast Routing accomplished by e.g. providing an extra bit in the Multicast Routing
Table. Table.
Although the mixed L2/L3 forwarding requires processing of the Although the mixed L2/L3 forwarding requires processing of the
traffic at L3, the load on the L3 forwarding engine is generally less traffic at L3, the load on the L3 forwarding engine is generally less
than in a pure L3 node. than in a pure L3 node.
Supporting this 'mixed L2/L3 forwarding' feature has following Supporting this 'mixed L2/L3 forwarding' feature has the following
advantages: advantages:
a) Assume LSR A (Figure 8) is an MPLS edge node for the branch a) Assume LSR A (Figure 8) is an MPLS edge node for the branch
towards LSR B and an MPLS core node for the branch towards LSR C. towards LSR B and an MPLS core node for the branch towards LSR C.
The mixed L2/L3 forwarding allows that the branch towards C is not The mixed L2/L3 forwarding allows that the branch towards C is not
disturbed by a return to L3 in LSR A. disturbed by a return to L3 in LSR A.
+-------------+ +-------------+
| MPLS cloud | | MPLS cloud |
| N | | N |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| 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) Enables the use of the traffic driven trigger with the Downstream b) Enables the use of the traffic driven trigger with the Downstream
Unsolicited or Upstream on Demand label distribution mode, as Unsolicited or Upstream on Demand label distribution mode, as
explained in section 5.3.1. explained in section 5.3.1.
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
there is no traffic. if 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.
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
skipping to change at page 14, line 41 skipping to change at page 15, line 6
| | | | | | | |
| | | | | | | |
|----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 Unsolicited mode) or an LDP bind request an LDP bind (Upstream Unsolicited mode) or an LDP bind request
(Downstream on 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 disadvantage that the 'routing calculations' performed by the
multicast routing daemon to determine the Multicast Routing Table are multicast routing daemon to determine the Multicast Routing Table are
repeated by the MPLS module. The former determines the tree that will repeated by the MPLS module. The former determines the tree that
be used at L3, the latter calculates an identical tree to be used by will be used at L3, the latter calculates an identical tree to be
L2. Since the same task is performed twice, it is better to create used by L2. Since the same task is performed twice, it is better to
the multicast LSP on the basis of information extracted from the create the multicast LSP on the basis of information extracted from
Multicast Routing Table itself (see section 5.2 and 5.3). The 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.
5.1.3. Resource reservation messages 5.1.3. Resource Reservation Messages
As is the case for unicast the RSVP Resv message can be used as a As is the case for unicast the RSVP Resv message can be used as a
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.
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. The MPLS module maps this L3 tree topology routing protocol daemon. The MPLS 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
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 Unsolicited mode). In Figure 10, suppose an LSP Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP
for a certain group exists to LSRd1 and another LSRd2 wants to join for a certain group exists to LSRd1 and another LSRd2 wants to join
the tree. In order for LSRd2 to initiate a trigger, it must already the tree. In order for LSRd2 to initiate a trigger, it must already
receive the traffic from the tree. This can be either at L2 or at receive the traffic from the tree. This can be either at L2 or at
L3. The former case is a chicken and egg problem. The latter case L3. The former case is a chicken and egg problem. The latter case
requires a mixed L2/L3 forwarding capability in LSRu to add the L3 requires a mixed L2/L3 forwarding capability in LSRu to add the L3
branch. branch.
+--------+ +--------+
| LSRd1 | | LSRd1 |
| | | |
+--------+ | L3 | +--------+ | L3 |
| LSRu | +--------+ | LSRu | +--------+
| | | | | | | |
| L3 | +--------------------------> | L3 | +-------------------------->
skipping to change at page 17, line 27 skipping to change at page 17, line 27
| | | |
| L3 | | L3 |
+--------+ +--------+
| | | |
| | | |
| L2 | | L2 |
+--------+ +--------+
Figure 10. The LSRu has to request the label. Figure 10. The LSRu has to request the label.
5.3.2. An implementation example 5.3.2. An Implementation Example
To illustrate that by choosing an appropriate trigger one can obtain To illustrate that by choosing an appropriate trigger one can
that MPLS multicast is independent of the deployed multicast routing conclude that MPLS multicast is independent of the deployed multicast
protocol following implementation example is given. routing protocol, the following implementation example is given.
Current implementations on Unix platforms of IP multicast routing Current implementations on Unix platforms of IP multicast routing
protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The
MFC is a cached copy of the Multicast Routing Table. The MFC MFC is a cached copy of the Multicast Routing Table. The MFC
requests an entry for a certain multicast group when it experiences a requests an entry for a certain multicast group when it experiences a
'cache miss' for an incoming multicast packet. The missing routing 'cache miss' for an incoming multicast packet. The missing routing
information is provided by the multicast daemon. If at a later point information is provided by the multicast daemon. If at a later point
in time something changes to the route (outgoing interfaces added or in time something changes to the route (outgoing interfaces added or
removed), the multicast daemon will update the MFC. removed), the multicast daemon will update the MFC.
The MFC is implemented as a common component (part of the kernel), The MFC is implemented as a common component (part of the kernel),
which makes this trigger very attractive because it can be which makes this trigger very attractive because it can be
transparently used for any IP multicast routing protocol. transparently used for any IP multicast routing protocol.
Entries in the MFC are removed when no traffic is received for this Entries in the MFC are removed when no traffic is received for this
entry for a certain period of time. When label switching is applied entry for a certain period of time. When label switching is applied
to a certain MFC-entry, the L3 will not see any packets arriving to a certain MFC-entry, the L3 will not see any packets arriving
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 that 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 |
| |unsolicited|on demand |unsolicited|on demand | | |unsolicited|on demand |unsolicited|on demand |
+----------------+-----------+----------+-----------+----------+ +----------------+-----------+----------+-----------+----------+
skipping to change at page 18, line 39 skipping to change at page 18, line 39
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 such 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
to be defined. has 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 [AWDU]. also applicable to multicast, is proposed in [AWDU].
The pro and cons of piggy-backing on multicast routing messages will The pros 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 the 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.
Following disadvantages of piggy-backing can be identified: Following disadvantages of piggy-backing can be identified:
a) In dense-mode protocols there are no messages on which the label a) In dense-mode protocols there are no messages on which the label
advertisement can be piggy-backed. [FARI] proposes to add periodic advertisement can be piggy-backed. [FARI] proposes to add
messages to dense-mode protocols for the purpose of label periodic 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
backing. piggy-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) cannot be applied in combination with piggy-backing.
c) Piggybacking requires extending the multicast routing protocol, c) Piggy-backing 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
supported for multiple multicast routing protocols. Especially when be supported for multiple multicast routing protocols. Especially
not only the label advertisement but also the other two LDP functions when not only the label advertisement but also the other two LDP
(discovery and adjacency) are piggy-backed. functions (discovery and adjacency) are piggy-backed.
d) Piggy-backing assumes the Downstream Unsolicited label d) Piggy-backing assumes the Downstream Unsolicited label
distribution mode, this excludes a number of trigger methods (see distribution mode, this excludes a number of trigger methods (see
Table 2). 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
the reliable communication with periodic soft-state label replaces 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
newly established VC. This way only one message is required. This the newly established VC. This way only one message is
method cannot be combined with piggy-backing because the routing required. This method cannot be combined with piggy-backing
message is sent before the VC can be established. An extra handshake because the routing message is sent before the VC can be
message is thus required, diminishing the benefit of piggy-backing. established. An extra handshake message is thus required,
diminishing the benefit of piggy-backing.
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 Piggy-backing 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. table by using LSPs.
A first way to interpret "multicast explicit routing" is overriding A first way to interpret "multicast explicit routing" is overriding
the tree established by the multicast routing protocol by another LSP the tree established by the multicast routing protocol by another LSP
tree (e.g. a Steiner tree calculated by an offline tool). In this tree (e.g. a Steiner tree calculated by an off-line tool). In this
interpretation the current 'shortest path' multicast routing protocol interpretation the current 'shortest path' multicast routing protocol
becomes obsolete and can be replaced by label advertisement messages becomes obsolete and can be replaced by label advertisement messages
that follow an explicit route (e.g. a branch of the Steiner tree). that follow an explicit route (e.g. a branch of the Steiner tree).
A second way of interpreting "multicast explicit routing" is that the A second way of interpreting "multicast explicit routing" is that the
known multicast routing protocols are running, but that the messages known multicast routing protocols are running, but that the messages
generated by these protocols use explicit unicast routes (instead of generated by these protocols use explicit unicast routes (instead of
the IGP shortest path routes) to construct trees. the IGP shortest path routes) to construct trees.
8. QoS/CoS 8. QoS/CoS
skipping to change at page 21, line 11 skipping to change at page 21, line 18
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 (e.g. 1 The sender has to send its traffic twice across the network (e.g. 1
best-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
merging is necessary to avoid a return to L3 in the QoS LSP. available, 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
categories is studied in [GARR]. categories is studied in [GARR].
9. Multi-access networks 9. Multi-access Networks
Multicast MPLS on multi-access networks poses a special problem. An Multicast MPLS on multi-access networks poses a special problem. An
LSR that wants to join a group must always be ready to accept the LSR that wants to join a group must always be ready to accept the
label that is already assigned to the group LSP (to another label that is already assigned to the group LSP (to another
downstream LSR on the link). This can be achieved in three ways: downstream LSR on the link). This can be achieved in three ways:
1) Each LSR on the multi-access link memorizes all the advertised 1) Each LSR on the multi-access link memorizes all the advertised
labels on the link, even if it has not received a join for the labels on the link, even if it has not received a join for the
associated group. If an LSR is added to the multi-access link it has associated group. If an LSR is added to the multi-access link it
to retrieve this information from another LSR on the link or in case has to retrieve this information from another LSR on the link or
of soft state label advertisement it can wait a certain time before in case of soft state label advertisement it can wait a certain
it can allocate labels itself. If LSRs allocate a label 'at the same time before it can allocate labels itself. If LSRs allocate a
moment' the LSR with the highest IP address could keep it, while the label 'at the same moment' the LSR with the highest IP address
other LSRs withdraw the label. could keep it, while the 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 [FARI]. If an LSR mechanism for label partitioning is described in [FARI]. If an
is added to the multi-access link the label ranges have to be LSR 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 torn down and
reconstructed with other labels. are reconstructed with other labels.
3) Per multi-access link one LSR could be elected to be responsible 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
from this Label Allocation LSR. it 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
duplicates in time. duplicates in time.
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
the shared link. In this approach the hard-state character of LDP on the shared link. In this approach the hard-state character of
can be maintained but the label advertisement is duplicated in space. LDP 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 assignment. For multicast traffic, use upstream or downstream label assignment. For multicast traffic,
upstream label allocation is simpler since there can be only one upstream label allocation is simpler since there can be only 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 unique label for the FEC. With (upstream) node can assign a unique label for the FEC. 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 different given tree on a multi-access link; each node may propose a different
label assignment for a FEC which would require some resolution label assignment for a FEC that would require some resolution process
process in order to come of with a single label per multicast FEC on in order to come up with a single label per multicast FEC on the
the link. link.
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
due to a unicast topology change. due to a unicast topology change.
10. More issues 10. More Issues
10.1. TTL field 10.1. TTL Field
The TTL field in the IP header is typically used for loop detection. The TTL field in the IP header is typically used for loop detection.
In IP multicast it is also used to limit the scope of the multicast In IP multicast it is also used to limit the scope of the multicast
packets by setting an appropriate TTL value. packets by setting an appropriate TTL value.
Thus in LSRs that do not support a TTL decrement function (e.g ATM Thus in LSRs that do not support a TTL decrement function (e.g. ATM
LSR), the scope restriction function is affected. Suppose one could LSR), the scope restriction function is affected. Suppose one could
calculate in advance the number of hops an LSP traverses. In a calculate in advance the number of hops an LSP traverses. In a
unicast LSP the TTL value could then be decremented at the ingress or unicast LSP the TTL value could then be decremented at the ingress or
the egress node. For multicast all the branches of the tree can have the egress node. For multicast all the branches of the tree can have
different lengths so the TTL can only be decremented at the egress different lengths so the TTL can only be decremented at the egress
node, potentially wasting bandwidth if the TTL turns out to be zero node, potentially wasting bandwidth if the TTL turns out to be zero
or negative. or negative.
10.2. Independent vs. Ordered Label Distribution Control 10.2. Independent vs. Ordered Label Distribution Control
skipping to change at page 23, line 21 skipping to change at page 23, line 27
The following sections explore what this terminology might mean in a The following sections explore what this terminology might mean in a
multicast context. multicast context.
In Independent Control ([ANDE]) each LSR can take the initiative to In Independent Control ([ANDE]) each LSR can take the initiative to
do a label mapping. In Ordered Control ([ANDE]) an LSR only maps a do a label mapping. In Ordered Control ([ANDE]) an LSR only maps a
label when it already received a label from its next-hop. label when it already received a label from its next-hop.
All the previously described trigger methods (section 5) combine with All the previously described trigger methods (section 5) combine with
Independent Control. Note that if the request driven approach is Independent Control. Note that if the request driven approach is
used with Independent Control the label distribution still behaves as used with Independent Control the label distribution still behaves as
in Ordered Control: the control messages flow from the egress node in Ordered Control: the control messages flow from the egress node
upstream, imposing the same sequence to the label advertisement. upstream, imposing the same sequence to the label advertisement.
Ordered Control is not applicable for a traffic driven trigger in Ordered Control is not applicable for a traffic driven trigger in
case the node does not support mixed L2/L3 forwarding. According to case the node does not support mixed L2/L3 forwarding. According to
Table 2, this case implies that labels are requested by the upstream Table 2, this case implies that labels are requested by the upstream
LSR. Suppose in Figure 11 that an LSP exists from S to R1 and a new LSR. Suppose in Figure 11 that an LSP exists from S to R1 and a new
branch must be added to R2. B will only accept a label on the A-B branch must be added to R2. B will only accept a label on the A-B
link if a label is already assigned on the B-C link. However, to link if a label is already assigned on the B-C link. However, to
establish a label on the B-C link, B must already receive traffic on establish a label on the B-C link, B must already receive traffic on
the A-B link. the A-B link.
N---N---R1 N---N---R1
/ /
/ /
S -----A S -----A
\ \
\ \
B---C---R2 B---C---R2
Figure 11. Figure 11.
10.3. Conservative vs. Liberal Label Retention Mode 10.3. Conservative vs. Liberal Label Retention Mode
In the Conservative Mode ([ANDE]) only the labels that are used for In the Conservative Mode ([ANDE]) only the labels that are used for
forwarding data (if the next-hop for the FEC is the LSR which forwarding data (if the next-hop for the FEC is the LSR which
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 identified
Liberal Mode does not make sense in multicast. Two reasons can be 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
Unsolicited mode (see below) the LSR does not know where to send the Downstream Unsolicited mode (see below) the LSR does not know
label mappings and thus has to send the mapping to all its neighbors. where to send the label mappings and thus has to send the mapping
In this case supporting the Liberal Mode does not generate extra to all its neighbors. In this case supporting the Liberal Mode
messages (it still requires extra state information and label space) does not generate extra messages (it still requires extra state
and thus the threshold to support Liberal Mode could be considered information and label space) and thus the threshold to support
lower. Liberal Mode could be considered 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 |
+---------+----------------+-----------------| +---------+----------------+-----------------|
|unicast | Yes | No | |unicast | Yes | No |
+---------+----------------+-----------------| +---------+----------------+-----------------|
skipping to change at page 24, line 44 skipping to change at page 24, line 50
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 Unsolicited or the one to send the request to in case of Upstream Unsolicited or
Downstream on Demand mode. The LSR is however not able to find the Downstream on Demand mode. The LSR is however not able to find the
previous hop. The previous hop is not necessarily the next hop previous hop. The previous hop is not necessarily the next hop
towards the source, because the path from A to B is not necessarily towards the source, because the path from A to B is not necessarily
the same as the path from B to A. Such a situation can occur as a the same as the path from B to A. Such a situation can occur as a
result of asymmetric link measures or in the event that multiple result of asymmetric link measures or in the event that multiple
equal cost paths exist [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 Unsolicited) or the upstream LSR (Upstream on on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on
Demand, Upstream Unsolicited, implicit). The advantages of Demand, Upstream Unsolicited, implicit). The advantages of
downstream label allocation 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 piggy-backing (especially the downstream
distribution mode). distribution mode).
The advantages of upstream label allocation are: The advantages of upstream label allocation are:
a) Easier label allocation in multi-access networks (see section 9). a) Easier label allocation in multi-access networks (see section 9).
b) The same label can be kept when the downstream LSR (which would b) The same label can be kept when the downstream LSR (which would
have been the label allocator in downstream mode in a multi-access have been the label allocator in downstream mode in a multi-access
network) leaves the group (see section 9). network) leaves the group (see section 9).
c) The upstream and implicit distribution mode allow a faster LSP c) The upstream and implicit distribution mode allow a faster LSP
setup when the LSP is traffic triggered. setup when the LSP is traffic triggered.
Whether to use upstream or downstream label distribution is outside Whether to use upstream or downstream label distribution is outside
the scope of this framework. The relative complexity between the the scope of this framework. The relative complexity between the
necessary protocol extensions and the resolution mechanism needed, necessary protocol extensions and the resolution mechanism needed, as
as well as the relative operational complexity, will influence which well as the relative operational complexity, will influence which way
way to go. to go.
10.5. Explicit vs. Implicit Label Distribution 10.5. Explicit vs. Implicit Label Distribution
Beside the explicit distribution modes (which use a signaling Beside the explicit distribution modes (which use a signaling
protocol), [ACHA] proposes an implicit label distribution method by protocol), [ACHA] proposes an implicit label distribution method by
using unknown labels. This method has all the advantages of the using unknown labels. This method has all the advantages of the
upstream label allocation method and is probably the fastest label upstream label allocation method and is probably the fastest label
advertisement method for traffic triggered LSPs. advertisement method for traffic triggered LSPs.
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
In general, the use of multicast in an mpls environment poses no In general, the use of multicast in an MPLS environment poses no
extra security issues beyond the ones that already exist in multicast extra security issues beyond the ones that already exist in multicast
and mpls protocols as such. and MPLS protocols as such.
The protocols described in this document are however not suited to The protocols described in this document are however not suited to
cross administrative boundaries. cross administrative boundaries.
When the multicast tree is determined by an existing multicast When the multicast tree is determined by an existing multicast
routing protocol (this is the assumption made in this document, routing protocol (this is the assumption made in this document,
except for the Explict Routing section), clearly no additional except for the Explicit Routing section), clearly no additional
security issues are introduced w.r.t. the shape of the tree (e.g. security issues are introduced with respect to the shape of the tree
unauthorized joining, tapping, blackholing, injecting traffic, ...). (e.g. unauthorized joining, tapping, blackholing, injecting traffic,
These security issues should have been addressed in the ...). These security issues should have been addressed in the
specifications of the multicast routing protocols. specifications of the multicast routing protocols.
In the MPLS context it is possible that control messages trigger L2 In the MPLS context it is possible that control messages trigger L2
resource allocations (e.g. LSPs). If security flaws would still be resource allocations (e.g. LSPs). If security flaws would still be
present in the existing protocols (which possibly are not too harmful present in the existing protocols (which possibly are not too harmful
in its original context) the abusive sending of such control messages in its original context) the abusive sending of such control messages
can yield more severe DoS attacks. can yield more severe DoS attacks.
In case of an "explicit routed" tree that is calculated centrally, In case of an "explicit routed" tree that is calculated centrally,
sufficient authentication must be done on the control messages that sufficient authentication must be done on the control messages that
set up the tree in the network nodes. set up the tree in the network nodes.
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.
Normative References
Since this is an informational framework document (describing possible
solutions, without selecting a particular one), there are no normative
references.
Informative References Informative References
[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM [ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast
Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE ATM Cell Transport (IPSOFACTO) : Switching Multicast flows",
Globecom '97. IEEE Globecom '97.
[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast [ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent
Version 2 Dense Mode Specification", Work In Progress. Multicast Version 2 Dense Mode Specification", Work In
Progress.
[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, [ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
"LDP specification", RFC3036, January 2001. R. Thomas, "LDP Specification", RFC 3036, January 2001.
[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva- [AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and
san, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
December 2001 RFC 3209, December 2001.
[BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi- [BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing
tecture", RFC2201, September 1997. Architecture", RFC 2201, September 1997.
[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame [CONT] Conta, D., Doolan, P. and A. Malis, "Use of Label Switching
Relay Networks", RFC3034, January 2001. on Frame Relay Networks", RFC 3034, January 2001.
[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden [CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M.
and J. Krawczyk, "A Framework for Integrated Services and RSVP and J. Krawczyk, "A Framework for Integrated Services and
over ATM", RFC2382, August 1998. RSVP over ATM", RFC 2382, August 1998.
[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. [DAVI] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen,
Swallow and P. Doolan, "MPLS using LDP and ATM VC switching", E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC
RFC3035, January 2001. switching", RFC 3035, January 2001.
[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. [DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler,
Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Specification", RFC 2117, June 1997. Protocol Specification", RFC 2362, June 1998.
[FARI] D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to [FARI] D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to
Distribute MPLS Labels for Multicast Routes", Work In Progress. Distribute MPLS Labels for Multicast Routes", Work In
Progress.
[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version [FENN] Fenner, W., "Internet Group Management Protocol, IGMP,
2", RFC 2236, November 1997. Version 2", RFC 2236, November 1997.
[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load [GARR] Garrett, M. and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", RFC2381, August 1998. Service and Guaranteed Service with ATM", RFC 2381, August
1998.
[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
In Progress. Work In Progress.
[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. [MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID [NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan,
Notification over ATM link for LDP", RFC3038, January 2001. "VCID Notification over ATM link for LDP", RFC 3038, January
2001.
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Maufer, "Simple Multicast", Work In Progress. Maufer, "Simple Multicast", Work In Progress.
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol",
In Progress. Work In Progress.
[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] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,
Li, A. Conta, "MPLS Label Stack Encoding", RFC3032, January G., Li, T. and A. Conta, "MPLS Label Stack Encoding",
2001. RFC 3032, January 2001.
Authors Addresses Authors Addresses
Dirk Ooms Dirk Ooms
Alcatel Corporate Research Center Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerp, Belgium. Fr. Wellesplein 1, 2018 Antwerp, Belgium.
Phone : 32 3 2404732 Phone : 32 3 2404732
Fax : 32 3 2409879 Fax : 32 3 2409879
E-mail: Dirk.Ooms@alcatel.be EMail: Dirk.Ooms@alcatel.be
Bernard Sales Bernard Sales
Alcatel Corporate Research Center Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerp, Belgium. Fr. Wellesplein 1, 2018 Antwerp, Belgium.
Phone : 32 3 2409574 Phone : 32 3 2409574
E-mail: Bernard.Sales@alcatel.be EMail: Bernard.Sales@alcatel.be
Wim Livens Wim Livens
Colt Telecom Colt Telecom
Zweefvliegtuigstraat 10, 1130 Brussels, Belgium Zweefvliegtuigstraat 10, 1130 Brussels, Belgium
Phone : 32 2 7901705 Phone : 32 2 7901705
Fax : 32 2 7901711 Fax : 32 2 7901711
E-mail: WLivens@colt-telecom.be EMail: WLivens@colt-telecom.be
Arup Acharya Arup Acharya
IBM TJ Watson Research Center IBM TJ Watson Research Center
30 Saw Mill River Road, Hawthorne 30 Saw Mill River Road, Hawthorne
NY 10532 NY 10532
Phone : 1 914 784 7481 Phone : 1 914 784 7481
E-mail: arup@us.ibm.com EMail: arup@us.ibm.com
Frederic Griffoul Frederic Griffoul
Ulticom, Inc. Ulticom, Inc.
Les Algorithmes, 2000 Route des Lucioles, BP29 Les Algorithmes, 2000 Route des Lucioles, BP29
06901 Sophia-Antipolis, FRANCE 06901 Sophia-Antipolis, FRANCE
E-mail: griffoul@ulticom.com EMail: griffoul@ulticom.com
Furquan Ansari Furquan Ansari
Bell Labs Bell Labs, Lucent Tech.
101 Crawfords Corner Rd., Holmdel, NJ 07733 101 Crawfords Corner Rd., Holmdel, NJ 07733
Phone : 1 732 949 5149 Phone : 1 732 949 5249
Fax : 1 732 332 6511 Fax : 1 732 949 4556
E-mail: furquan@dnrc.bell-labs.com EMail: furquan@dnrc.bell-labs.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 148 change blocks. 
413 lines changed or deleted 419 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/