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
