📄 rfc3353.txt
字号:
+------------------+------+------+------+------+------+------+------+
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.
4. 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).
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2
Ooms, et al. Informational [Page 12]
RFC 3353 IP Multicast in an MPLS Environment August 2002
+--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
Nodes that support this 'mixed L2/L3 forwarding' feature allow
splitting of a multicast tree into branches in 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 the following
advantages:
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
Ooms, et al. Informational [Page 13]
RFC 3353 IP Multicast in an MPLS Environment August 2002
b) Enables the use of the traffic driven trigger with the Downstream
Unsolicited or Upstream on Demand label distribution mode, as
explained in section 5.3.1.
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.
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 9 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 9. Request driven trigger
(interception of resp. incoming and outgoing control messages)
Ooms, et al. Informational [Page 14]
RFC 3353 IP Multicast in an MPLS Environment August 2002
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 Unsolicited mode) or an LDP bind request
(Downstream on Demand mode) to LSRd.
Currently, for multicast, 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:
Ooms, et al. Informational [Page 15]
RFC 3353 IP Multicast in an MPLS Environment August 2002
a) RSVP Resv messages can merge.
b) RSVP Resv messages are only sent up to the first branch which made
the required reservation.
5.2. Topology Driven
The Multicast Routing Table (MRT) is maintained by the IP multicast
routing protocol daemon. 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.
The disadvantage of this method is that labels are consumed even when
no traffic exists.
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.
If the mixed L2/L3 forwarding capability (see section 4) is not
supported, the traffic driven trigger requires a label distribution
mode in which the label is requested by the LSRu (Downstream on
Demand or Upstream Unsolicited mode). In Figure 10, 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.
Ooms, et al. Informational [Page 16]
RFC 3353 IP Multicast in an MPLS Environment August 2002
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
Figure 10. The LSRu has to request the label.
5.3.2. An Implementation Example
To illustrate that by choosing an appropriate trigger one can
conclude that MPLS multicast is independent of the deployed multicast
routing protocol, the following implementation example is given.
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.
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
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
MFC need to be updated by L2 measurements.
Ooms, et al. Informational [Page 17]
RFC 3353 IP Multicast in an MPLS Environment August 2002
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -