Internet DRAFT - draft-meng-pim-sm-enhancement

draft-meng-pim-sm-enhancement



 



INTERNET-DRAFT                                                   R. Meng
Intended Status: Informational                       Huawei Technologies
Expires: May 20, 2018                                  November 20, 2017


                        An Enhancement of PIM-SM

                  draft-meng-pim-sm-enhancement-01.txt

Abstract

   This document specifies an enhanced version of PIM-SM which works
   without requiring whole network deployment.


Status of this Memo

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2017 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
 


Rui Meng                  Expires May 20, 2017                  [Page 1]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Description  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Compatible Scheme  . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Sending Join/Prune Messages  . . . . . . . . . . . . . . .  4
     3.2.  Receiving Join Messages  . . . . . . . . . . . . . . . . .  4
     3.3.  Receiving Prune Messages . . . . . . . . . . . . . . . . .  5
   4.  Clean Slate Scheme . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Sending Join/Prune Messages  . . . . . . . . . . . . . . .  6
     4.2.  Receiving Join Messages  . . . . . . . . . . . . . . . . .  6
     4.3.  Receiving Prune Messages . . . . . . . . . . . . . . . . .  7
   5.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9






















 


Rui Meng                  Expires May 20, 2017                  [Page 2]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


1.  Introduction

   PIM-SM is a multicast routing protocol that can use the underlying
   unicast routing information base or a separate multicast-capable
   routing information base. It builds unidirectional shared trees
   rooted at a Rendezvous Point (RP) per group, and it optionally
   creates shortest-path trees per source. 

   However, PIM-SM must be deployed contiguously in the whole network,
   because a joining router can not join into a tree if the upstream
   neighbor does not support PIM-SM.

1.1.  Terminology

   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 RFC 2119 [RFC2119].


2.  Problem Description

   PIM-SM protocol works generally as follows: 

   1)Multicast receivers express their interests in receiving traffic
   destined for multicast by using IGMP, MLD or other mechanisms. 

   2)One of a receiver's local routers is elected as the Designated
   Router (DR) for that subnet. On receiving the receiver's expression
   of interest, the DR then sends a PIM Join message towards the
   RP/Source for that multicast group. The Join message travels hop-by-
   hop towards the RP/Multicast source for the group, and in each router
   it passes through, multicast tree state for group G is instantiated.
   Eventually, the Join message either reaches the RP/Multicast source
   or reaches a router that already has Join state for that group. 

   3)In RFC 7761, all join/prune messages are multicast with TTL 1 to
   the 'ALL-PIM-ROUTERS' group, a message receiver would compare Unicast
   Upstream Neighbor Address carried in the message with the address of
   itself, the message will be processed only if the two addresses are
   the same. 

   As long as there is one router does not support PIM in the path from
   a joining router to the target RP/Source, the router can not join
   into the RPT/SPT.

3.  Compatible Scheme

   This scheme is based on RFC 7761.
 


Rui Meng                  Expires May 20, 2017                  [Page 3]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


   New unicast Join/Prune messages(and their process procedures) will be
   introduced in this scheme and they will coexist with old Join/Prune
   messages.

3.1.  Sending Join/Prune Messages

   PIM-SM routers send join messages to join into multicast groups, send
   prune messages to leave multicast groups. 

   If upstream neighbor is a PIM-SM neighbor, old join/prune messages
   should be sent by the joining/pruning router even if unicast
   join/prune messages are being received.

   Otherwise, new unicast join/prune messages should be sent as below:

   1)If an RPT is being joined/pruned, the destination address of the
   unicast join/prune message should be the RP address, the source
   address of the unicast join/prune message should be the address of
   the joining/pruning router. 

   2)If an SPT is being joined/pruned, the destination address of the
   unicast join/prune message should be the multicast source address,
   the source address of the unicast join/prune message should be the
   address of the joining/pruning router, and there is no Joined/Pruned
   Source Address field in the message.

