| PIM Working Group | M.B. 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
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.
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 (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.
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].
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.
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.
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].
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].
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.
This document does not introduce any new security concerns. In fact, it reduces the risk of an attacker spoofing PIM Register packets.
Thanks to Stig Venaas for all his comments and feedback that resulted in significant improvement of this document.
This document places no requests to IANA.
| [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. |
| [RFC3936] | Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004. |
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.