One document matched: draft-ooms-mpls-pimsm-00.txt
Submitted to MPLS Working Group D. Ooms
INTERNET DRAFT W. Livens
<draft-ooms-mpls-pimsm-00.txt> B. Sales
Alcatel
November, 1998
Expires May, 1999
MPLS for PIM-SM
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Distribution of this memo is unlimited.
Abstract
This document describes the issues which rise when PIM-SM ([ESTR]) is
chosen as the protocol for IP multicast deployment in an MPLS
environment. The relevant characteristics of PIM-SM are further
explored and a trigger for the establishment of LSPs for multicast
trees is proposed.
Table of Contents
1. Introduction
2. Characteristics of PIM-SM
3. The selection of an LSP trigger method
4. The MFC as a trigger method
4.1. Co-existence of (S, G) and (*, G) states in a single node
4.2. Label switching and encapsulated traffic
4.3. L3 measurements
Ooms, et al. Expires May 1999 [Page 1]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
4.4. Mixed L2/L3 forwarding
5. Security Considerations
6. Acknowledgements
Table of Abbreviations
DR Designated Router
DRsend Designated Router of a sender
DRrecv Designated Router of a receiver
IGMP Internet Group Management Protocol
IP Internet Protocol
L2 layer 2 (e.g. ATM)
L3 layer 3 (e.g. IP)
LSP Label Switched Path
LSR Label Switching Router
MFC Multicast Forwarding Cache
MRT Multicast Routing Table
mp2mp multipoint-to-multipoint
PIM-SM Protocol Independent Multicast-Sparse Mode
RP Rendezvous Point
1. Introduction
Draft [OOMS] is a framework for IP Multicast in MPLS. Among other
things it describes the characteristics of several IP Multicast
protocols in an MPLS context. This document will focus on one of
these protocols, namely PIM-SM ([ESTR]). This document will advocate
one method to trigger the establishment of multicast LSPs, namely an
approach based on the Multicast Forwarding Cache (MFC).
2. Characteristics of PIM-SM
The characteristics of PIM-SM, which are important in the context of
MPLS are listed in [OOMS]. The trees constructed in PIM-SM are
unidirectional and they can be either shared-trees (= group specific
with the Rendezvous Point as the root of the tree) or source-trees (=
source specific with the source as the root of the tree; also called
shortest-path tree).
For the unidirectional shared-tree, multicast data is sent
encapsulated towards the Rendezvous point (RP). The decapsulation of
the data requires L3 processing at the RP. This means a multicast
Ooms, et al. Expires May 1999 [Page 2]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
LSP for the shared-tree can not cross the RP, it can only start at
the RP. At the same time this characteristic avoids the potential
merging problem of mapping mp2mp streams onto LSPs in the RP.
3. The selection of an LSP trigger method
In label switching one wants to map the L3 tree onto a L2 tree, i.e.
mapping multicast data streams onto LSPs. The description of the
branching of the L3 tree can be found in the Multicast Routing Table
(MRT). The MRT is maintained by the multicast routing protocol. A
subset of this MRT - with only entries corresponding to data carrying
trees - can be found in the Multicast Forwarding Cache (MFC).
In [OOMS] the trigger methods for multicast are discussed: request
driven, topology driven and traffic driven. The methods based on the
MRT and MFC are respectively categorized as topology driven and
traffic driven. The interception of PIM messages to trigger LSPs
belongs to the category of the request driven methods. As mentioned
in [OOMS] this trigger method implies that the 'routing calculations'
(which calculate the L3 tree based on e.g. the PIM Join/Prune/Assert
messages) have to be redone in the 'MPLS module'.
To illustrate what can happen if this 'routing calculation' is
neglected consider the example in Figure 1. Assume a topology with
one sender S and two receivers R1 and R2. RP is the Rendezvous
Point. Ni is an LSR. The numbers are the interface numbers, Reg is
the Register interface.
PJ=Pim Join
IJ=Igmp Join
S
|
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <-
RP------N1----N2----N3----N4----R1
^|2 1 2 1 3 1 2
PJ|| IJ
1| <-
N5----R2
2
Figure 1
All IGMP and PIM Join messages are shown in the picture. The
multicast routing states created in the MRT are:
Ooms, et al. Expires May 1999 [Page 3]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3
(S,G):1->2
in N2: (*,G):1->2
(S,G):1->none
in N3: (*,G):1->3
(S,G):2->Reg,3
in N4: (*,G):1->2
in N5: (*,G):1->2
If the LSP would be derived straightforward from the PIM Join
messages, an LSP from RP to N4 (or R1) will be established. The
result of this will be that R1 receives the data from S twice: once
via the LSP (RP-N1-N2-N3-N4-R1) and once hop-by-hop (S-N3-N4-R1). So
the naive straightforward interception of PIM Join messages is
insufficient to trigger multicast LSPs.
If the LSPs are triggered by a topology (MRT) or traffic (MFC) driven
method this 'routing calculation' is already performed by the
multicast routing daemon, so the problem described above will not be
encountered.
Since the MFC is a subset of the MRT it will consume less labels. An
additional implementation advantage is that often the MFC is a common
component for several multicast routing protocols.
For the reasons listed above the use of the MFC trigger is advocated.
This trigger method still requires an intelligent interpreter of the
MFC (see section 4).
4. The MFC as a trigger method
4.1. Co-existence of (S, G) and (*, G) states in a single node
PIM-SM supports both shared-trees and source-trees. The
corresponding (*, G) and (S, G) state types for the same group G can
appear as entries in the MFC of a single node (e.g. N1 in Figure 1).
The co-existence of these state types typically occur when:
- A source-tree can overlap with the shared-tree (the latter can
still be in use by other sources of the same group). In the node
where the overlap starts both (S, G) and (*, G) state is present.
- Multicast traffic from a sender will create (S, G) state in the DR
of the sender (DRsend; N3 in Figure 1 is the DRsend of S). Each node
Ooms, et al. Expires May 1999 [Page 4]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
on a shared-tree has (*, G) state. Thus an on-tree DRsend has both
(*, G) and (S, G) state. Remark that the first upstream router
(starting from DRsend) which has a branch also has both state types
(N1 in Figure 1).
- ...
An (S, G) and (*, G) state can co-exist in a certain node when the
multicast data sent by S has to be forwarded in a different way than
the other data of the same group. It is not trivial to handle this
co-existence on L2. A general rule for handling this state co-
existence is to terminate the LSPs and forward all traffic of this
group on L3.
However L2 optimizations are possible. Depending on whether the (*,
G) and (S, G) state have a same (4.1.1.) or different (4.1.2.)
incoming interface two types of state co-existence can be
distinguished.
4.1.1. Same incoming interface
The (*, G) and (S, G) state have the same incoming interface (e.g. N1
in Figure 1). If the multicast data of this group arrives on a
single (*, G) LSP a termination at L3 is required to perform the
appropriate forwarding based on the source address, namely the (S, G)
traffic must be extracted from the (*, G) stream.
In case a (S, G) entry without outgoing interface is added to the MRT
(e.g. N2 in Figure 1) this entry will only exist temporarily in the
MFC (on a pruned interface traffic can only arrive as a transient
effect). In this particular case of co-existence of (*, G) and (S,
G) state one could maintain the existing (*, G) LSP, the disadvantage
being duplicate traffic for a very short time.
4.1.2. Different incoming interface
The (*, G) and (S, G) state have different incoming interfaces, but
some common outgoing interfaces (e.g. N3 in Figure 1). It is
possible that the traffic of S arrives on both the (*, G) and (S, G)
interfaces. In normal L3 forwarding the (S, G) entry prohibits the
forwarding of the traffic from S arriving on the (*, G) incoming
interface.
During a switch-over from a shared-tree to a source-tree, the traffic
of S can only temporarily (until Prune messages are processed) arrive
Ooms, et al. Expires May 1999 [Page 5]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
on the incoming interfaces of both the (*, G) and (S, G) entries. If
one does not mind the temporary forwarding of duplicate packets one
could opt for L2 forwarding. In the latter case the (*, G) and (S,
G) streams have to be merged into the (*, G) LSP on the outgoing
interfaces which are common.
4.2. Label switching and encapsulated traffic
The encapsulation and decapsulation of multicast data is a L3
process. For this reason the mp2mp path corresponding to a
unidirectional shared tree can never be mapped onto an end-to-end
LSP: the traffic on this mp2mp path can not be forwarded on L2 on the
Register interface of the DRsend (encapsulation), nor can it cross
the RP (decapsulation) at L2. If the LSR does support mixed L2/L3
forwarding ([OOMS]), the (S, G) traffic in DRsend can still be
forwarded on L2 on the outgoing interfaces which are not the Register
interface.
PIM-SM encapsulates the multicast data in a PIM Register message from
the DRsend towards the RP. This traffic could also benefit from MPLS
by label switching PIM Register messages.
4.3. L3 measurements
The MFC is performing L3 measurements to determine when to time out
its cache. Additionally PIM-SM uses these measurements to determine
when to switchover between shared-trees and source-trees. When label
switching is applied, these L3 measurements are disturbed because
traffic uses an LSP. To overcome this problem the L3 counters have
to be updated by measurements on the LSP.
4.4. Mixed L2/L3 forwarding
If the nodes do not support mixed L2/L3 forwarding the use of the MFC
trigger requires that labels are requested by the upstream node (e.g.
Downstream On Demand LDP mode) [OOMS].
5. Security Considerations
Security considerations are not discussed in this version of the
document.
Ooms, et al. Expires May 1999 [Page 6]
Internet Draft draft-ooms-mpls-pimsm-00.txt November 1998
6. Acknowledgements
The authors would like to thank Pavlin Radoslavov (University of
Southern California) and Maria Ramalho for reviewing the draft.
References
[ESTR] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P, Sharma, L. Wei; Protocol
Independent Multicast (PIM), Sparse Mode Protocol: Specifica-
tion, RFC 2362, June 1998.
[OOMS] D. Ooms, W. Livens, B. Sales, M. Ramahlo, Framework for IP Mul-
ticast in MPLS, draft-ooms-mpls-multicast-00.txt
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
Ooms, et al. Expires May 1999 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-22 15:17:21 |