All things related to multicast

[Bill Nickless <>]

   Internet Draft                                           B. Nickless
   Document: draft-ietf-msdp-cache-only-00.txt         Argonne National
                                                             Laboratory
   Expires: August 2001                                   February 2001


           An Alternative Way To Stop MSDP Loops Through Caching


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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/ietf/1id-abstracts.txt

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


Abstract

   Proposed: to use a cache in each MSDP speaker to avoid Source Active
   forwarding loops.


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Conventions used in this document..................................2
   Procedure..........................................................2
   Claims.............................................................3
   Acknowledgements...................................................4
   Security Considerations............................................4
   References.........................................................4
   Author's Address...................................................5


Overview


   Nickless      Informational - Expires August 2001                1 
                      An Alternative Way To Stop         February 2001
                      MSDP Loops Through Caching

   Standard Multicast Source Discovery Protocol (MSDP) [1] loop
   avoidance is based on using RPF checks to verify that an incoming
   Source Active message is only accepted (and therefore forwarded)
   only once.

   This Memo describes an alternative strategy that uses a cache for
   each speaker instead of the RPF checks.  This strategy is motivated
   by a desire to make MSDP more robust, easier to troubleshoot, and
   simpler to configure.

   It is intended by the author that the strategy outlined in this Memo
   will eventually be incorporated as a new section 14.4 in [1].


Conventions used in this document

   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 [2].


Procedure

   An MSDP speaker shall maintain a cache of received MSDP Source
   Active messages.  Each line in this cache shall consist of six
   values:

   S       is the IPv4 address of the IP Multicast Source
   G       is the IPv4 address of the IP Multicast Group
   RP      is the IPv4 address of the advertising Rendezvous Point
   PA      is the IPv4 address of the peer from which we received
           a given Source Active message
   Expire  is the SA-State-Timer from [1].
   Hold    is the SA-Hold-Down-Timer from [1].
   D       is a 1-bit flag denoting whether or not this SA cache
           entry is used for decapsulating SA data, as per
           section 12 of [1].

   In addition, the MSDP speaker MAY maintain a count of cache lines
   received from a given peer, in order to provide rate limiting.


   Nickless      Informational - Expires August 2001                2 
                      An Alternative Way To Stop         February 2001
                      MSDP Loops Through Caching

   Upon receipt of a SA from a given Peer PA, the MSDP speaker will
   follow this pseudo-code algorithm:

   if (count of SAs from PA < configured maximum)
     then
       if (no matching (S,G,RP) in cache)
         then
           place (S,G,RP,PA,D=true) in cache
           initialize Expire timer
           initialize Hold timer
           decapsulate data and send down shared tree
           forward SA to all peers except PA
         else
           if (no matching (S,G,RP,PA) in cache)
             then
               place (S,G,RP,PA,D=false) in cache
               initialize Expire timer
               initialize Hold timer
               if (no (S,G,RP,*,D=true)
                 then
                   set (S,G,RP,PA,D=true)
                   decapsulate data and send down shared tree
               endif
             else
               reset Expire
               if ((S,G,Rp,PA,D==true))
                 then
                   decapsulate data and send down shared tree
                 else
                   if (no (S,G,RP,*,D==true))
                     then
                       set (S,G,RP,PA,D=true)
                       decapsulate data and send down shared tree
                   endif
               endif
               if (Hold has expired)
                 then
                   forward SA (S,G,RP) to all peers except PA
                   reset Hold
               endif
           endif
       endif
   endif

   If Expire associated with a given (S,G,RP,PA) expires, remove that
   cache line.


Claims

   This modification is backwards compatible with the existing protocol
   defined in [1].


   Nickless      Informational - Expires August 2001                3 
                      An Alternative Way To Stop         February 2001
                      MSDP Loops Through Caching

   This modification provides greater redundancy and therefore
   robustness, because MSDP SAs can take paths not chosen by the
   underlying routing protocol.  This can work around several classes
   of failure, especially unintentional black-holes.

   Only one SA will be decapsulated and sent down the PIM shared tree
   per SA-Hold-Down-Timer.  Let us assume that there is an interested
   listener within the PIM domain controlled by this MSDP speaker.  At
   worst, there will be a data packet lost from a succeeding MSDP SAs
   that arrive between the arrival of the first MSDP SA and the
   establishment of the inter-domain source specific tree.  That is, if
   packets are routinely arriving with a frequency greater than one per
   SA-Hold-Down-Timer, the inter-domain source specific tree will be
   set up and delivering those packets already.  The source specific
   tree will remain up for at least Join-Prune Holdtime, currently
   specified as 210 seconds by default as per [3].

   Networks unable to upgrade to software capable of handling these new
   semantics should be able to talk to a dedicated MSDP speaker using
   the MSDP default peer semantics (section 14.2 of [1]).



Acknowledgements

   The author would like to thank Brian Edwards for the original
   statement of the pseudo-code algorithm reproduced above.  Greg
   Shepherd and Toerless Eckert pointed out weaknesses and made
   suggestions for improvement that have been incorporated.

   Bill Nickless' work was supported by the Mathematical, Information,
   and Computational Sciences Division subprogram of the Office of
   Advanced Scientific Computing Research, U.S. Department of Energy,
   under Contract W-31-109-Eng-38.


Security Considerations

   Implementations SHOULD choose and implement appropriate rate limits
   so as to reduce the effect of intentional or inadvertent consumption
   of all available memory in an MSDP speaker.  This can happen when an
   improperly configured scanner sweeps across the IP Multicast address
   range (224.0.0.0/4), creating an MSDP SA with each packet sent.

   Wider flooding of MSDP SAs may lead to the encapsulated data being
   spread further than might otherwise happen, leading to data floating
   around outside a network that otherwise should not.


References

   Nickless      Informational - Expires August 2001                4 
                      An Alternative Way To Stop         February 2001
                      MSDP Loops Through Caching


   1  Farinacci, D., Rekhter, Y., Meyer, D., Lothberg, P., Kilmer, H.,
      Hall, J.  "Multicast Source Discovery Protocol (MSDP)" draft-
      ietf-msdp-spec-06.txt

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

   3  RFC 2362 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.
      Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei.
      "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
      Specification."



Author's Address

   Bill Nickless
   Argonne National Laboratory
   9700 South Cass Avenue #221     Phone:  +1 630 252 7390
   Argonne, IL 60439               Email:  


   Nickless      Informational - Expires August 2001                5