PIM Working Group                                              M. Bhatia
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                       February 11, 2011
Expires: August 15, 2011


         Replacing PIM Register packets with MPLS encapsulation
               draft-bhatia-pim-mpls-register-packets-00

Abstract

   In PIM-SM the designated router (DR) closest to the source keeps
   sending PIM register packets till it receives an explicit Register-
   Stop message from the rendezvous point (RP) router.  The process of
   encapsulating multicast data traffic to the RP, and the decapsulation
   done by RP are relatively expensive operations for a router to
   perform, depending upon whether or not the router has appropriate
   hardware support for these tasks.

   Since the PIM register messages are native IP packets and routed
   based on IP forwarding tables no resource reservation mechanisms are
   available.  All IP packets will follow common paths that are defined
   by the traditional IGP's algorithm and customizing the path for
   multicast applications is impossible.

   This document proposes using MPLS tunnel(s) to send traffic from the
   source to the RP till the shortest path tree (SPT) from the RP to the
   source is established.  Processing MPLS packets is easy and is
   readily supported on most platforms.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 15, 2011.

Copyright Notice



Bhatia                   Expires August 15, 2011                [Page 1]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Handling Null-Register Probes  . . . . . . . . . . . . . . . .  7
   4.  Handling Register-Stop Messages  . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Appendix  . . . . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14























