All things related to multicast

[Bill Nickless <>]

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


                          An MSDP Query Protocol


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

   This document describes a protocol to query the status and operation
   of a Multicast Source Discovery Protocol (MSDP) speaker, as a way to
   support diagnosis of MSDP reachability problems among other uses.



   Nickless      Informational - Expires August 2001                1 
                        An MSDP Query Protocol           February 2001

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Conventions used in this document..................................2
   Protocol Motivations...............................................2
   Procedure..........................................................3
   Hypothetical Queries...............................................3
   Hypothetical Send Queries..........................................5
   Hypothetical Receive Queries.......................................6
   Cache Queries......................................................7
   Cache Send Queries.................................................8
   Cache Receive Queries..............................................9
   Expected Querier Strategies.......................................11
   Security Considerations...........................................12
   References........................................................13
   Author's Address..................................................13


Overview

   Current best practice for fixing MSDP forwarding problems requires
   Looking Glass-style access to MSDP speakers.  The process of working
   from one MSDP speaker to another is always tedious, and is often
   impossible without the cooperation of the network engineers at each
   step along the way.

   This Memo describes a protocol that provides visibility into the
   operation and state of an MSDP speaker.  User-level, automated tools
   can use this protocol to illuminate MSDP problems where they exist.


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


Protocol Motivations

   Three widely-used tools are used to test and debug IP Unicast
   routing in an internet.  Traceroute [2] is usable by anyone on the
   network, as it does not depend on any authenticated access to the
   network devices.  Network engineers within an organization may
   choose SNMP [3] to obtain detailed status information about network
   devices.  Network engineers may also use command line queries,
   either directly or by way of Looking Glass [4] style web interfaces,
   to discover the network device state.


   Nickless      Informational - Expires August 2001                2 
                        An MSDP Query Protocol           February 2001

   In the case of IP Multicast routing, the path used by packets from
   active sources to receivers can be followed through the use of the
   mtrace [5] protocol and tool, as an analogue to the unicast
   traceroute tool.  This Memo seeks to provide an analogue to
   traceroute and mtrace for MSDP.

   There are two schools of thought on how an MSDP traceroute analogue
   should be developed and operate.  One school holds that MSDP should
   operate in a constrained manner such that the MSDP Source Active
   forwarding tree will be built in a defined way based on a given set
   of M-BGP and other Reverse-Path Forwarding rules.  Another school
   holds that MSDP would be more robust if these forwarding rules were
   relaxed, using caches at each MSDP speaker to avoid forwarding
   loops.  The protocol outlined in this Memo is explicitly designed to
   operate within the framework that each school prefers.


Procedure

   An MSDP speaker listens on UDP port 639 (already reserved by IANA
   for MSDP).  Queries arrive on that port from interested hosts and
   are processed by the MSDP speaker.  A reply is constructed and
   transmitted by the MSDP speaker.

   There are two types of queries that an MSDP speaker may receive:
   Hypothetical and Cache.  In the case of Hypothetical queries, the
   MSDP speaker follows its internal logic and configuration to
   determine what action, if any, would be taken if it were to receive
   an MSDP SA as specified in the query.  In the case of a Cache Query,
   the MSDP speaker looks in its cache (if it exists) and reports on
   the contents of the cache that match the query, if any.


Hypothetical Queries

   The Hypothetical Query is intended to allow an interested host to
   discover whether a given MSDP SA message would be accepted or
   forwarded.

   An interested host sends a Hypothetical Query Packet to an MSDP
   speaker, where it is processed and returned.


   Nickless      Informational - Expires August 2001                3 
                        An MSDP Query Protocol           February 2001

   A Hypothetical query packet is a UDP packet with a payload in this
   format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |H|S| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source address                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RP address                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Peer address                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Max Peers     | Reserved, set to all 0 bits                   |
   | to report     |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  32 bits reserved, set to all 0 bits, for each possible       |
   |  Peer based on the Max (RP,Peer)s value in the preceding word |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bit 0, word 0 is the H bit, or "Hypothetical" bit.  All Hypothetical
   Queries have this bit set.

   Bit 1, word 0 is the S bit, or Send/Accept bit.  If this bit is set,
   the Query is asking the MSDP speaker to which peers, if any, an
   accepted MSDP SA would be sent (forwarded).  If this bit is cleared,
   the Query is asking the MSDP speaker from which peers, if any, an
   MSDP SA would be accepted.

   The 14-bit opaque query handle is used by a querying host as a means
   to keep multiple queries and replies straight.

   The Source Address is the IPv4 address of a hypothetical or real IP
   Multicast Source.

   The Group address is the IPv4 Multicast Group address, on which the
   hypothetical source would be transmitting.

   The RP address is a hypothetical PIM Sparse Mode Rendezvous Point
   address, associated with the Source and Group.

   The Peer address identifies which peer the hypothetical MSDP SA
   should be considered as being received on by this MSDP speaker.  The
   Peer address MAY be all zeros, equivalent to the IPv4 address
   0.0.0.0.



   Nickless      Informational - Expires August 2001                4 
                        An MSDP Query Protocol           February 2001

