One document matched: draft-ietf-mboned-ssmping-02.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
         'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
    
<?rfc toc="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<rfc category="info" ipr="full3978" docName="draft-ietf-mboned-ssmping-02">
        <front>
                <title abbrev="ssmping">ssmping Protocol</title>
		<author initials='S.' surname='Venaas' fullname='Stig Venaas'>
			<organization>UNINETT</organization>
			<address>
				<postal>
					<city>Trondheim</city>
					<code>NO-7465</code>
					<country>Norway</country>
				</postal>
				<email>venaas@uninett.no</email>
			</address>
		</author>
		<author initials='H.' surname='Santos' fullname='Hugo Santos'>
			<organization>NEC Europe Ltd.</organization>
			<address>
				<postal>
					<street>Kurfuersten-Anlage 36</street>
					<city>Heidelberg</city>
					<code>69115</code>
					<country>Germany</country>
				</postal>
				<email>hugo.santos@nw.neclab.eu</email>
			</address>
		</author>
                <date month="November" year="2007" />
                <abstract><t>The ssmping protocol specified in this
document allows for checking whether one can receive multicast,
both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM),
as well as to obtain additional multicast related information. This
protocol is based on an implementation of tools called ssmping and
asmping.
</t></abstract>
<note title="Requirements Language">
                        <t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
                </note>
        </front>
        <middle>
                <section title="Introduction" anchor="intro">
		        <t>The ssmping protocol specified in this
document allows for checking multicast connectivity. Not only
reception of multicast (SSM or ASM), but can also provide other
information like multicast tree setup time, the number of hops the
packets have traveled, as well as the packet delay and loss.
This functionality resembles, in part, the ICMP Echo Request/Reply
infrastructure, but uses UDP and requires both a client and a server
implementing this protocol.
</t><t>
The protocol here specified is based on the actual implementation of
the ssmping and asmping tools <xref target="impl"/> which are widely
used by the Internet community to conduct multicast connectivity tests.
</t>
                </section>
                <section title="Architecture" anchor="arch">
