Internet DRAFT - draft-archana-pimwg-pim-ping

draft-archana-pimwg-pim-ping



INTERNET-DRAFT             PIM-PING              Archana Patel
Expires 28 December 2007                         Cisco         
                                                 Janardhan Kulkarni
                                                 Citrix
                                                 28 June 2007




                          PIM-PING             
            <draft-archana-pimwg-pim-ping-00>


Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 
have been or will be disclosed, and any of which he or she becomes 
aware  will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt

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

Abstract

As multicast networks start to get deployed in large number, it 
becomes very important that, proper mechanisms are in place for 
trouble shooting error conditions and informing other failure 
situations. Since multicasting has little support from IP in this
matter (since ICMP does not support multicasting and broadcasting) it
behooves that, multicast routing protocols, embed these features in 
themselves. This draft presents some ideas about how this can be done
using PIM protocol suite as example, since PIMSSM and PIMSM are 
probably most widely used multicast routing protocols.




Archana/Janardhan            PIM-PING               [Page 1]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007






                          
                         Table of Contents

1.  Introduction                                                     3
2.  Terminology                                                      4
      2.1 Definitions                                                4
3.  PIM-PING Overview                                                5
4.  PIM-PING message formats                                         6
      4.1 Request Message format                                     6
      4.2 Response Message format                                    9
5.  Specification of PIM-Ping                                        10
      5.1. Checking Convexity in PIM-Domain                          10
         5.1.1. Sending the PIM-PING Request message                 10
         5.1.2. Processing of the PIM-PING packets at the 
                intermediate Routers                                 10
         5.1.3 Processing of the PIM-PING request packet at the 
               firsthop router towards destination or 
               at destination.                                       10 
      5.2. Checking for the RP consistency along a path              10  
         5.2.1 Sending the PIM-PING message to verify RP consistency 11
         5.2.2 Processing of the PIM-PING RP consistency messages 
               at the intermediate routers.                          11
         5.2.3 Processing of the PIM-PING RP consistency  messages 
               at destination.                                       11
      5.3. Request Types                                             12
      5.4. Response Types                                            12
6.  Processing the received response message                         13
7.  Message Verifications                                            13
8.  References                                                       14
9.  Author’s Address                                                 14
10. Copyright (C) The IETF Trust (2007)                              15


















Archana/Janardhan            PIM-PING               [Page 2]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







Justification

Multicast technology has been around for quite some time now. But 
widespread deployment of multicasting has just begun. All these days,
multicasting technology was revolving around developing efficient, 
scalable routing protocols. Now that, multicast routing protocols are
matured, PIMSSM and PIMSM have established themselves as principal 
multicast routing protocols, since many applications are using 
multicasting as their base technology, it is the time to address 
other aspects like debugging, trouble shooting and error reporting. 
Most of the work that has been done so far in these areas, either
depend on multicast tree being set up or support from IP, and MIBS. 
But it is our opinion that, multicast routing protocols should in 
themselves embed necessary mechanisms to address these issues, even if
it means protocol implementations needs to be tweaked. Also, we 
should note that, most of multicast routing protocols which use PULL
model like PIMSM, PIMSSM will create a multicast tree only if there
are some receivers join the tree. So, to get information about the 
reachability or to trace the path of multicast data, even before 
creating the tree it is necessary to extend the protocols. In this 
draft we want to present some extensions to PIM, which help in trouble
shooting PIM related issues. 


1. Introduction

This draft describes simple extensions to PIM protocol suite to test
the convexity of pim domain and RP consistency for a multicast group 
along a path.A convex pim domain implies that data from a multicast 
source can be received if the source lies within the domain. Hence 
this feature can also be used to test whether a multicast source can 
be reached within a pim domain and to test whether source is sending
multicast data. For PIMSM to function properly, it is required that,
group to RP mapping is consistent across the pim domain. Since, group
to RP mapping is done using various mechanisms like static 
configurations, BSR-RP and in case of IPV6 embedded RP, it is 
cumbersome to track the consistency of the mapping across all the 
routers. Hence these extensions to pim protocol suite can be handy to
debug these scenarios.We call these extensions as PIM-PING, since it 
does the same function for multicast as PING does for unicast routing.
 
PIM-PING as described in this draft can be used to solve following
problems:
o To test the convexity of pim domain, and to test whether a multicast
  data  source is active.