Hypothetical Send Queries

   Upon receipt of a Hypothetical Query with the Send/Receive bit set,
   the MSDP speaker goes through its logic for deciding whether to
   forward an MSDP SA with the associated Source, Group, RP, and Peer
   addresses to each of its configured peers.  This logic should ignore
   any cached SAs and their associated timers, if any.  The MSDP
   speaker constructs a packet of this form and returns it to the
   interested querier.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source address as originally received                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Group address as originally received                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RP address as originally received                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Peer address as originally received                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Number Of     | Reserved, set to all 0 bits                   |
   | Peers Reported|                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Peer addresses that would be forwarded this SA (if any)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bits 0 and 1 of Word 0 will be set in the case of a Hypothetical
   Send Query, and will be set in the case of the associated reply.

   The Source, Group, RP, and Peer addresses are returned unaltered.

   The Number Of Peers Reported is a number ranging from 0 to 255,
   specifying how many peers (up to 255) would be forwarded the
   hypothetical accepted MSDP SA.

   Starting in word 6, the remainder of the UDP payload consists of the
   IPv4 address of the peers, if any, to which the MSDP SAs would be
   forwarded.

   In the original Query, the Peer address MAY have been set to all
   zeros, equivalent to the IPv4 address 0.0.0.0.  In this case, the RP
   address is ignored and the MSDP speaker calculates which of its
   Peers (if any) would be sent a hypothetical SA if it had received
   the (S,G) packet in a PIM Sparse Mode Register from within its PIM
   Domain.



   Nickless      Informational - Expires August 2001                5 
                        An MSDP Query Protocol           February 2001

Hypothetical Receive Queries

   Upon receipt of a Hypothetical Query with the Send/Receive bit is
   clear, the MSDP speaker goes through its logic for deciding whether
   to accept an MSDP SA with the associated Source, Group, RP, and Peer
   addresses.  This logic should ignore any cached SAs and their
   associated timers, if any.  The MSDP speaker constructs a packet of
   this form and returns it to the interested querier:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source address as originally received                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Group address as originally received                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RP address as originally received                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Peer address as originally received                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Number Of     | Reserved, set to all 0 bits                   |
   | Peers Reported|                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Peer addresses that would be forwarded this SA (if any)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bits 0 and 1 of Word 0 will be set and clear, respectively, in the
   case of a Hypothetical Receive Query, and will be preserved in the
   associated reply.

   The Source, Group, RP, and Peer addresses are returned unaltered.

   The Number of Peers Reported is a number ranging from 0 to 255,
   specifying how many peers (up to 255) are reported in the rest of
   the UDP payload.

   The Peer address MAY be set to all zeros, equivalent to the IPv4
   address 0.0.0.0.  In this case, the MSDP speaker should report all
   Peer addresses (if any) that would be acceptable sources for a
   hypothetical MSDP SA with given Source, Group, and RP addresses.

   If the Peer address is not set to all zeros, the MSDP speaker should
   determine whether a hypothetical MSDP SA with given Source, Group,
   and RP addresses would be accepted from that peer.  If so, then the
   Number Of Peers Reported is set to one and the Peer address is
   reported.  If not, then the Number Of Peers Reported is set to zero
   and no Peer address is reported.



   Nickless      Informational - Expires August 2001                6 
                        An MSDP Query Protocol           February 2001