Bhatia                   Expires August 15, 2011                [Page 2]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119[RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119[RFC2119].












































Bhatia                   Expires August 15, 2011                [Page 3]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Introduction

   PIM-SM [RFC4601]DR encapsulates all multicast packets that it
   receives directly from the source and sends these unicast to the RP
   for that group.  The multicast data traffic is encapsulated in PIM
   Register packets.  These packets convey the source address, S, and
   the group address, G to the RP.

   The RP decapsulates the PIM Register packets and forwards them
   natively down the RPT.  Additionally, the RP joins the SPT by sending
   a (S,G) Join to its RPF neighbor for the source and waits till it
   starts receiving multicast packets natively directly from the source.
   Till this happens, the RP must extract the multicast data traffic
   from every PIM Register packet it receives for the (S,G) pair that
   needs to be forwarded down the RPT natively.

   Encapsulation and Decapsulation are expensive operations for routers
   and the latter, especially, as it entails a double lookup that many
   routers cannot do in hardware.  It is for this reason that several
   off the shelf chips do not support decapsulating the PIM Register
   packets.  Any router that cannot decapsulate the PIM Register packet
   in hardware must send all this traffic to CPU, where its
   decapsulated, and forwarded based on the multicast forwarding table.
   This increases the load on the CPU and also makes the router
   susceptible for DoS attacks.  Also, since Register packets are
   unicast, then can be easily spoofed and an attacker can use this to
   attack the router and thus the network.

   This document attempts to solve the above problems by doing away with
   the PIM Register packets.  It instead proposes using an MPLS tunnel
   to send all multicast data traffic till an SPT is formed.  This
   eliminates the complexity of decapsulating PIM register packets on
   the RP as it now only needs to pop off the MPLS labels before
   forwarding the native packet down the RPT.

   The mechanism described in this draft is only applicable when both DR
   and the RP are MPLS capable and exist in an environment where they
   can use MPLS in data plane.

   Additionally there are other advantages in using MPLS as a transport
   mechanism over the native IP that PIM register traditionally uses.
   Operators can set up resource reservation along the entire path
   requesting a certain level of QoS for the multicast flow across the
   network.  It simplifies operations by providing a common operational
   framework for unicast and multicast traffic.  The failover time is
   very less because of MPLS FRR mechanisms - something that's
   unachievable when using traditional IP.




Bhatia                   Expires August 15, 2011                [Page 4]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


   This document is only applicable to PIM-SM in the ASM (Any Source
   Multicast) mode and introduces no change to PIM-SSM (Source Specific
   Multicast).  This is because there is no concept of an RP in the
   latter.















































Bhatia                   Expires August 15, 2011                [Page 5]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Mechanism

   The DR close to the source MUST set up an MPLS RSVP-TE tunnel
   [RFC3936] between itself and the RP.  The operator can use various
   constraints in setting up the tunnel.  This tunnel would be used for
   sending all multicast data traffic till the RP is able to receive
   multicast traffic natively through the SPT.

   It is suggested that this tunnel be established ahead of time as soon
   as the RP is configured so that there is no signaling involved when
   receiving data traffic from the source.  A discussion about the life
   of the tunnel is beyond the scope of this draft and an operator could
   keep it for as long as there is traffic expected from the source.

   Implementations can either set up one RSVP-TE tunnel between the DR
   and the RP or multiple tunnels with different constraints per
   multicast group, G.

   This draft introduces no changes in how the DR sends the Register
   packets.  The same rules apply as defined in[RFC4601].  The only
   thing that changes is that the DR MUST send Register packets using
   the tunnel, instead of the regular registration encapsulation that's
   defined in [RFC4601].




























Bhatia                   Expires August 15, 2011                [Page 6]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Handling Null-Register Probes

   Implementations MAY use the RSVP-TE tunnel established between the DR
   and the RP to send Null-Register Probes or can continue sending them
   as specified in [RFC4601].














































Bhatia                   Expires August 15, 2011                [Page 7]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Handling Register-Stop Messages

   Implementations should continue sending Register-Stop messages as
   described in [RFC4601].  While there is nothing that prevents routers
   from establishing a reverse MPLS RSVP-TE tunnel from the RP to the DR
   that could be used for transporting these messages, there isn't too
   much that one would gain by doing that.  It is thus suggested that
   there should be no change in how the Register-Stop messages are sent.











































Bhatia                   Expires August 15, 2011                [Page 8]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Security Considerations

   This document does not introduce any new security concerns.  In fact,
   it reduces the risk of an attacker spoofing PIM Register packets.















































Bhatia                   Expires August 15, 2011                [Page 9]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  Acknowledgements

   Thanks to Stig Venaas for all his comments and feedback that resulted
   in significant improvement of this document.















































Bhatia                   Expires August 15, 2011               [Page 10]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  IANA Considerations

   This document places no requests to IANA.
















































Bhatia                   Expires August 15, 2011               [Page 11]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

8.2.  Informative References

   [RFC3936]  Kompella, K. and J. Lang, "Procedures for Modifying the
              Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936,
              October 2004.



































Bhatia                   Expires August 15, 2011               [Page 12]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


Appendix A.  Appendix

   As mentioned earlier, there is no change in the exchange that occurs
   between the DR and the RP.  This section just describes it in case
   someone would like to get more clarity on how the RSVP-TE tunnel is
   used.

   When the DR receives multicast traffic directly from the source for a
   multicast group it will not encapsulate this in a PIM Register
   packet.  It will instead forward this traffic over the MPLS tunnel
   that has been established between the DR and the RP.  The RP will
   receive this traffic over the RSVP-TE tunnel and will pop off the
   label, before sending it natively over the RPT towards the listeners.

   When the RP joins the SPT by sending (S,G) Join to its RPF neighbor
   for the source it will wait till it starts receiving packets natively
   before sending a Register-Stop message.  Meanwhile, it will continue
   using the traffic that arrives on the RSVP-TE tunnel and will forward
   it natively on the RPT tree.

   Upon receiving the Register-Stop message, the DR MUST stop sending
   the multicast data traffic over the RSVP-TE tunnel and should start a
   Register-Stop timer for the (S,G) pair.  The DR can periodically send
   a Null-Register to the RP over the tunnel.  The Null-Register message
   will be used to probe the RP to determine whether the DR needs to
   start sending normal multicast data traffic over the tunnel to the RP
   for the (S,G) pair.

   The RP upon receiving a Null-Register needs to decide if it wants to
   send a Register-Stop message back to the DR based on whether its
   receiving traffic natively or not.  If the RP sends a Register-Stop,
   the Register-Stop timer on the DR is reset before it expires, and the
   DR does not start sending data over the RSVP-TE tunnel again.

   If the Register-Stop is not sent and the DR's Register-Stop timer
   expires, the DR MUST start sending multicast data traffic over the
   MPLS tunnel to the RP until it receives another Register-Stop.














Bhatia                   Expires August 15, 2011               [Page 13]

 
Internet-Draft       replace-PIM-register-with-MPLS        February 2011


Author's Address

   Manav Bhatia
   Alcatel-Lucent
   Bangalore,
   India

   Email: manav.bhatia@alcatel-lucent.com











































Bhatia                   Expires August 15, 2011               [Page 14]