o To test whether RP mapping for a particular group is consistent, at
  all the routers. 


Archana/Janardhan            PIM-PING               [Page 3]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007






o To trace the route through which multicast data will traverse, 
  within a pim domain.
o To calculate approximately the time needed to construct a SPT or RPT. 
  


2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 and  "OPTIONAL" are to be interpreted as described in RFC 2119 [1]
and indicate requirement levels for compliant PIM-PING 
implementations.

2.1. Definitions
   The following terms have special significance for PIM-PING: 

   RPF Interface
         RPF stands for "Reverse Path Forwarding".  The RPF Interface 
         of a router with respect to an address is the interface that
         the unicast-routing table indicates should be used to reach 
         that address.

   RPF Neighbor
         The RPF Neighbor of a router with respect to an address is 
         the neighbor that the Unicast Routing Table indicates should
         be used to reach that address. 

   PIM Neighbor
         Any adjacent router from which pim hello messages are 
         received.

   Rendezvous Point (RP):
         RP is a router that has been configured to be used as the
         root of the non-source-specific distribution tree for a 
         multicast group.  Join messages from receivers for a group 
         are sent towards the RP, and data from senders is sent to 
         the RP so that receivers can discover who the senders are, 
         and start to receive traffic destined for the group.








Archana/Janardhan            PIM-PING               [Page 4]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







3. PIM-PING Overview

This document assumes some familiarity with working of PIM protocol 
suite, specially PIMSM or PIMSSM. PIM-PING uses a 2 new PIM Message
types, request and response message which are very similar to PIM 
Join/prune messages.These messages do not create any state at the 
intermediate routers, but it does involve processing of these 
messages by all the routers.

PIM-PING uses a method very similar to building a SPT or RPT in PIMSM 
(or PIMSSM), to test the convexity of PIM domain, or to do the RP 
consistency. A router generates request message which will be 
propagated hop by hop towards the destination router. If the any of 
the intermediate routers fail to propagate the message, they will 
generate response message back to router which originated the request.
If the request message reaches the destination successfully, a 
response message indicating the success will be generated and sent to
the originator of request.

Although this feature can be used for both IPV4 and IPV6 versions of
PIM protocols, here IPV4 is used to demonstrate the working of 
PIM-PING.

Consider the following topology:

               10.0.0.0        20.0.0.0      30.0.0.0   40.0.0.0 
   [S]-----R1------------R2-------------R3----------R4----------[R5]
            .1          .2  .1        .2  .1      .2 .1         .2


Suppose at R5, user wants to test the reachability of multicast source S,
which is sending multicast data for group G. So, router R5 
generates request message, with type as PIMPING_CONVEXITY_TEST, 
(request message types are explained in detail later) and sends it to
the RPF neighbor of S, which in this example is R4. 
R4 on reception of this packet, in turn sends this packet to R3, 
Which is RPF neighbor of S at R3. This process continues till either
message reaches R1 or one of the router fails to propagate the 
message.In the former case, R1 being the last hop router and since it
recognizes that S is a directly connected multicast data source, it 
sends back a unicast reply to R5, indicating the success.

In case of failure, where message cannot be propagated by a router,an 
appropriate response message will be generated by the router and will
be sent back to R5.



Archana/Janardhan            PIM-PING               [Page 5]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







A similar idea is used to check the RP consistency along a path. 
Taking the above example, suppose user wants to test whether all the 
routers from R5 to R2 use same RP for a particular multicast group G.
To verify this, R5 will originate a request message with type as
PIMPING_RPCONSISTENCY_TEST. It puts the group address and RP it is
using for that group in the packet and sends it to the RPF neighbor 
of destination (which is R2 now). When the packet reaches router R4, 
it verifies whether RP for group G it is using is same as one in the 
packet it has got. If the RP being used mismatch, a response message
is unicasted back to R5. If RP addresses match then it propagates’ 
the packet to RPF neighbor of destination. This continues till the 
packet reaches R2. Here R2 being the destination will send a response
message back to R5, informing the consistency of RP addresses along 
the path. If, any router fails to propagate the packet, either due to
RP inconsistency or, due to other problems like having no PIM 
neighbors, an appropriate response message will be generated back to
R5.
  