Cache Queries

   The Cache Query is intended to allow an interested host to discover
   whether a given MSDP SA message exists in the MSDP Speaker's cache,
   and how that SA is being treated.

   An interested host sends a Cache Query Packet to an MSDP speaker,
   where it is processed and returned.

   A Cache Query packet is a UDP packet with a payload in this format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |H|S| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source address                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RP address                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Peer address                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Max (RP,Peer)s| Reserved, set to all 0 bits                   |
   | To Report     |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  64 bits reserved, set to all 0 bits, for each possible       |
   |  Peer based on the Max (RP,Peer)s value in the preceding word |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bit 0, word 0 is the H bit, or "Hypothetical" bit.  All Cache
   Queries have this bit clear.

   Bit 1, word 0 is the S bit, or Send/Accept bit.  If this bit is set,
   the Query is asking the MSDP speaker from which peers, if any, the
   MSDP SA was received.  If this bit is cleared, the Query is asking
   the MSDP speaker to which peers, if any, the MSDP SA is being
   forwarded.

   The 14-bit opaque query handle is used by a querying host as a means
   to keep multiple queries and replies straight.

   The Source Address is the IPv4 address of an actual, active IP
   Multicast Source.

   The Group address is the IPv4 Multicast Group address, on which the
   actual, active IP Multicast Source is transmitting.


   Nickless      Informational - Expires August 2001                7 
                        An MSDP Query Protocol           February 2001

   The RP address is the hypothetical PIM Sparse Mode Rendezvous Point
   address, associated with the Source and Group.  The RP Address MAY
   be all zeros, equivalent to the IPv4 address 0.0.0.0.

   The Peer address identifies which peer the MSDP SA should be
   associated with in this query.  The Peer address MAY be all zeros,
   equivalent to the IPv4 address 0.0.0.0.

   The Max (RP,Peer)s To Report field indicates the maximum number of
   (RP,Peer) pairs that should be reported in any response.

   The rest of the packet consists of all zero bits, enough to contain
   the maximum possible responses as per the Max (RP,Peer)s To Report
   number.


Cache Send Queries

   Upon receipt of a Cache Query with the Send/Receive bit set, the
   MSDP speaker looks through its cache for matching (Source,Group)
   entries (if any).

   If the RP Address in the Cache Query is not set to all zeros,
   equivalent to the IPv4 address 0.0.0.0, the MSDP speaker MUST limit
   the matching (Source,Group) records (if any) to those that match the
   RP Address in the cache.

   If the Peer Address in the Cache Query is not set to all zeros,
   equivalent to the IPv4 address 0.0.0.0, the MSDP speaker SHOULD
   limit the matching (Source,Group) records (if any) to those that
   were received from its MSDP peer with that IPv4 address.


   Nickless      Informational - Expires August 2001                8 
                        An MSDP Query Protocol           February 2001

   The MSDP speaker constructs a packet of this form and returns it to
   the interested querier:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |H|S| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source address                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RP address                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Peer address                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | No. (RP,Peer)s| Reserved, set to all 0 bits                   |
   | Reported      |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RP address of cache entry                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peer Address to which cache entry will be forwarded received |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bits 0 and 1 of Word 0 will be clear and set, respectively, in the
   case of a Cache Send Query, and these settings will be preserved in
   the associated reply.

   The Source Address, Group Address, RP Address, and Peer Address
   fields will be preserved in the associated reply.

   The Number Of (RP,Peer)s Reported field will contain the number (0
   to 255) of the (RP,Peer) pairs that follow in the UDP payload.

   The rest of the UDP payload consists of (RP,Peer) address pairs of
   matching MSDP SA cache entries (if any).  The first word of each
   reply SHALL contain the RP address of the SA in the cache.  The
   second word of each pair SHALL contain the address of a Peer to
   which the MSDP SA will be forwarded.