<t>Before describing the protocol in detail, we provide a brief
overview of how the protocol may be used and what information it may
provide. 
The typical usage of an ssmping/asmping session is as follows. A server
runs continuously to serve requests from clients. When a user decides
to verify the multicast reception from a specific server (knowing one
of the server's unicast addresses is required), the client will send
a unicast message to the server asking for a group to use. Optionally
the user may have requested a specific group or scope, in which case
the client will ask for a group matching the user's request. The
server will respond with a group to use, or an error if no group is
available. Next, the client joins an SSM channel (S,G) where S is a
unicast address of the target server, or an ASM group G, where G is
the group specified by the server.
</t><t>
After joining the channel, the client unicasts ssmping requests to
the server. The requests are sent using UDP with destination port set
to the standardised ssmping port [TBD]. The
requests are sent periodically, e.g., once per second, to the server.
The requests contain a sequence number, and typically a timestamp. The
requests are echoed back by the server, except the server may add a
few options. To each request, the server sends two replies.
One as unicast back to the port and address the request was sent
from, and also one as multicast back to the port from which the request
originated with the requested group G as destination address. The server
should specify the TTL used for both the unicast and multicast messages
(we recommend at least 64) and includes a TTL option for the client
to compute the number of hops. The client should leave the channel/group
when it has finished its measurements.
</t>
<t>By use of this protocol, a client can obtain information about
several multicast delivery characteristics. First, by receiving
unicast replies, it can verify that the server is receiving the
unicast requests, is operational and responding. Hence, provided that
the client receives unicast replies, a failure to receive multicast
indicates either a multicast problem or a multicast administrative
restriction. If it does receive multicast, it knows not only
that it can receive; it may also estimate the amount of time it took to
establish the multicast tree (at least if it is in the
range of seconds), whether there are packet drops, and the length
and variation of Round Trip Times (RTT). For unicast, the RTT is the
time from when the unicast request is sent to when the reply is received.
The measured multicast RTT also references the client's unicast
request. By use of the TTL option specifying the TTL of the replies when
they are originated, the client can also determine the number of router
hops it is from the source. Since similar information is obtained in
the unicast replies, the host may compare its multicast and unicast
results and is able to check for differences in the number of hops,
RTT, etc. Provided that the server sends the unicast
and multicast replies nearly simultaneously, it may also be able to
measure the difference in one way delay for unicast and multicast on the
path from server to client, and also differences in
delay. Servers may optionally specify a timestamp.
This may be useful since the unicast and multicast
replies can not be sent simultaneously (the delay depending on
the host's operating system and load), or whether the client and server
have synchronised clocks.</t>
                </section>
                <section title="Protocol specification" anchor="protocol">
<t>
There are four different ssmping message types. There are
Echo Request and Echo Reply messages used for the actual
measurements; there is an Init message that SHOULD be used to
initialise a ping session and negotiate which group to use;
and finally a Server Response message that is mainly used in
response to the Init message.
</t>
<t>
The ssmping messages share a common format: one octet
specifying the message type, followed by a number of options in
TLV (Type, Length and Value) format. This makes the protocol
easily extendible. The Init message generally contains some
prefix options asking the server for a group from one of the
specified prefixes. The server responds with a Server Response
message that contains the group address to use, or possibly
prefix options describing what multicast groups the server may
be able to provide. For an Echo Request the client generally
includes a number of options, and a server may simply echo the
content back (only changing the message type), without inspecting
the options. However, the server SHOULD add a TTL option, and
there are some other options that a server implementation MAY
support, e.g., the client may ask for certain information or a
specific behaviour from the server.
The Echo Replies (one unicast and one multicast) MUST first
contain the exact options from the request (in the same order),
and then, immediately following, options appended by the server.
</t>
<t>
This document defines a number of different options. Some options
do not require processing by servers and are simply returned unmodified
in the reply. There are, however, other client options that the server
may care about, and also server options that may be requested by a
client. 
</t>
<t>
Unless otherwise specified, an option MUST NOT be used multiple
times in the same message.
</t>
			<section title="Option format" anchor="optformat">
<t>All options are TLVs formatted as specified below.
				<figure><artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value                             |
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
				</artwork></figure></t>
<t>Type (2 octets) specifies the option. The different options
are defined below.</t>
<t>Length (2 octets) specifies the length of the value field. Depending on
the option type, it can be from 0 to 65535.</t>
<t>Value. The value must always be of the specified length. See the
respective option definitions for possible values. If the length is
0, the value field is not included.</t>
			</section>
			<section title="Defined Options" anchor="opts">
<t>Version, type 0. Length MUST be 1. This option MUST always be
included in all messages, and the value MUST be set to 2 (in decimal).
Note that there are older implementations of ssmping that only partly
follow this specification. They can be regarded as version 1 and do
not use this option.</t>
<t>Client ID, type 1. Length MUST be non-zero.
A client SHOULD always include this option in all messages
(both Init and Request). The client may use any value it likes to be
able to detect whether a reply is a reply to this Init/Request or not.
A server should treat this as opaque data, and simply leave it
unchanged in the reply (both Server Response and Reply). The value
might be a
process ID, perhaps process ID combined with an IP address because
it may receive multicast responses to queries from other clients.
It is left to the client implementor how to make use of this option.</t>
<t>Sequence number, type 2. Length MUST be 4.
A client MUST always include this in Request messages and MUST NOT
include it in Init messages. A server replying to a Request message
MUST copy it into the Reply (or Server Response message on error).
This contains a 32 bit sequence number. The values would typically
start at 1 and increase by one for each request in a sequence.</t>
<t>Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include
this in Request messages and MUST NOT include it in Init messages.
A server replying to a request MUST copy
it into the Reply. In addition, a server supporting this option, 
SHOULD include it in Reply messages, if requested by the client.
Note that this means that the option may be present in the Reply
message twice; both a client timestamp as part of the echoed Request,
and another timestamp added by the server. The timestamp specifies
the time when the message (query or reply) is sent. The first 4
bytes specify the number of seconds since the Epoch (beginning
of the year 1970). The next 4 bytes specify the number of microseconds
since the last second since the Epoch.</t>
<t>Multicast group, type 4. Length MUST be greater than 1. It MAY
be used in Server Response messages to tell the client what group
to use in subsequent Request messages. It MUST be used in Request
messages to tell the server what group address to respond to (this
group would typically be previously obtained in a Server Response
message). It MUST be used in Reply messages (copied from the Request
message). It MUST NOT be used in Init messages.
The format of the option value is as below.
				<figure><artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Family         |  Multicast group address...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ....                         |

				</artwork></figure>
The address family is a value 0-65535 as assigned by IANA for Internet
Address Families <xref target="addrfamily"/>.
This is followed by the group address.
For IPv4 the option value length will be 6, for IPv6 18.</t>
<t>Option Request Option, type 5. Length MUST be greater than
1. This option MAY be used in Init and Request messages. It
MUST NOT be used in any other messages, except that a server
will, in a Reply, echo back this option if present in the Request.
This option contains a list of option types for options that
the client is requesting from the server. Support for this option
is optional for both clients and servers. The length of this option
will be a non-zero even number, since it contains one or more option
types that are two octets each. The format of the option value is as
below.
				<figure><artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Type          |          Option Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .....                             |

				</artwork></figure>
This option might be used by the client to ask the server to include
options like Timestamp or Server Information. A client MAY request
Server Information in Init messages; it MUST NOT request it in
other messages. A client MAY request a Timestamp in Request messages;
it MUST NOT request it in other messages.
</t>
<t>Server Information, type 6. Length MUST be non-zero. It MAY
be used in Server Response messages and MUST NOT be used in other
messages. Support for this
option is optional. A server supporting this option SHOULD add
it in Server Response messages if and only if requested by the
client. The value is a UTF-8 string that might contain vendor
and version information for the server implementation. It may
also contain information on which options the server supports.
An interactive client MAY support this option, and SHOULD then
allow a user to request this string and display it.
</t>
<t>Type 7, Reserved.  This option code value was used by early
implementations for an option that is now deprecated. This option
should no longer be used. Clients MUST not use this option,
and Servers MUST ignore it.</t>
<t>Pad, type 8. Length can be anything, including 0. This option
is used by clients to increase the request size in order to have
the server deliver responses of a particular size. If the server
adds any options
when responding, it should, if possible make the response the
same size as the request by shrinking the pad option (i.e., not
simply including it, as is, like all other client options). If the
options added by the server consume as much space as the pad
option does, or more, the server should remove the entire pad
option.</t>
<t>TTL, type 9. Length MUST be 1. This option contains a single
octet specifying the TTL of a Reply message. Every time a server
sends a unicast or multicast Reply message, it SHOULD include
this option specifying the TTL. This is used by clients to
determine the number of hops the messages have traversed. It
MUST NOT be used in other messages. Although this option is not
absolutely required, the server is expected to use it if it
knows what the TTL of the Reply will be. In general the server
can specify a specific TTL to the host stack.
</t>
<t>Multicast prefix, type 10. Length MUST be greater than 2. It MAY
be used in Init messages to request a group within the prefix(es),
it MAY be used in Server Response messages to tell the client what
prefix(es) it may try to obtain a group from. It MUST NOT be used
in Request/Reply messages.
				<figure><artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Family         | Prefix Length |Partial address|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ....      |

				</artwork></figure>
The address family is a value 0-65535 as assigned by IANA for Internet
Address Families <xref target="addrfamily"/>. This is followed by a
prefix length (0-32 for IPv4, 0-128 for IPv6), and finally a group
address. The group address need only contain enough octets to cover
the prefix length bits (e.g., there need be no group address if the
prefix length is 0, the group address would have to be 3 octets long
if the prefix length is 17-24). Any bits past the prefix length MUST
be ignored. For IPv4 the option value length will be 3-7, while for
IPv6 3-19.
</t>
<t>Session ID, type 11. Length MUST be non-zero. A server MAY
include this in Server Response and Reply messages. If a client
receives this option in a message, the client MUST echo the
Session ID option in Reply messages, with the exact same value,
until the next message is received from the server. If the next
message from the server has no Session ID or a new Session ID
value, the client should do the same, either not use the Session
ID, or use the new value.
</t>
			</section>
                </section>
                <section title="Packet Format" anchor="format">
<t>The format of all messages is a one octet message type,
directly followed by a variable number of options.
			<figure><artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |          Option                               |
   +-+-+-+-+-+-+-+-+            .                                  |
   |                            .                                  |
   |                            .                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                          Option                               |
   |                            .                                  |
   |                            .                                  |
   |                            .                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
                                .
				.
				.
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                          Option                               |
   |                            .                                  |
   |                            .                                  |
   |                            .                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
      			</artwork></figure></t>
<t>There are four message types defined. Type 81 (the character Q in
ASCII) specifies an Echo Request (Query). Type 65 (the character A in
ASCII) specifies an Echo Response (Answer). Type 73 (the character I in
ASCII) is an Init message, and type 83 (the character S in ACII) is a
Server Response message.</t>
<t>The options directly follow the type octet and are not aligned in
any way (no spacing or padding), i.e., options might start at any
octet boundary. The option format is specified above.</t>
		</section>
		<section title="Message types and options">
<t>For the readers convenience we provide the matrix below, showing
what options can go in what messages.
			<figure><artwork>
   Option / Message Type | Init | Server Response | Request | Reply |
   -----------------------------------------------------------------+
   Version (0)           | MUST |      MUST       |  MUST   | ECHO  |
   Client ID (1)         |SHOULD|      ECHO       | SHOULD  | ECHO  |
   Sequence number (2)   | NOT  |      ECHO       |  MUST   | ECHO  |
   Timestamp (3)         | NOT  |      NOT        | SHOULD  |ECHO/RQ|
   Multicast group (4)   | NOT  |      MAY        |  MUST   | ECHO  |
   Option Request (5)    | MAY  |      NOT        |  MAY    | ECHO  |
   Server Information (6)| NOT  |       RQ        |  NOT    |  NOT  |
   Reserved (7)          | NOT  |      NOT        |  NOT    |  NOT  |
   Pad (8)               | NOT  |      NOT        |  MAY    | ECHO* |
   TTL (9)               | NOT  |      NOT        |  NOT    |SHOULD |
   Multicast prefix (10) | MAY  |      MAY        |  NOT    |  NOT  |
   Session ID (11)       | NOT  |      MAY        |  ECHO   |  MAY  |
      			</artwork></figure>
NOT means that the option MUST NOT be included. ECHO for a server
means that if the option is specified by the client, then the server
MUST echo the option back in the response, with the exact same option
value. The exception is ECHO* where the option value may be modified.
ECHO for a client means that it MUST echo the option it got in the
last message from the server in the following messages it sends.
RQ means that the server SHOULD include the option in the response,
when requested by the client using the Option Request option.
</t>
		</section>
		<section title="Client Behaviour">
<t>We will consider how a typical interactive client using the
above protocol would behave. A client need only require a user to
specify the unicast address of the server. It can then send an Init
message with a prefix option containing the desired address family
and zero prefix length. The server is then free to decide which
group it should return. A client may also allow a user to specify
a group address(es) or prefix(es) (for IPv6, the user may only be
required to specify a scope or an RP address, from which the client
can construct the desired prefix, possibly embedded-RP). From this
the client can specify one or more prefix options in an Init message
to tell the server which address it would prefer. If the user
specifies a group address, that can be encoded as a prefix of
maximal length (e.g. 32 for IPv4). The prefix options are in
prioritised order, i.e., the client should put the most preferred
prefix first.
</t><t>
If the client receives a Server Response message containing a
group address it can start sending Request messages, see the next
paragraph. If there is no group address option, it would typically
exit with an error message. The server may have included some
prefix options in the Server Response. The client may use this to
provide the user some feedback on what prefixes or scopes are
available.
</t><t>
Assuming the client got a group address in a Server Response it
can start pinging. Before it does that it should let the user know
which group is being used. When sending ping Requests the client
must always specifiy the group option. If the last message from
the server contained a Session ID, then it MUST also include
that with the same value. Typically it would receive a Session ID
in a Server Response together with the group address, and then
the ID would stay the same during the entire ping sequence.
However, if for instance the server process is restarted, it may
still be possible to continue pinging but the Session ID MAY be
changed by the server. Hence a client implementation MUST always
use the last Session ID it received, and not necessarily the one
from the Server Response message. If a client receives a Server
Response message in response to a Request message (that is, a
Server Response message containing a sequence number), this means
there is an error and it should stop sending Requests.
This may for instance happen after server restart.
</t><t>
The client may have an option for the user to obtain server
information. If the user asks for server information, the client
can send an Init message with no prefix options, but with an
Option Request Option, requesting the server to return a Server
Information option. The server will return server information if
supported, and it may also return a list of prefixes it supports.
It will however not return a group address. The client may also
try to obtain only a list of prefixes by sending an Init message
with no prefixes and not requesting any specific options.
</t><t>
Note that a client may pick a multicast group and send Request
messages without first going through the Init - Server Response
negotiation. If this is supported by the server and the server
is okay with the group used, the server can then send Reply
messages as usual. If the server is not okay, it will send a
Server Response telling the client to stop and possibly pick a
new group.
</t>
		</section>
		<section title="Server Behaviour">
<t>We will consider how a typical server using the above protocol
would behave. First we consider how to respond to Init messages.
If the Init message contains prefix options, the server should
look at them in order and see if it can assign a multicast
address in the given range. The server would be configured,
possibly have a default, specifying which groups it can offer.
It may have a large pool just picking a group at random,
possibly choose a group based on hashing of the clients IP
address or identifier, or just use a fixed group. It is left to
the server to decide whether it should allow the same address to
be used simultaneously by multiple clients. If the server finds
a suitable group address, it returns this in a group option in a
Server Response message. The server may additionally include a
Session ID. This may help the server if it is to keep some state,
for instance for making sure the client uses the group it got
assigned. A good Session ID would be a random byte string that
is hard to predict. If the server cannot find a suitable group
address, or if there were no prefixes in the Init message, it
may send a Server Response message containing prefix options
listing what prefixes may be available to the client. Finally,
if the Init message requests the Server Information option, it
should include that.
</t><t>
When the server receives a Request message, it may first
check that the group address and Session ID (if provided) are
valid. If the server is satisfied it will send a unicast Reply
message back to the client, and also a multicast Reply message
to the group address. The Reply messages contain the exact
options and in the same order, as in the Request (only exception
is the pad option), and after that the server adds a TTL option
and additional options if needed. E.g., it may add a timestamp
if requested by the client. If the server is not happy with the
group address and Session ID, it may send a Server Response
message asking the client to stop. This Server Response must
echo the sequence number from the Request. This Server Response
may contain which prefixes the client can try to request
addresses from.  The unicast and multicast Reply messages have
identical UDP payload apart from possibly TTL and timestamp
option values.
<t></t>
Note that the server may receive Request messages with no
prior Init message. This may happen when the server restarts
or if a client sends a Request with no prior Init message. The
server may go ahead and respond if it is okay with the group
used. In the responses it may add a Session ID which will then
be in later requests from the client. If the group is not okay,
the server sends back a Server Response. The Response is just
as if it got an Init message with no prefixes. If the server
adds or modifies the SessionID in replies, it MUST use the
exact same SessionID in the unicast and multicast replies.
</t>
		</section>
		<section title="Acknowledgements">
<t>The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
Specific Multicast, and also the Internet Draft draft-sarac-mping-00.txt.
Mickael Hoerdt has contributed with several ideas. Alexander Gall,
Nicholas Humfrey, Nick Lamb and Dave Thaler have contributed in
different ways to the
implementation of the ssmping tools at <xref target="impl"/>.
Many people in
communities like TERENA, Internet2 and the M6Bone have used early
implementations of ssmping and provided feedback that have influenced
the current protocol. Thanks to Kevin Almeroth, Toerless Eckert,
Gorry Fairhurst, Liu Hui, Bharat Joshi, Olav Kvittem, Kamil Sarac,
Pekka Savola, Trond Skjesol and Cao Wei for reviewing and providing
feedback on this draft.</t>
		</section>
		<section title="IANA Considerations">
<t>IANA is requested to provide a UDP port number for use by this
protocol, and also provide a registry for ssmping option types.
</t>
		</section>
		<section title="Security Considerations">
<t>There are some security issues to consider. One is that a host
may send a request with an IP source address of another host,
and make an arbitrary ssmping server on the
Internet send packets to this other host. This hehaviour is fairly
harmless. The
worst case is if the host receiving the unicast replies also happen to
be performing an ssmping test towards that particular server. In this
unlikely event, there would be an amplification
effect where the host receives twice as many replies as there are
requests sent. An ssmping server should perform rate limiting, to
guard against this function being used as a DoS attack. A client should also
use the client ID option to distinguish replies to
its own requests from replies that might be to other requests.
</t>
		</section>
        </middle>
        <back>
                <references title="Normative References">
                        &rfc2119;
			<reference target="http://www.iana.org/assignments/address-family-numbers" anchor="addrfamily">
				<front>
					<title>IANA, Address Family Numbers</title>
				</front>
			</reference>
		</references>
                <references title="Informative References">
			<reference target="http://www.venaas.no/multicast/ssmping/" anchor="impl">
				<front>
					<title>ssmping implementation</title>
				</front>
			</reference>
		</references>
        </back>
</rfc>