Submitted to MPLS Working Group D. Ooms
INTERNET DRAFT W. Livens
<draft-ooms-mpls-multicast-01.txt> B. Sales
M. Ramalho
Alcatel
February, 1999
Expires August, 1999
Framework for IP Multicast in MPLS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document offers a framework for IP multicast deployment in an
MPLS environment. Issues arising when MPLS techniques are applied to
IP multicast are overviewed. The pros and cons of existing IP
multicast routing protocols in the context of MPLS are described and
the relation to the different trigger methods and LDP modes are
discussed. The consequences of various layer 2 (L2) technologies are
listed. Both point-to-point and multi-access networks are
considered.
Table of Contents
Ooms, et al. Expires August 1999 [Page 1]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
1. Introduction
2. MPLS and IP multicast: a winner combination
3. Layer 2 characteristics
4. Taxonomy of IP multicast routing protocols in the context of MPLS
4.1. Flood & Prune
4.2. Source/Shared trees
4.3. Uni/Bi-directional Shared Trees
4.4. Loop-free-ness
4.5. RPF Check
4.6. Mapping of characteristics on existing protocols
5. Taxonomy of IP multicast LSP triggers
5.1. Request driven
5.1.1. General
5.1.2. Multicast routing messages
5.1.3. Resource reservation messages
5.2. Topology driven
5.3. Traffic driven
5.3.1. General
5.3.2. An implementation example
5.4. Combinations of triggers and LDP modes
6. Mixed L2/L3 forwarding in a single node
7. Piggy-backing
8. Explicit routing
9. QoS/CoS
9.1 DiffServ
9.2 IntServ and RSVP
10. More issues
10.1. TTL field
10.2. Local control vs. egress control
10.3. Conservative vs. optimistic
10.4. Conservative vs. liberal
10.5. Scalability
11. Multi-access networks
12. Security Considerations
13. Acknowledgements
Table of Abbreviations
ATM Asynchronous Transfer Node
CBT Core Based Tree
CoS Class of Service
DLCI Data Link Connection Identifier
DVMRP Distant Vector Multicast Routing Protocol
FR Frame Relay
IGMP Internet Group Management Protocol
Ooms, et al. Expires August 1999 [Page 2]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
IP Internet Protocol
L2 layer 2 (e.g. ATM, Frame Relay)
L3 layer 3 (e.g. IP)
LSP Label Switched Path
LSR Label Switching Router
LSRd Downstream LSR
LSRu Upstream LSR
MIP Multicast Internet Protocol
MOSPF Multicast OSPF
mp2mp multipoint-to-multipoint
p2mp point-to-multipoint
PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
QoS Quality of Service
RPF Reverse Path Forwarding
RSVP Resource reSerVation Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
VC Virtual Circuit
VCI Virtual Circuit Identifier
VP Virtual Path
VPI Virtual Path Identifier
1. Introduction
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
performance and to create a vehicle for enhanced network services
(QoS/CoS, traffic engineering, ...).
Current unicast routing protocols generate a same (optimal) shortest
path in steady state for a certain (source, destination)-pair. Remark
that unicast protocols can behave slightly different with regard to
equal cost paths.
For multicast, the optimal solution would impose a Steiner tree
computation. Unfortunately, no multicast routing protocol today is
able to maintain such an optimal tree. Different multicast protocols
will therefore, in general, generate different trees.
The discussion is focused on intra-domain multicast routing
protocols. Aspects of inter-domain routing are beyond the scope of
this document.
2. MPLS and IP multicast: a winner combination
Besides the better utilization of expensive L3 resources, multicast
Ooms, et al. Expires August 1999 [Page 3]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
LSPs have even more benefits than unicast LSPs. First, multicast
traffic flows are often those long-duration high-bandwidth flows that
are prime candidate to be label switched (e.g. video streams). Next,
the detection of these flows can be straightforward, as multicast
flows are often setup using explicit routing messages (e.g. the
receiver triggered Join messages in PIM-SM), which can be easily
intercepted. Finally, IP multicast uses UDP, which does not have the
congestion-avoiding behavior of TCP. A large scale deployment of
multicast may therefore push aside regular TCP traffic, deteriorating
the latter's performance. Label switching this multicast UDP traffic
will therefore result in a better performance for non-label-switched
TCP-based applications.
3. Layer 2 characteristics
Although MPLS is multiprotocol both at L3 and at L2, in practice IP
is the only considered L3 protocol. For L2 attention is mainly
focused on ATM [DAVI]. ATM offers big pipes, high switching
capacities and QoS awareness, but in the context of MPLS it poses
several limitations which are described in [DAVI]. Similar
considerations are made for Frame Relay on L2 in [CONT].
If label switching is mapped on L2 switching capabilities (such as
ATM or FR) this can pose following limitations to MPLS:
- Limited Label Space: either the standardized or the implemented
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
established.
- Merging: some L2 technologies or implementations of these
technologies do not support multipoint-to-point and/or multipoint-
to-multipoint 'connections', obstructing the merging of LSPs.
- TTL: L2 technologies do not support a 'TTL-decrement' function.
All three limitations can impact the implementation of multicast in
MPLS as will be described in this document.
When native MPLS (with generic MPLS header) is deployed the above
limitations vanish. Moreover 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 MPLS unicast and multicast are
defined [ROSE].
4. Taxonomy of IP multicast routing protocols in the context of MPLS
Ooms, et al. Expires August 1999 [Page 4]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
At the moment, an abundance of IP multicast routing protocols is
being proposed and developed. All these protocols have different
characteristics (scalability, computational complexity, latency,
control message overhead, tree type, etc...). It is not the purpose
of this document to give a complete taxonomy of IP multicast routing
protocols, only their characteristics relevant to the MPLS technology
will be addressed.
Following characteristics are considered:
- Flood & Prune
- Source/Shared trees
- Uni/Bi-directional shared trees
- Loop-free-ness
- RPF check
The discussion of these characteristics will not lead to the
selection of one superior multicast routing protocol. It is even
very probable that different IP multicast routing protocols will be
deployed in the Internet.
4.1. Flood & Prune
To establish the multicast tree some IP multicast routing protocols
(e.g. DVMRP) flood the network with multicast data. 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 periodically,
thus generating a very volatile tree structure. Direct mapping of
this dynamic layer 3 (L3) point-to-multipoint (p2mp) tree to a layer
2 (L2) p2mp LSP is problematic because of the limited label space,
the signaling overhead and the setup time of the LSPs.
4.2. Source/Shared trees
IP multicast routing protocols create either source trees (S, G),
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). Some
protocols support a mixture of both tree types (e.g. PIM-SM).
Ooms, et al. Expires August 1999 [Page 5]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
R1 R1 R1
S1 / / /
\ / / /
\ / / /
C---R2 S1---R2 S2---R2
/ \ \ \
/ \ \ \
S2 \ \ \
R3 R3 R3
Figure 1. Shared tree and Source trees
The advantage of using shared trees, when label switching is applied,
is that shared trees consume less labels than source trees (1 label
per group versus 1 label per source and per group).
However, mapping a shared tree end-to-end on L2 implies setting up
multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing
mp2mp LSPs boils down to the merging problem.
4.3. Uni/Bi-directional Shared Trees
Bidirectional shared trees (e.g. CBT) have the disadvantage of
creating a lot of merging points (M) in the nodes (N) of the shared
tree. Figure 2 shows these merging points resulting from 2 senders S1
and S2 on a bidirectional tree.
S1 S2
|| ||
v| <- <- <- <- |v
<- <- | -> -> -> -> | ->
----N----M----M----M----M----M----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 2. Multicast traffic flows from 2 senders on a bidirectional tree
In Figure 3 the same situation for unidirectional shared trees is
depicted. In this case the data of the senders is tunneled towards
the root node R, yielding only a single merging point, namely the
root of the shared tree itself.
Ooms, et al. Expires August 1999 [Page 6]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 3. Multicast traffic flows from 2 senders on a unidirectional tree
In unidirectional shared trees the multicast traffic is sent
encapsulated from the Designated Router (DR) of the source to the
root node R. Hence, multicast traffic arriving at the root needs to
be decapsulated first (L3 operation) before transmission over the (*,
G) tree. Therefore, forwarding multicast packets in the root node
can only be done at L3, so there is no issue of merging data from
different sources at L2 in the root node. LSPs can only start from
the root node, so the traffic can never be label switched end-to-end.
4.4. Loop-free-ness
Multicast routing protocols which depend on a unicast routing
protocol can suffer from the same transient loops as the unicast
protocols do, however the effect of loops will be much worse in the
case of multicast (multicast avalanche).
Note that there exist multicast routing protocols which are
guaranteed loop free [PARS]. Currently loop detection is a
configurable option in LDP and a decision on the mechanism for loop
prevention is postponed. If loops appear to be a major issue and
MPLS does not handle them properly these guaranteed loop free
protocols have an advantage.
4.5. RPF Check
Some protocols perform a Reverse Path Forwarding (RPF) check on the
received multicast packets. This mechanism checks whether the packet
is received on the interface which is on the shortest path to the
source (or root). This mechanism can introduce problems when
explicit routing is used (see section 8). Indeed, explicit routing
can construct a tree yielding another incoming interface than the
RPF-compatible one.
Ooms, et al. Expires August 1999 [Page 7]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
4.6. Mapping of characteristics on existing protocols
The above characteristics are summarized in Table 1 for a non-
exhaustive list of existing IP multicast routing protocols: DVMRP
[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], MIP
[PARS], SM [PERL].
+------------------+------+------+------+------+------+-----+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|MIP |SM |
+------------------+------+------+------+------+------+-----+------+
|Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+-----+------+
|Tree Type |source|source|shared|source|both |both |shared|
+------------------+------+------+------+------+------+-----+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |both |bi |
+------------------+------+------+------+------+------+-----+------+
|Loop Free |no |no |no |no |no |yes |no |
+------------------+------+------+------+------+------+-----+------+
|RPF check |yes |yes |no |yes |yes |no |no |
+------------------+------+------+------+------+------+-----+------+
Table 1. Taxonomy of IP Multicast Routing Protocols
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.
Furthermore since DVMRP uses source trees it experiences no merging
problem when label switching is applied. The table can be
interpreted in the same way for the other protocols.
5. Taxonomy of IP multicast LSP triggers
The creation of an LSP for multicast streams can be triggered by
different events, which can be mapped on the well known categories of
'request driven', 'topology driven' and 'traffic driven'.
a) Request driven: intercept the sending or receiving of control
messages (e.g. multicast routing messages, resource reservation
messages).
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
there is no traffic.
c) Traffic driven: the L3 tree is mapped onto a L2 tree when data
arrives on the tree.
Ooms, et al. Expires August 1999 [Page 8]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
The granularity of the multicast streams is (*, G) for a shared tree
and (S, G) for a source tree, S being the source address and G the
multicast group address. Aggregation of multiple trees on one LSP is
a subject for further study.
Whether the trigger by multicast routing messages is categorized as
request or topology driven is debatable. The constructed L2 tree
will be identical to the one constructed by topology driven methods,
but the definition of request driven [CALL] includes all label
assignments in response to control traffic. In [KATS] the multicast
routing messages trigger is categorized as request driven, so we will
continue using this convention.
5.1. Request driven
5.1.1. General
The establishment of LSPs can be triggered by the interception of
outgoing (requiring that the label is requested by the downstream
LSR) or incoming (requiring that the label is requested by the
upstream LSR) control messages. Figure 4 illustrates these two
cases.
LSRu LSRd LSRu LSRd
-------+ +--- ---+ +-------
| control | | control |
<---*<-----message------- <-------message-------*----
| | | | | |
trigger| | | | | |trigger
| | bind | | bind | |
+--------or---------> <---------or----------+
| bind-request | | bind-request |
| | | |
| | | |
|----data----->| |-----data---->|
incoming outgoing
Figure 4. Request driven trigger
(interception of resp. incoming and outgoing control messages)
The downstream LSR (LSRd) sends a control message to the upstream LSR
(LSRu). In the case that incoming control messages are intercepted
and the MPLS module in LSRu decides to establish an LSP it will send
an LDP bind (upstream mode) or an LDP bind request (downstream on
demand mode) to LSRd.
Ooms, et al. Expires August 1999 [Page 9]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
Currently, we can identify two important types of control messages:
the multicast routing messages and the resource reservation messages.
5.1.2. Multicast routing messages
In principle, this mechanism can only be used by IP multicast routing
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
support this type of trigger [FARI], however, at the cost of
modifying the IP multicast routing protocol itself !
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
periodically). The latter generates more control traffic for tree
maintenance and thus requires more processing in the MPLS module.
Triggers based on the multicast routing protocol messages have the
disadvantage that the routing calculations performed by the multicast
routing daemon to determine the Multicast Routing Table are repeated
by the MPLS module. The former determines the tree that will be used
at L3, the latter calculates an identical tree to be used by L2.
Since the same task is performed twice, it is better to create the
multicast LSP on the basis of information extracted from the
Multicast Routing Table itself (see section 5.2 and 5.3). The
routing calculations become more complex for protocols which support
a switch-over from a (*, G) tree to a (S, G) tree because more
messages have to be interpreted.
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
multicast routing messages but the IGMP Join/Prune messages ([FENN])
as well.
5.1.3. Resource reservation messages
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
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
does for unicast because:
a) RSVP Resv messages can merge.
b) RSVP Resv messages are only sent up to the first branch which made
the required reservation.
Ooms, et al. Expires August 1999 [Page 10]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
More on RSVP in the sections on Piggy-backing (section 7) and QoS
(section 9).
5.2. Topology driven
The Multicast Routing Table (MRT) is maintained by the IP multicast
routing protocol daemon (e.g. PIM/pimd, DVMRP/mrouted). The MPLS
module maps this L3 tree topology information to L2 p2mp LSPs.
The MPLS module can poll the MRT to extract the tree topologies.
Alternatively, the multicast daemon can be modified to notify the
MPLS module directly of any change to the MRT.
5.3. Traffic driven
5.3.1. General
A traffic driven trigger method will only construct LSPs for trees
which carry traffic. It consumes less labels than the topology
driven method, as labels are only allocated when there is traffic on
the multicast tree.
Ooms, et al. Expires August 1999 [Page 11]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
If the mixed L2/L3 forwarding capability (see section 6) is not
supported, the traffic driven trigger requires an LDP mode in which
the label is requested by the LSRu (downstream on demand or upstream
mode). In Figure 5, suppose an LSP 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 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 requires a mixed L2/L3
forwarding capability in LSRu to add the L3 branch.
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
Figure 5. The LSRu has to request the label.
5.3.2. An implementation example
Current implementations on Unix platforms of IP multicast routing
protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The
MFC is a cached copy of the Multicast Routing Table. The MFC
requests an entry for a certain multicast group when it experiences a
'cache miss' for an incoming multicast packet. The missing routing
information is provided by the multicast daemon. If at a later point
in time something changes to the route (outgoing interfaces added or
removed), the multicast daemon will update the MFC.
The MFC is implemented as a common component (part of the kernel),
which makes this trigger very attractive because it can be
transparently used for any IP multicast routing protocol.
Ooms, et al. Expires August 1999 [Page 12]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
Entries in the MFC are removed when for a certain time no traffic is
received anymore for this entry. When label switching is applied to
a certain MFC-entry, the L3 will not see any packets arriving
anymore. To obtain a normal MFC behavior the L3 counters of the MFC
need to be updated by L2 measurements.
5.4. Combinations of triggers and LDP modes
Table 2 shows the valid combinations of LDP modes and trigger types
which were discussed in the previous sections. The (X) means that
the combination is valid when the mixed L2/L3 forwarding feature is
supported in the LSR (section 6).
+----------------+-------------------------------------------+
| | label requested by |
| | LSRu | LSRd |
| +---------------------+---------------------+
| | upstream |downstream|downstream| upstream |
| | |on demand | | on demand|
+----------------+----------+----------+----------+----------+
|Request Driven | | | | |
|(incoming msg) | X | X | | |
+----------------+----------+----------+----------+----------+
|Request Driven | | | | |
|(outgoing msg) | | | X | X |
+----------------+----------+----------+----------+----------+
|Topology Driven | X | X | X | X |
+----------------+----------+----------+----------+----------+
|Traffic Driven | X | X | (X) | (X) |
+----------------+----------+----------+----------+----------+
Table 2. Valid combinations of triggers and LDP modes
6. Mixed L2/L3 forwarding in a single node
Since unicast traffic has one incoming and one outgoing interface the
traffic is either forwarded at L2 OR at L3 (Figure 6). Because
multicast traffic can be forwarded to more than one outgoing
interface one can consider the case that traffic to some branches is
forwarded on L2 and to other branches on L3 (Figure 7).
Ooms, et al. Expires August 1999 [Page 13]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
Nodes which support this 'mixed L2/L3 forwarding' feature allow that
a multicast tree splits in branches of which some are forwarded at L3
while others are switched at L2.
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
accomplished by e.g. providing an extra bit in the Multicast Routing
Table.
Although the mixed L2/L3 forwarding requires processing of the
traffic at L3, the load on the L3 forwarding engine is generally less
than in a pure L3 node.
Supporting this 'mixed L2/L3 forwarding' feature has following
advantages:
Ooms, et al. Expires August 1999 [Page 14]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
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.
The mixed L2/L3 forwarding allows that the branch towards C is not
disturbed by a return to L3 in LSR A.
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
Figure 8. Mixed L2/L3 forwarding in node A
b) Allows a return to L3 for branches which requested lower QoS
(section 9).
c) Enables the use of the traffic driven trigger with the LDP
downstream or upstream on demand mode, as explained in section 5.4.
7. Piggy-backing
In Figure 4 (outgoing case) one can observe that instead of sending 2
separate messages the label advertisement can be piggy-backed on the
existing control messages. However, some disadvantages can be
identified:
a) A network node can be MPLS enabled and/or PIM-SM enabled. Mixing
both features in one protocol is conceptually not elegant.
b) Since label advertisement is only one of the three functions of
LDP (the two others are discovery and adjacency), LDP is still
required for e.g. label range negotiation.
c) Suppose piggy-backing is applied on the multicast routing
protocol. In order to support unicast label switching, either piggy-
backing has also to be implemented on the unicast routing protocol or
LDP must be used. In the latter case, one may question the benefit of
piggy-backing on the multicast routing protocol. As a result,
Ooms, et al. Expires August 1999 [Page 15]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
piggy-backing introduces extra implementation effort.
d) Piggy-backing assumes the LDP downstream mode, this excludes a
number of trigger methods (see Table 2).
e) Piggy-backing changes the LDP paradigm: LDP normally runs on top
of TCP, assuring a reliable communication between peer nodes.
Piggy-backed label advertisement often replaces the reliable
communication with periodic soft-state label advertisements. Because
of this periodic label advertisement the control traffic will
increase.
f) If a VCID notification mechanism [NAGA] is required, the (in-band)
notification can be done by sending the LDP bind through the newly
established VC. This way only one message is required. This method
cannot be combined with piggy-backing because the routing message is
sent before the VC can be established. An extra handshake message is
thus required, diminishing the benefit of piggy-backing.
For multicast two piggy-back candidates exist:
a) Multicast routing messages: protocols as PIM-SM and CBT have
explicit Join messages which could carry the label mappings. This
approach is described in [FARI]. When different multicast routing
protocols are deployed, an extension to each of these protocols has
to be defined.
b) RSVP Resv messages: a label mapping extension object for RSVP,
also applicable to multicast, is proposed in [DAVI].
Piggy-backing is not incompatible with multicast, but one has to
consider the disadvantages carefully.
8. Explicit routing
Explicit routing for unicast refers to overriding the unicast routing
table by using LSPs. A first way to interprete "multicast explicit
routing" is overriding the multicast routing table by another LSP
tree (e.g. a centrally calculated Steiner tree).
A second way of interpreting "multicast explicit routing" is that
multicast routing protocols use the explicit unicast routes to
construct trees. However this approach creates some problems:
1) The unicast explicit paths need to be bidirectional so that the
multicast data (from source to receiver) and the multicast routing
messages (from receiver to source) follow the same path.
Ooms, et al. Expires August 1999 [Page 16]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
2) The RPF check also has to take into account the explicit path.
9. QoS/CoS
9.1. DiffServ
The Differentiated Services approach can be applied to multicast as
well. It introduces finer stream granularities (Class of Service
(CoS) as an extra differentiator). A sender can construct one or
more trees with different CoS bits.
These (S, G, CoS) or (*, G, CoS) trees can be mapped very easily onto
LSPs when the traffic driven trigger is used. In this case one can
create LSPs with different attributes for the various classes. Note
however that these LSPs still use the same route as long as the tree
construction mechanism does not support a class identifier, this
means that the multicast routing protocol has to interprete the CoS
bits in the join messages and create (S, G, CoS) state in the
routers.
9.2. IntServ and RSVP
RSVP can be used to setup multicast trees with QoS. An important
multicast issue is the problem of how to map the 'heterogeneous
receivers' paradigm onto L2 (remark that it is not solved in IP
either). This subject is tackled in [CRAW]. Pragmatic approaches
are the 'Limited Heterogeneity Model' which allows a best effort
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
a single QoS.
The first approach will construct full trees for each service class.
The sender has to send its traffic twice across the network (1 best-
effort and 1 QoS tree). Both trees can be label switched.
The second approach constructs one tree and the best-effort users are
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
default VC) the QoS multicast traffic has to be merged onto these
default VCs. This function can be provided by the 'mixed L2/L3
forwarding' feature described in section 6. If this is not available
VC 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
categories is studied in [GARR].
Ooms, et al. Expires August 1999 [Page 17]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
10. More issues
10.1. TTL
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
packets by setting an appropriate TTL value. Since the TTL value is
not decremented in an LSP, the scope restriction function is
affected.
Suppose one could calculate in advance the number of hops an LSP
traverses. In a unicast LSP the TTL value could then be decremented
at the ingress node. This is impossible for multicast since all the
branches of the tree can have different lengths.
10.2. Local control vs. egress control
In local control (also called independent mode [ANDE]) each LSR can
take the initiative to set up a LSP. In egress control (also called
ordered mode [ANDE]) the LSP is set up on the initiative of the
egress node. All the previously described trigger methods (section
5) combine with LDP local control. In case of the request driven
approach the label distribution in fact behaves as egress controlled:
the control messages flow from the egress node upstream, imposing the
same sequence to the label advertisement. In case of piggy-backing
the label advertisements themselves are flowing from the egress node
upstream.
10.3. Conservative vs. optimistic
The conservative mode ([DAVI]) only accepts an upstream label for a
certain stream if it already has a downstream label for this stream.
The optimistic mode always accepts the label.
The conservative mode cannot be used in combination with a traffic
driven trigger in case the node does not support mixed L2/L3
forwarding. According to Table 2, this case implies that labels are
requested by the upstream LSR. Suppose in Figure 10 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 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 the A-B link. This is not possible at L2
nor at L3 (since A does not support mixed L2/L3).
Ooms, et al. Expires August 1999 [Page 18]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
N---N---R1
/
/
S -----A
\
\
B---C---R2
Figure 10.
10.4. Conservative vs. liberal
In the conservative mode ([ANDE]) only the labels that are required
for forwarding data are allocated and maintained. In the liberal
mode labels are advertised and maintained to all neighbors. This mode
does not scale when the label space is limited.
In some cases (see below) it is not known by an LSR to which neighbor
it has to request a label. Therefore, it has to send the request to
all its neighbors. In such case supporting the liberal mode requires
no extra messages. However, it still requires extra state information
and label space.
Table 3 shows the cases where it is known by an LSR where to send its
label requests.
+---------+----------------------------------+
| | label requested by |
| | LSRu | LSRd |
+---------+----------------+-----------------|
|unicast | Yes | No |
+---------+----------------+-----------------|
|multicast| Yes | Yes |
+---------+----------------+-----------------+
Table 3. Does an LSR know where to send its label requests ?
For a unicast flow, an LSR can determine the next hop LSR, which is
the one to send the request to in case of upstream or downstream-on-
demand mode. The LSR is however not able to find the previous hop.
The previous hop is not necessarily the next hop 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 result of asymmetric
link measures or in the event that multiple equal cost paths exist
[PAXS].
Ooms, et al. Expires August 1999 [Page 19]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
In the case of multicast, an LSR knows both the next hop(s) and the
previous hop. Because multicast trees are constructed using the
reverse shortest path method, the previous hop is always the next hop
towards the source or towards the root of the tree. As a result,
multicast maps very naturally on the conservative mode.
10.5. Scalability
Sparse mode multicast routing protocols (CBT, PIM-SM) are more
scalable than dense mode protocols. But even the sparse mode
protocols introduce state in each node of the tree. An enhancement
to this is proposed in [TIAN]. In this proposal tunnels are created
which span the non-branching nodes. An appropriate trigger could map
these tunnels to LSPs.
11. Multi-access networks
Multicast MPLS on shared media requires label space partitioning,
otherwise the danger exists that two downstream LSRs will use the
same label to subscribe to different multicast groups. A label space
partitioning mechanism is described in [FAR2].
Unlike the unicast case, a multicast stream can have more than one
downstream LSR which all have to use the same label. Two solutions
can be thought of:
1) [FARI] proposes to multicast the label advertisements to all LSRs
on the shared link. Since multicast is not reliable this requires
periodic label advertisements, yielding label advertisement
duplicates in time.
2) Another approach is that an LSR unicasts its label advertisements
in a reliable way (TCP) to all other LSRs on the shared link. In
this approach the hard-state character of 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
the number of LSRs on a shared link is limited the first approach
will generate more signaling.
12. Security Considerations
Security considerations are not discussed in this version of the
document.
Ooms, et al. Expires August 1999 [Page 20]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
13. Acknowledgements
The authors would like to thank Piet Van Mieghem, Philip Dumortier,
Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard Gastaud for the
fruitful discussions and/or their thorough revision of this document.
References
[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas,
"Label Distribution Protocol", IETF Draft, draft-mpls-ldp-
00.txt, March 1998.
[BALL] A. Ballardie, "Core Based Trees (CBT, v2) Multicast Routing -
Protocol Specification", IETF Draft, draft-ietf-idmr-cbt-spec-
09.txt, 1997.
[CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A.
Viswanathan, "A Framework for Multiprotocol Label Switching",
IETF Draft, draft-ietf-mpls-framework-02.txt, November 1997.
[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
Relay Networks", IETF Draft, draft-ietf-mpls-fr-03.txt, November
1998.
[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden
and J. Krawczyk, "A Framework for Integrated Services and RSVP
over ATM", IETF Draft, draft-ietf-issll-atm-framework-04.txt,
May 1998.
[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
Swallow and P. Doolan, "Use of Label Switching With ATM", IETF
Draft, draft-davie-mpls-atm-00.txt, November 1997.
[DAV2] B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan
and S. Blake, "Use of Label Switching With RSVP", IETF Draft,
draft-ietf-mpls-rsvp-00.txt, March 1998
[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.
Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2117, June 1997.
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol
Independent Multicast (PIM), Dense Mode Protocol: Specifica-
tion", IETF Draft, 1994.
Ooms, et al. Expires August 1999 [Page 21]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
[FARI] D. Farinacci and Y. Rekhter, "Multicast Tag Binding and Distri-
bution using PIM", IETF Draft, draft-farinacci-multicast-tagsw-
00.txt, December 1996.
[FAR2] D. Farinacci and Y. Rekhter, "Partitioning Tag Space among Mul-
ticast Routers on a Common Subnet", IETF Draft, draft-
farinacci-multicast-tag-part-00.txt, December 1996.
[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version
2", RFC 2236, November 1997.
[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", IETF Draft, draft-
ietf-issll-atm-mapping-06.txt, March 1998.
[KATS] Y. Katsube, Y. Ohba and K. Nagami, "Two Modes of MPLS Explicit
Label Distribution Protocol", IETF Draft, draft-katsube-mpls-
two-ldp-00.txt, September 1997.
[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994.
[NAGA] K. Nagami, N. Demizu, H. Esaki and P. Doolan, "VCID Notification
over ATM link", IETF Draft, draft-ietf-mpls-vcid-atm-00.txt;
March 1998.
[PERL] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Maufer, "Simple Multicast", IETF Draft, draft-perlman-simple-
multicast-01.txt, November 1998.
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", IETF
Draft, draft-ietf-idmr-dvmrp-v3-05, October 1997.
[PARS] M. Parsa and J. Garcia-Luna-Aceves, "A protocol for scaleable
loop-free multicast routing", IEEE JSAC, vol.15, no.3, p.316-
331, April 1997
[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet",
IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
[ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T.
Li, A. Conta, "MPLS Label Stack Encoding", IETF draft, draft-
ietf-mpls-label-encaps-03.txt, September 1998.
[TIAN] J. Tian, G. Neufeld, "Forwarding State Reduction for Sparse Mode
Multicast Communication", IEEE INFOCOM '98, San Francisco, USA,
29 March- 2 April 1998,
http://www.comsoc.org/confs/infocom/98/index.html
Ooms, et al. Expires August 1999 [Page 22]
Internet Draft draft-ooms-mpls-multicast-01.txt February 1999
Authors Addresses
Dirk Ooms
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-4732
Fax : 32-3-240-9932
E-mail: Dirk.Ooms@alcatel.be
Wim Livens
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-7570
E-mail: Wim.Livens@alcatel.be
Bernard Sales
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-9574
E-mail: Bernard.Sales@alcatel.be
Maria Fernanda Ramalho
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-9725
E-mail: Maria.Ramalho@alcatel.be
Ooms, et al. Expires August 1999 [Page 23]