Cache Receive Queries

   Upon receipt of a Cache Query with the Send/Receive bit clear, the
   MSDP speaker looks through its cache for matching (Source,Group)
   entries (if any).

   If the RP Address in the Cache Query is not set to all zeros,
   equivalent to the IPv4 address 0.0.0.0, the MSDP speaker MUST limit
   the matching (Source,Group) records (if any) to those that match the
   RP Address in the cache.

   Nickless      Informational - Expires August 2001                9 
                        An MSDP Query Protocol           February 2001


   If the Peer Address in the Cache Query is not set to all zeros,
   equivalent to the IPv4 address 0.0.0.0, the MSDP speaker SHOULD
   limit the matching (Source,Group) records (if any) to those that
   were received from its MSDP peer with that IPv4 address.

   The MSDP speaker constructs a packet of this form and returns it to
   the interested querier:


                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |H|S| 14-bit opaque query handle  |   16-bit CRC of UDP payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source address                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RP address                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Peer address                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | No. (RP,Peer)s| Bit Vector [0..24] denoting which (RP,Peer)   |
   | Reported      | is being used as data for PIM Shared Tree     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RP address of cache entry                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peer Address from which cache entry was accepted             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bits 0 and 1 of Word 0 will be clear and set, respectively, in the
   case of a Cache Send Query, and these settings will be preserved in
   the associated reply.

   The Source Address, Group Address, RP Address, and Peer Address
   fields will be preserved in the associated reply.

   The Number Of (RP,Peer)s Reported field will contain the number (0
   to 255) of the (RP,Peer) pairs that follow in the UDP payload.

   The Bit Vector denotes which (RP,Peer)s (if any) in the cache is
   being inspected for encapsulated data, and if there is encapsulated
   data, is being sent down the PIM Sparse Mode Shared Tree.  For
   example, if the third (RP,Peer) reported is being used for that
   purpose, bit 10 of Word 6 will be set.

   The rest of the UDP payload consists of (RP,Peer) address pairs of
   matching MSDP SA cache entries (if any).  The first word of each
   reply SHALL contain the RP address of the SA in the cache.  The

   Nickless      Informational - Expires August 2001               10 
                        An MSDP Query Protocol           February 2001

   second word of each pair SHOULD contain the address of the Peer from
   which the MSDP SA was received and accepted.


Expected Querier Strategies

   It is difficult to predict what uses may be made of the information
   that this protocol makes available to interested queriers.  The
   following should be considered speculation until actual experience
   is gained.

   A Traceroute-like tool could be developed that traces the path of an
   MSDP SA from a given MSDP speaker back to its originating PIM
   Rendezvous Point.  This tool would perform Cache Receive Queries on
   each successive MSDP Speaker until it reaches the MSDP Speaker that
   originated the MSDP SA to begin with.

   A more sophisticated tool could do a recursive traversal of MSDP
   peers, finding all possible ways an MSDP SA could be forwarded from
   one MSDP speaker to another.  The resulting graph could be used to
   generate maps.  This tool could use Cache Queries to follow actual
   MSDP SA messages in an internet, or Hypothetical Queries to operate
   in their absence.

   An even more sophisticated tool could be used to discover why MSDP
   SAs are not properly flowing from one MSDP speaker to another, again
   querying MSDP speakers recursively.  This tool would use Cache Send
   Queries to discover how far the SAs are actually being propagated
   from a given originator.  A historical graph, generated by a tool
   described in the previous paragraph, could be used to help guide the
   search.

   Hypothetical Receive and Send queries could be used to work from the
   MSDP speaker that is not receiving MSDP SAs on a given
   (Source,Group) towards a known MSDP speaker that does have them
   cached.  The strategy here would be to discover where policy or
   configuration error causes an interruption in reachability.
   Hypothetical Receive and Send queries could also be used to gain
   insight into the behavior of MSDP speakers that choose not to cache
   SA messages at all.


Acknowledgements

   This specification is inspired by Bill Fenner's desire for an MSDP
   traceroute facility.

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




   Nickless      Informational - Expires August 2001               11 
                        An MSDP Query Protocol           February 2001


Security Considerations

   The Query and Response packets are designed so that the Queries are
   always at least as long as the maximum Response.  This reduces the
   incentive for this protocol to be used as a Smurf-style amplifier.

   As with Traceroute, some network operators may wish to restrict the
   use of this protocol from outside users as it may provide hostiles
   with information about network topology.  This concern should be
   weighed carefully against the benefits of making this information
   available to those troubleshooting MSDP problems, both within and
   external to that network.

   Implementations SHOULD choose and implement appropriate rate limits
   so as to reduce the effect of attackers trying to use this protocol
   to consume all computational resources in an MSDP speaker.

   Nickless      Informational - Expires August 2001               12 
                        An MSDP Query Protocol           February 2001


References

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

   2  ftp://ftp.aces.com/pub/software/traceroute/

   3  RFC 2578 Structure of Management Information Version 2 (SMIv2). K.
      McCloghrie, D. Perkins, J. Schoenwaelder. April 1999

   4  ftp://ftp.enterzone.net/looking-glass

   5  draft-ietf-idmr-traceroute-ipm-07.txt Fenner, W. and Casner, S.,
      "A 'traceroute' facility for IP Multicast."



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               13