📄 rfc3353.txt
字号:
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).
Ooms, et al. Informational [Page 6]
RFC 3353 IP Multicast in an MPLS Environment August 2002
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 discussed earlier.
Note that in practice shared trees are often only used to discover
new sources of the group and a switchover to a source tree is made at
very low bitrates.
3.4. Co-existence of Source and Shared Trees
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
group G. Two cases of state co-existence are described below.
Assume topologies with senders Si and receivers Ri. RP is the
Rendezvous Point. Ni are LSRs. The numbers are the interface
numbers, "Reg" is the Register interface. All IGMP and PIM
Join/Prune messages are shown in the figures. It is also indicated
whether the RPT-bit is set for the (S, G) state.
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
Designated Router of receiver R1 (DRrecv), decides to initiate a
source tree for source S1. After the arrival of data via the
source tree in N2, N2 will send a prune to N5 for source S1.
State co-existence occurs in the node where the overlap of shared
and source tree starts (N2) and in the node where S1 does not need
forwarding on the shared tree anymore (N5).
PJ
IJ PJS PJS
-> 1 2 -> 1 2 -> 1 2
R1-----N1------N2------N3----S1
3| |3 IJ=Igmp Join
||PPS | PJ=Pim Join (*,G)
|vPJ | PJS=Pim Join (S1,G)
IJ PJ | PJ | PPS=Pim Prune (S1,G)
-> -> |3 -> |
R2-----N4------N5------RP----S2
1 2 1 2 1
Figure 2
Ooms, et al. Informational [Page 7]
RFC 3353 IP Multicast in an MPLS Environment August 2002
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 N1: (*,G):2->1
in N2: (*,G):3->1
(S1,G):2->1
in N3: (S1,G):2->Reg,1
in N4: (*,G):2->1
in N5: (*,G):2->1,3
(S1,G)RPT-bit:2->1
2) Figure 3 shows that even without a switchover, state co-existence
can occur. Multicast traffic from a sender will create (S, G)
state in the Designated Router of the sender (DRsend; N3 in Figure
3 is the DRsend of S). Each node on a shared-tree has (*, G)
state. Thus an on-tree DRsend has both (*, G) and (S, G) state.
If the DRsend is on-tree it will also send a prune for S towards
the RP, creating (S, G) state in all nodes until the first router
which has a branch (N1 and N2 in Figure 3).
S
PPS PPS |
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ
1| <-
N5----R2
2
Figure 3
The multicast routing states created in the MRT are:
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3
(S,G)RPT-bit:1->2
in N2: (*,G):1->2
(S,G)RPT-bit:1->none
in N3: (*,G):1->3
(S,G):2->Reg,3
in N4: (*,G):1->2
in N5: (*,G):1->2
Ooms, et al. Informational [Page 8]
RFC 3353 IP Multicast in an MPLS Environment August 2002
In the examples one can observe that two types of state co-
existence occur:
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 common outgoing interfaces. It is possible that the traffic
of S arrives on both the (*, G) and (S, G) interfaces. In normal
L3 forwarding the (S, G)SPT-bit entry prohibits the forwarding of
the traffic from S arriving on the (*, G) incoming interface. The
traffic of S can only temporarily arrive on the incoming
interfaces of both the (*, G) and (S, G) entries (until N5 in
Figure 2 and N1 in Figure 3 have processed the prune messages).
To avoid the temporary forwarding of duplicate packets L3
forwarding can be applied in this type of node. If one does not
mind the temporary duplicate packets L2 forwarding can be applied.
In this case the (*, G) and (S, G) streams have to be merged into
the (*, G) LSP on their common outgoing interfaces.
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) traffic must be extracted from the (*, G) stream. In MPLS this
state co-existence can be handled in several ways. Four
approaches to this problem will be described:
a) A first method to handle this state co-existence is to
terminate the LSPs and forward all traffic of this group at L3.
However a return to L3 can be avoided in case a (S, G) entry
without an outgoing interface is added to the MRT (N2 in Figure
3). This entry will only receive traffic temporarily. In this
particular case one could ignore the (S, G) state and maintain
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 of the shared tree. Multiple labels will be associated
with one (*, G) entry, corresponding to one label per active
source. Since the nodes only know which sources are active
when traffic from these sources arrives, the LSPs cannot be
pre-established and a fast LSP setup method is favorable.
c) A third way is that only source trees are labelswitched and
that traffic on the shared tree is always forwarded at L3.
This assumes that the shared tree is only used as a way for the
receivers to find out who the sources are. By configuring a
low bitrate switchover threshold, one can ensure that the
receivers switchover to source trees very quickly.
Ooms, et al. Informational [Page 9]
RFC 3353 IP Multicast in an MPLS Environment August 2002
d) In the fourth approach, an LSR which has (S, G) RPT-bit state
with a non-null oif, advertises a label for (S, G) to the
upstream LSR and this label advertisement is then propagated by
each upstream LSR towards the RP. In this way a dedicated LSP
is created for (S, G) traffic from the RP to the LSR with the
(S, G) RPT-bit state. In the latter LSR, the (S, G) LSP is
merged onto the (*, G) LSP for the appropriate outgoing
interfaces. This ensures that (S, G) packets traveling on the
shared tree do not make it past any LSR which has pruned S.
3.5. Uni/Bi-directional Shared Trees
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
tree. Figure 4 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 4.
Multicast traffic flows from 2 senders on a bidirectional tree
In Figure 5 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.
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 5.
Multicast traffic flows from 2 senders on a unidirectional tree
Ooms, et al. Informational [Page 10]
RFC 3353 IP Multicast in an MPLS Environment August 2002
3.6. Encapsulated Multicast Data
Sources of unidirectional shared trees and non-member sources of
bidirectional shared trees encapsulate the data towards the root
node. The data is then decapsulated in the root node. The
encapsulation and decapsulation of multicast data are L3 processes.
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 on the Register interface of the DRsend (encapsulation), nor can
it cross the root (decapsulation) at L2.
Remarks:
1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G)
traffic in DRsend can still be forwarded at L2 on all outgoing
interfaces other than the Register interface.
2) The encapsulated traffic can also benefit from MPLS by label
switching the tunnels.
3) If the root node decides to join the source (to avoid
encapsulation/decapsulation), an end-to-end (S, G) LSP can be
constructed.
3.7. Loop-free-ness
Multicast routing protocols which depend on a unicast routing
protocol 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. The reason being, each time a multicast packet
goes around a loop, copies of the packet may be emitted from the loop
if branches exist in the loop.
Currently loop detection is a configurable option in LDP and a
decision on the mechanism for loop prevention is postponed.
3.8. 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 [ADAM], PIM-SM [DEER],
SSM [HOLB], SM [PERL].
Ooms, et al. Informational [Page 11]
RFC 3353 IP Multicast in an MPLS Environment August 2002
+------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
+------------------+------+------+------+------+------+------+------+
|Aggregation |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
|Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+------+------+
|Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |no |no |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -