Internet Draft 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]