3.2.  Receiving Join Messages

   Both old join messages and new unicast join messages could be
   received:

   1)Old Join messages can only be received by PIM-SM neighbors of the
   sender, they should be processed according to RFC7761.

   2)Unicast Join messages could be received by PIM routers(other than
   RP/Multicast Source) through ACL or similar means, they could also be
   received by the destination(RP/Multicast Source) of the messages,
   receivers should create tunnels from themselves to senders along with
   new states.

   Join messages should be processed as below in detail:

   join_msg_arrives(msg) { 

       if (msg.dst == 224.0.0.13) {

           //The message should be processed according to RFC 7761 

 


Rui Meng                  Expires May 20, 2017                  [Page 4]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


       } else { 

           S = multicast_source(msg);

           state = S ? get_state(*, G) : get_state(S, G); 

           if (!state) {

               state = S ? new_state(*, G) : new_state(S, G); 

               if (msg.dst != self_addr) { 

                   if (upstream_neighbor_is_a_PIM-SM_neighbor) {

                       send_multicast_join_message;

                   } else {

                       new_msg = msg; 

                       new_msg.src = OIF(new_msg).addr; 

                       send(new_msg);

                   } 

               } 

           }

           add_IF_to_olist(state, create_tunnel(IIF(msg).addr,
   msg.src));

       } 

   }

   add_IF_to_olist(state, IF) {

       if (/*IF is in state's olist*/){

           return;

       }

       add(state.olist, IF);

   }
 


Rui Meng                  Expires May 20, 2017                  [Page 5]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


   IIF(msg) {

       return the input interface of msg;

   }

   OIF(msg) {

       return the output interface of msg;

   }

3.3.  Receiving Prune Messages

   Old Prune messages should be processed according to RFC7761.

   New Prune messages would be intercepted by PIM routers or be received
   be RP/Source, they should be processed as below.

   prune_msg_arrives(msg) { 

       if (msg.dst == 224.0.0.13) {

           //The message should be processed according to RFC 7761 

       } else { 

           S = multicast_source(msg);

           state = S ? get_state(*, G) : get_state(S, G); 

           if (state) {

               IIF = tunnel(IIF(msg).addr, msg.src) ?
   tunnel(IIF(msg).addr, msg.src) : IIF(msg);

               delete_IF_from_olist(state, IIF);

               if (state.olist_num == 0) {

                   delete_state(state);

                   if (msg.dst != self_addr) { 

                       if (upstream_neighbor_is_a_PIM-SM_neighbor) {

                           send_multicast_prune_message;

 


Rui Meng                  Expires May 20, 2017                  [Page 6]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


                       } else {

                           new_msg = msg; 

                           new_msg.src = OIF(new_msg).addr; 

                           send(new_msg);

                       }

                   } 

               }

           } else if (msg.dst != self_addr) {

               forward(msg);

           } else {

               //The prune message should be ignored

           }

       } 

   }

   delete_IF_from_olist(state, IF) {

       if (/*IF is not in state's olist*/){

           return;

       }

       delete(state.olist, IF);

   }

   IIF(msg) {

       return the input interface of msg;

   }

   OIF(msg) {

 


Rui Meng                  Expires May 20, 2017                  [Page 7]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


       return the output interface of msg;

   }

4.  Clean Slate Scheme

   This scheme is a modification of RFC 7761:

   1)Neighbor relationship between PIM routers will no longer be
   maintained.

   2)Join/Prune messages(and their process procedures) in RFC 7761 will
   be replaced by Join/Prune messages introduced in this section.

4.1.  Sending Join/Prune Messages

   Join/Prune messages will no longer be multicast with TTL 1 to the
   'ALL-PIM-ROUTERS' group, they will be unicast as below:

   1)If an RPT is being joined/pruned, the destination address of the
   join/prune message should be the RP address, the source address of
   the join/prune message should be the address of the joining/pruning
   router.

   2)If an SPT is being joined/pruned, the destination address of the
   join/prune message should be the multicast source address, the source
   address of the join/prune message should be the address of the
   joining/pruning router, and there is no Joined/Pruned Source Address
   field in the message.

