Subject: draft-ooms-mpls-pimsm-00.txt

From: Dirk Ooms <[email-masked]>
Date: Wed, 18 Nov 1998 19:41:26 +0100

I would like to submit the attached draft on PIM-SM and MPLS.
-- 
                                     ----------------
                                     \              /
--------------------------------------\            /-----------
Dirk Ooms (DN9)                       Alcatel Telecom 
Phone: +32 3 240 4732                Research Division
Fax:   +32 3 240 9932              Francis Wellesplein 1
mailto:[email-masked]       B-2018 Antwerp, Belgium
------------------------------------------\    /--------------
                                           \  /
                                            \/

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: [email-masked]

   Wim Livens
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-7570
   E-mail: [email-masked]

   Bernard Sales
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-9574
   E-mail: [email-masked]

Ooms, et al.                Expires May 1999                    [Page 7]

---

From: Cynthia Clark <[email-masked]>
Date: Fri, 20 Nov 1998 17:20:30 -0500

Hi Dirk,

Since this remote site <ds.internic.net> is no longer
in service, I've corrected and changed from
"ds.internic.net" to "ftp.ietf.org"
in the Status of this Memo section.  Please make
a note of this for your future drafts.
 
I'll send the announcement to the entire ietf
sometime tomorrow or next work day regarding
your new Internet-Draft <draft-ooms-mpls-pimsm-00.txt>
 
If you have any concerns about any drafts, then
please contact me directly at <[email-masked]>
anytime.
 
Kind Regards,
Cynthia
------------------------------------------------------
Cynthia Clark, IETF Internet-Drafts Publisher
E-mail Address preference:  <[email-masked]>
-------------------------------------------------------