Routers also append their IPv4/IPV6 addresses in the request message, 
when they propagate the message towards destination. This list of 
router addresses is used to trace the path towards multicast data
source.

4. PIM-PING Packet Format

PIM-Ping uses 2 types of messages

o Request Message : This message is generated by the router which 
  wants to use PIM-PING functionality mentioned above. Request 
  packet format and fields are described in the section 4.1.

o Response Message : This message is  generated by the 
  firsthop router for destination or destination Router or 
  intermediate routers in case of failure, for a particular request.
  The message format is described in detail in the section 4.2.


4.1 Request Message:

All PIM control messages have IP protocol number 103.
PIM-PING request message is multicast with TTL 1 to the 
`ALL-PIM-ROUTERS' Group. The IPv4 `ALL-PIM-ROUTERS' group is 
`224.0.0.13'.  The IPv6 `ALL-PIM-ROUTERS' group is `ff02::d'.
In case of IPV6, the source address used for request Message is the
link-local address of the interface on which the message is being 
sent.


Archana/Janardhan            PIM-PING               [Page 6]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







Following is the PIM-Ping Request messages format:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Upstream Neighbor Address (Encoded-Unicast format)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |request/response|      NA      |          Sequence Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Destination address.  (EUF)                        |
   |          (Normally a Multicast data source)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Multicast Group address                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            The RP address Used  (ESF)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Routers           |   NA                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Router Address 1 (Originator of request)(ESF)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Router Address 2 (Encoded-Unicast format) (EUF)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Router Address n (Encoded-Unicast format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Ver
        PIM Version number is 2.

Type
        Type for PIM-Ping packet is 14

Reserved
        Set to zero on transmission.  Ignored upon receipt.

Checksum
        The checksum is a standard IP checksum, i.e.,the 16-bit one's
        complement of the one's complement sum of the entire PIM
        message.  For computing the checksum, the checksum
        field is zeroed.  If the packet's length is not an integral
        number of 16-bit words, the packet is padded with a trailing
        byte of zero before performing the checksum.

Archana/Janardhan            PIM-PING               [Page 7]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







        For IPv6, the checksum also includes the IPv6 
        "pseudo-header",as specified in RFC 2460, Section 8.1 [5].
        This "pseudo-header" is prepended to the PIM header for 
        the purposes of calculating the checksum.  The "Upper-Layer
        Packet Length" in the pseudo-header is set to the length of
        the PIM message.  The Next Header value used in the 
        pseudo-header is 103.

Upstream Neighbor Address
        The upstream neighbor address is the RPF neighbor address for
        the destination as indicated by the unicast RIB. Unicast 
        Encoding Format used is same as mentioned in Section 4.9.1,
        RFC 4601.

Request Type 
        Request Types are mentioned in Section 5.3.
              
NA
        Field will be set as zero.

Sequence Number 
        Randomly generated number to identify the request message.

Destination address
        Destination address is the address of the router, or 
        multicast source, the path of which is being tested for 
        convexity or RP consistency. 

Group Address 
        This field contains the multicast group address in encoded 
        group format, for which RP consistency check is being carried
        out. If the request type is PIMPING_CONVEXITY_TEST,this field
        will be set to 0, and should be ignored by the routers.

RP Address
        This field contains the RP being used for a multicast group 
        address at a router. If the request type is 
        PIMPING_CONVEXITY_TEST, this field will be set to 0, and 
        should be ignored by the routers.

Number of routers 
        This field gives the number of router addresses appended in 
        the router address list.





Archana/Janardhan            PIM-PING               [Page 8]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







Router Address
        Every router when it propagates the request message will also 
        append its own address to the request message. The first 
        address in this list is that of the router which initiated 
        this request, is used as destination address to generate the 
        response message. The list of router addresses helps in 
        tracing the multicast path towards a  particular destination.
        The address appended is always global routable unicast 
        address, present on the RPF interface on which message will 
        be propagated.

4.2 The Response Message Format:

The response message is same as the request message, except the 
following 2 differences.
    o Request type field becomes Response type.
    o When the response is for RP consistency, the “The RP address 
      field”, will indicate, in failure cases, the RP address used
      for a particular group, at the router where RP’s used for a 
      particular multicast group address mismatch.

PIM-PING response message has IP protocol number 103.

The response message is unicasted to originator of the request. 
Address of the originator of request, is got from first address of 
the routers list from request message.  The source address used for
response message is a domain-wide reachable unicast routable address.

TTL value for response message is same as TTL value used by unicast 
packet on that router.

Upstream Neighbor Address
      Upstream Neighbor address is set to 0 by sender and
      is ignored by receiver.

Response Type
      Response type values are mentioned in Section 5.7.

All other fields of the response message shall remain same as 
received request packet for which response is generated. 
                      
  






Archana/Janardhan            PIM-PING               [Page 9]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







5.  Specification of PIM-PING functionality.

5.1  Checking the convexity of PIM-Domain. 
 
5.1.1 Sending the PIM-PING request message.

When a router wants to verify the reachability of a multicast source, 
or wants to verify the convexity of PIM domain, it generates a 
request message and sets the request type as PIMPING_CONVEXITY_TEST.
Destination address and upstream neighbor address fields are filled.
It also includes a sequence number, which is a randomly generated 
number to identify the request message. Number of routers field is 
set as 1, IP address present on the RPF interface towards 
destination is appended and packet is sent to PIM-ALLROUTERS. An 
optional implementation may start a timer and repeat the whole 
process for certain number of times, to make it robust against 
possible loss of packets. 

5.1.2 Processing of the PIM-PING packets at the intermediate routers.

When an intermediate router receives a PIM-PING request message, it
does message verification as described in section 7. Request 
message is dropped, if any of the verification checks fail. Router 
then looks up RPF neighbor for destination address present in the 
message. If RPF neighbor is found, it fills this address in upstream
neighbor field and adds its own IP address present on the RPF 
interface to the list of router’s addresses.  Number of routers count
is incremented and packet is sent to PIM-ALLROUTERS.  If the router 
fails to propagate request message it generates a reply message as 
described in the section 5.4. 

5.1.3 Processing of the PIM-PING request packet at the firsthop 
      router towards destination or at destination. 

When the first hop router towards destination or destination router 
receives the PIM-PING message, it does the message verification as 
described in Section. A unicast reply message is sent back to towards
the router which issued the request. Details about the various 
responses are given in section 5.4.


5.2. Checking for the RP consistency along a path.
 





Archana/Janardhan            PIM-PING               [Page 10]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







5.2.1 Sending the PIM-PING message to verify RP consistency.

When a router wants to verify the RP consistency for group, it
generates a request message and sets the request type as
PIMPING_RPCONSISTENCY_TEST. Destination address and upstream neighbor
address fields are filled. The multicast group address for which RP
consistency needs to be verified and RP being used for that group are
set. 

It also includes a sequence number, which is a randomly generated 
number to identify the request message.  Number of routers field is 
set to 1, IP address present on the RPF interface towards destination
is appended and message is sent to PIM-ALLROUTERS. An optional 
implementation may start a timer and repeat the  whole process for 
certain number of times, to make it robust against possible loss of
packets. 

5.2.2 Processing of the PIM-PING RP consistency messages at the 
      intermediate routers.

When an intermediate router receives a PIM-PING request message, it
does message the verification as described in section 7. Request 
message is silently dropped, if any of the verification checks fail.
Router then verifies whether RP addresses being used for multicast 
group are consistent .If they match, router then looks up RPF 
neighbor for destination address present in the message. If RPF 
neighbor is found, it fills this address in upstream neighbor field 
and adds its own IP address present on the RPF interface to the list 
of router’s addresses.  Number of routers count is incremented and 
packet is sent to PIM-ALLROUTERS.  If the RP addresses mismatch or 
router fails to propagate request message it generates a reply 
message as described in the section 5.4. 

5.2.3 Processing of the PIM-PING RP consistency  messages at 
      destination. 

When the destination router receives the PIM-PING message, it does
the message verification as described in Section 7. A unicast reply 
message is sent back to towards the router which issued the request.
Details about the various responses is described in detail in section
5.4.







Archana/Janardhan            PIM-PING               [Page 11]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







5. 3 The request types:

This draft describes following two request types

1.  To verify convexity of PIM domain (PIMPING_CONVEXITY_TEST):
    This request type is used to check the convexity of pim domain or
    reachability of multicast data source through a pim domain. The 
    value for this is 1.
2.  To verify RP consistency (PIMPING_RPCONSISTENCY_TEST): 
    This request type is used to check the RP consistency. The value
    for this is 2.


5.4 The response types:

The following are the response types and the values for them, as 
described in this draft. 

1. Source is active [PIMPING_DESTINATION_ACT]: 
   This will be the response type, when a response message is 
   generated by the first hop router in the subnet of destination or
   destination router itself. Value is 3.

2. Source is not active but is reachable 
   [PIMPING_ DESTINATION _REACHABLE]: 
   This is  the response type, when a response message is generated 
   by the first hop router in the subnet of destination or 
   destination router itself. Destination is reachable but is not 
   sending the multicast data. Value is 4.

3. Destination is not present in the subnet of firsthop router.
   [PIMPING_ DESTINATION _NOTPRESENT]:
   This will be the response type, when a reply message is generated the
   first hop router in the subnet of destination. This response will
   be generated only when first hop router in the subnet of
   destination has the knowledge that destination address being 
   pinged is not present. Value is 5.

4. Destination is not reachable since unicast route is not present: 
   [PIMPING_DESTINATION_NOUNICASTROUTE]:
   This response is generated by intermediate routers. Since unicast
   route is not there, (or no static multicast RPF interface is not 
   configured) join cannot be propagated further. Value is 6. 





Archana/Janardhan            PIM-PING               [Page 12]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







5. Destination is not reachable since there there is no pim neighbor
   on the RPF interface [PIMPING_DESTINATION_NOPIMNBR]:
   This response is generated by intermediate routers. Since pim 
   neighbor is not present, the request message cannot be propagated 
   further. Value is 7. 

6. Destination is not reachable due to configuration issues
   [PIMPING_DESTINATION_NOPIMCFG]:
   This response is generated by intermediate routers. 
   Due to configuration related problems, the request message cannot
   be forwarded. Value is 8.

7. RP addresses used at for a particular group mismatch 
   [RP_MISMATCH]:
   This response is generated by the router, when the RP address used
   for a particular group mismatch. The value is 9.

8. RP addresses used for a particular group are consistent 
   [RP_CONSISTANT]:
   This will be generated by the last hop router or router to which 
   request is issued. This means that, all the routers are using 
   the same RP address for a particular multicast group address, 
   along this path. The value is 10.


6. Processing the recieved response message.

The router which recieves the response message should do the packet 
verification as desribed in the section 9. It should check the source
address and sequence number fields to verify that response message
is for the request it sent. If the response is intended to it,
response type indicates result of its query.


7. Message Verification

The following fields of the request and response messages should be 
verified for the validity before message is processed by the routers.
If any of the checks fail, message should be dropped.

1. PIM Ver and Type must have value mentioned in Section 4.1.
2. Upstream address must be valid unicast ip address for ipv4 and 
   valid link-local address for IPv6. This field shall be ignored in
   response message.
3. Destination address must be valid unicast global ip-address.
4. Routers’ List must contain valid unicast global ip-addresses.


Archana/Janardhan            PIM-PING               [Page 13]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007







   For RP Consistency messages :
5. RP address must be valid unicast global ip-address.
6. Group address must be valid multicast address.
   Above fields must be set to zero in the request and
   response messages for domain convexity tests.


8. References

   [1] RFC 4601 – Protocol Independent Multicast – Sparse Mode:
       Protocol Specification

   [2] RFC 3973 – Protocol Independent Multicast – Dense Mode

   [3] draft-ietf-pim-bsr-10.txt – Bootstrap Router (BSR) Mechanism
       for PIM

   [4] draft-ietf-pim-ipv6-03.txt - Protocol Independent Multicast
       Routing in IPv6


9. Author's address
        Janardhan Kulkarni,
        Citrix systems, 
        Bangalore.
        email: janardhan.kulkarni@citrix.com
 
        Archana Patel, 
        Cisco Systems, Inc.,
        Bangalore.
        email: archanap@cisco.com

















Archana/Janardhan            PIM-PING               [Page 14]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007








10. Copyright (C) The IETF Trust (2007)

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights.

This document and the information contained herein are provided on
An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard.  Please address the information to the IETF at 
ietf- ipr@ietf.org.









Archana/Janardhan            PIM-PING               [Page 15]
INTERNET-DRAFT               Exp: Dec 2007          28 June 2007