4.2.  Receiving Join Messages

   Join messages could be received by PIM routers(other than
   RP/Multicast Source) through ACL or similar means, they could also be
   received by the destination(RP/Multicast Source) of the messages.

   A receiver should create tunnel from itself to the sender along with
   new state only if it is the sender's neighbor which can be identified
   by TTL in IPv4 packet or Hop Limit in IPv6 packet.

   Join messages would be intercepted by PIM routers or be received be
   RP/Source, they should be processed as below:

   join_msg_arrives(msg) { 

       S = multicast_source(msg);

       state = S ? get_state(*, G) : get_state(S, G); 
 


Rui Meng                  Expires May 20, 2017                  [Page 8]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


       if (!state) {

           state = S ? new_state(*, G) : new_state(S, G);

           if (msg.dst != self_addr) { 

               new_msg = msg; 

               new_msg.src = OIF(new_msg).addr;

               new_msg.ttl = 255; 

               send(new_msg); 

           } 

       }

       IIF = (msg.ttl == 255) ? IIF(msg) : create_tunnel(IIF(msg).addr,
   msg.src);

       add_IF_to_olist(state, IIF); 

   }

   add_IF_to_olist(state, IF) {

       if (/*IF is in state's olist*/){

           return;

       }

       add(state.olist, IF);

   }

   IIF(msg) {

       return the input interface of msg;

   }

   OIF(msg) {

       return the output interface of msg;

   }
 


Rui Meng                  Expires May 20, 2017                  [Page 9]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


4.3.  Receiving Prune Messages

   Prune messages would be intercepted by PIM routers or be received be
   RP/Source, they should be processed as below:

   prune_msg_arrives(msg) { 

       S = multicast_source(msg);

       state = S ? get_state(*, G) : get_state(S, G); 

       if (state) {

           IIF = tunnel(IIF(msg).addr, msg.src) ? tunnel(IIF(msg).addr,
   msg.src) : IIF(msg);

           delete_IF_from_olist(state, IIF); 

           if (state.olist_num == 0) {

               delete_state(state);

               if (msg.dst != self_addr) {

                   new_msg = msg; 

                   new_msg.src = OIF(new_msg).addr; 

                   send(new_msg);

               }

           }

       } else if (msg.dst != self_addr) {

           forward(msg);

       } else {

           //The prune message should be ignored

       }

   }

   delete_IF_from_olist(state, IF) {

 


Rui Meng                  Expires May 20, 2017                 [Page 10]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


       if (/*IF is not in state's olist*/){

           return;

       }

       delete(state.olist, IF);

   }

   IIF(msg) {

       return the input interface of msg;

   }

   OIF(msg) {

       return the output interface of msg;

   }

5.  Packet Formats

   There is only one modification about packet formats:

   If an SPT is being joined/pruned, there will be no Joined/Pruned
   Source Address field in the joined/pruned message, and the Number of
   Joined Sources in the message is 1.

6.  Security Considerations

   To be perfected.


7.  IANA Considerations

   There is no IANA consideration in this specification.


8.  References

8.1.  Normative References

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

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
 


Rui Meng                  Expires May 20, 2017                 [Page 11]

INTERNET DRAFT          An Enhancement of PIM-SM           November 2017


              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <http://www.rfc-
              editor.org/info/rfc2119>..

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <http://www.rfc-editor.org/info/rfc7761>.

Authors' Addresses

   Rui Meng
   Huawei Technologies Co., Ltd
   Huawei Campus, 156 Beiqing Road, Hai-dian District
   Beijing  100089
   China

   EMail: mengrui@huawei.com
































Rui Meng                  Expires May 20, 2017                 [Page 12]