draft-ietf-mboned-ssmping-02.txt   draft-ietf-mboned-ssmping-03.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Informational H. Santos Intended status: Informational February 12, 2008
Expires: May 22, 2008 NEC Europe Ltd. Expires: August 15, 2008
November 19, 2007
ssmping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-02 draft-ietf-mboned-ssmping-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The ssmping protocol specified in this document allows for checking The Multicast Ping Protocol specified in this document allows for
whether one can receive multicast, both Source-Specific Multicast checking whether an endpoint can receive multicast, both Source-
(SSM) and Any-Source Multicast (ASM), as well as to obtain additional Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
multicast related information. This protocol is based on an be used to obtain additional multicast related information like
multicast tree setup time etc. This protocol is based on an
implementation of tools called ssmping and asmping. implementation of tools called ssmping and asmping.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Message types and options . . . . . . . . . . . . . . . . . . 9 5. Message types and options . . . . . . . . . . . . . . . . . . 10
6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10
7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The ssmping protocol specified in this document allows for checking The Multicast Ping Protocol specified in this document allows for
multicast connectivity. Not only reception of multicast (SSM or checking multicast connectivity. In addition to checking reception
ASM), but can also provide other information like multicast tree of multicast (SSM or ASM), the protocol can provide related
setup time, the number of hops the packets have traveled, as well as information like multicast tree setup time, the number of hops the
the packet delay and loss. This functionality resembles, in part, packets have traveled, as well as packet delay and loss. This
the ICMP Echo Request/Reply infrastructure, but uses UDP and requires functionality resembles, in part, the ICMP Echo Request/Reply
mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires
both a client and a server implementing this protocol. both a client and a server implementing this protocol.
The protocol here specified is based on the actual implementation of The protocol here specified is based on the actual implementation of
the ssmping and asmping tools [3] which are widely used by the the ssmping and asmping tools [5] which are widely used by the
Internet community to conduct multicast connectivity tests. Internet community to conduct multicast connectivity tests.
2. Architecture 2. Architecture
Before describing the protocol in detail, we provide a brief overview Before describing the protocol in detail, we provide a brief overview
of how the protocol may be used and what information it may provide. 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 The typical protocol usage is as follows: A server runs continuously
server runs continuously to serve requests from clients. When a user to serve requests from clients. A client can test the multicast
decides to verify the multicast reception from a specific server reception from this server, provided it knows a unicast address of
(knowing one of the server's unicast addresses is required), the the server. It will then send a unicast message to the server asking
client will send a unicast message to the server asking for a group for a group to use. Optionally the user may have requested a
to use. Optionally the user may have requested a specific group or specific group or scope, in which case the client will ask for a
scope, in which case the client will ask for a group matching the group matching the user's request. The server will respond with a
user's request. The server will respond with a group to use, or an group to use, or an error if no group is available. Next, for ASM,
error if no group is available. Next, the client joins an SSM the client joins an ASM group G, while for SSM it joins a channel
channel (S,G) where S is a unicast address of the target server, or (S,G). Here G is the group specified by the server, and S is the
an ASM group G, where G is the group specified by the server. unicast address used to reach the server.
After joining the channel, the client unicasts ssmping requests to After joining the channel, the client unicasts multicast ping
the server. The requests are sent using UDP with destination port requests to the server. The requests are sent using UDP with
set to the standardised ssmping port [TBD]. The requests are sent destination port set to the standardised multicast ping port [TBD].
periodically, e.g., once per second, to the server. The requests The requests are sent periodically, e.g., once per second, to the
contain a sequence number, and typically a timestamp. The requests server. The requests contain a sequence number, and typically a
are echoed back by the server, except the server may add a few timestamp. The requests are echoed back by the server, except the
options. To each request, the server sends two replies. One as server may add a few options. For each request, the server sends two
unicast back to the port and address the request was sent from, and replies. One reply is unicast to the source IP address and source
also one as multicast back to the port from which the request UDP port of the request, while another is multicast back to requested
originated with the requested group G as destination address. The multicast group G and the source UDP port of the request. Both the
server should specify the TTL used for both the unicast and multicast replies are sent from the same port from which the request was
messages (we recommend at least 64) and includes a TTL option for the received. The server should specify the TTL used for both the
client to compute the number of hops. The client should leave the unicast and multicast messages (we recommend at least 64) and
channel/group when it has finished its measurements. 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.
By use of this protocol, a client can obtain information about By use of this protocol, a client can obtain information about
several multicast delivery characteristics. First, by receiving several multicast delivery characteristics. First, by receiving
unicast replies, it can verify that the server is receiving the unicast replies, it can verify that the server is receiving the
unicast requests, is operational and responding. Hence, provided unicast requests, is operational and responding. Hence, provided
that the client receives unicast replies, a failure to receive that the client receives unicast replies, a failure to receive
multicast indicates either a multicast problem or a multicast multicast indicates either a multicast problem or a multicast
administrative restriction. If it does receive multicast, it knows administrative restriction. If it does receive multicast, it knows
not only that it can receive; it may also estimate the amount of time 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 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 range of seconds), whether there are packet drops, and the length and
variation of Round Trip Times (RTT). For unicast, the RTT is the 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 time from when the unicast request is sent to when the reply is
received. The measured multicast RTT also references the client's received. The measured multicast RTT also references the client's
unicast request. By use of the TTL option specifying the TTL of the unicast request. By use of the TTL option specifying the TTL of the
replies when they are originated, the client can also determine the replies when they are originated, the client can also determine the
number of router hops it is from the source. Since similar number of router hops it is from the source. Since similar
information is obtained in the unicast replies, the host may compare information is obtained in the unicast replies, the host may compare
its multicast and unicast results and is able to check for its multicast and unicast results and is able to check for
differences in the number of hops, RTT, etc. Provided that the differences in the number of hops, RTT, etc. The number of multicast
server sends the unicast and multicast replies nearly simultaneously, hops and changes in the number of hops over time, may also reveal
it may also be able to measure the difference in one way delay for details about the multicast tree and multicast tree changes. E.g.,
unicast and multicast on the path from server to client, and also with PIM-SM one may be able to tell whether the forwarding is on a
differences in delay. Servers may optionally specify a timestamp. shared or source-specific tree and when an eventual switch occurs.
This may be useful since the unicast and multicast replies can not be Provided that the server sends the unicast and multicast replies
sent simultaneously (the delay depending on the host's operating nearly simultaneously, the client may also be able to measure the
system and load), or whether the client and server have synchronised difference in one way delay for unicast and multicast on the path
clocks. 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).
3. Protocol specification 3. Protocol specification
There are four different ssmping message types. There are Echo There are four different message types. There are Echo Request and
Request and Echo Reply messages used for the actual measurements; Echo Reply messages used for the actual measurements; there is an
there is an Init message that SHOULD be used to initialise a ping Init message that SHOULD be used to initialise a ping session and
session and negotiate which group to use; and finally a Server negotiate which group to use; and finally a Server Response message
Response message that is mainly used in response to the Init message. that is mainly used in response to the Init message. The messages
MUST always be in network byte order. UDP checksums MUST always be
used.
The ssmping messages share a common format: one octet specifying the The messages share a common format: one octet specifying the message
message type, followed by a number of options in TLV (Type, Length type, followed by a number of options in TLV (Type, Length and Value)
and Value) format. This makes the protocol easily extendible. The format. This makes the protocol easily extendible. The Init message
Init message generally contains some prefix options asking the server generally contains some prefix options asking the server for a group
for a group from one of the specified prefixes. The server responds from one of the specified prefixes. The server responds with a
with a Server Response message that contains the group address to Server Response message that contains the group address to use, or
use, or possibly prefix options describing what multicast groups the possibly prefix options describing what multicast groups the server
server may be able to provide. For an Echo Request the client may be able to provide. For an Echo Request the client generally
generally includes a number of options, and a server may simply echo includes a number of options, and a server may simply echo the
the content back (only changing the message type), without inspecting content back (only changing the message type), without inspecting the
the options. However, the server SHOULD add a TTL option, and there options. However, the server SHOULD add a TTL option, and there are
are some other options that a server implementation MAY support, other options that a server implementation MAY support, e.g., the
e.g., the client may ask for certain information or a specific client may ask for certain information or a specific behaviour from
behaviour from the server. The Echo Replies (one unicast and one the server. The Echo Replies (one unicast and one multicast) MUST
multicast) MUST first contain the exact options from the request (in first contain the exact options from the request (in the same order),
the same order), and then, immediately following, options appended by and then, immediately following, any options appended by the server.
the server. A server MUST NOT process unknown options, but they MUST still be
included in the Echo Reply. A client MUST ignore any unknown
options.
This document defines a number of different options. Some options do This document defines a number of different options. Some options do
not require processing by servers and are simply returned unmodified not require processing by servers and are simply returned unmodified
in the reply. There are, however, other client options that the in the reply. There are, however, other client options that the
server may care about, and also server options that may be requested server may care about, and also server options that may be requested
by a client. by a client. Unless otherwise specified, an option MUST NOT be used
multiple times in the same message.
Unless otherwise specified, an option MUST NOT be used multiple times
in the same message.
3.1. Option format 3.1. Option format
All options are TLVs formatted as specified below. All options are TLVs formatted as specified below.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 6 skipping to change at page 6, line 16
Version, type 0. Length MUST be 1. This option MUST always be 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 included in all messages, and the value MUST be set to 2 (in
decimal). Note that there are older implementations of ssmping that decimal). Note that there are older implementations of ssmping that
only partly follow this specification. They can be regarded as only partly follow this specification. They can be regarded as
version 1 and do not use this option. version 1 and do not use this option.
Client ID, type 1. Length MUST be non-zero. A client SHOULD always Client ID, type 1. Length MUST be non-zero. A client SHOULD always
include this option in all messages (both Init and Request). The 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 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 reply is a reply to its Init/Request or not. A server should treat
this as opaque data, and simply leave it unchanged in the reply (both 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 Server Response and Reply). The value might be a process ID, perhaps
process ID combined with an IP address because it may receive process ID combined with an IP address because it may receive
multicast responses to queries from other clients. It is left to the multicast responses to queries from other clients. It is left to the
client implementor how to make use of this option. client implementor how to make use of this option.
Sequence number, type 2. Length MUST be 4. A client MUST always Sequence number, type 2. Length MUST be 4. A client MUST always
include this in Request messages and MUST NOT include it in Init include this in Request messages and MUST NOT include it in Init
messages. A server replying to a Request message MUST copy it into messages. A server replying to a Request message MUST copy it into
the Reply (or Server Response message on error). This contains a 32 the Reply (or Server Response message on error). This contains a 32
bit sequence number. The values would typically start at 1 and bit sequence number. The values would typically start at 1 and
increase by one for each request in a sequence. increase by one for each request in a sequence.
Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include Client Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD
this in Request messages and MUST NOT include it in Init messages. A include this in Request messages and MUST NOT include it in Init
server replying to a request MUST copy it into the Reply. In messages. A server replying to a Request message MUST copy it into
addition, a server supporting this option, SHOULD include it in Reply the Reply. The timestamp specifies the time when the Request message
messages, if requested by the client. Note that this means that the is sent. The first 4 bytes specify the number of seconds since the
option may be present in the Reply message twice; both a client Epoch (beginning of the year 1970). The next 4 bytes specify the
timestamp as part of the echoed Request, and another timestamp added number of microseconds since the last second since the Epoch.
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.
Multicast group, type 4. Length MUST be greater than 1. It MAY be 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 used in Server Response messages to tell the client what group to use
in subsequent Request messages. It MUST be used in Request messages in subsequent Request messages. It MUST be used in Request messages
to tell the server what group address to respond to (this group would to tell the server what group address to respond to (this group would
typically be previously obtained in a Server Response message). It typically be previously obtained in a Server Response message). It
MUST be used in Reply messages (copied from the Request 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 MUST NOT be used in Init messages. The format of the option value is
as below. as below.
skipping to change at page 6, line 47 skipping to change at page 7, line 4
typically be previously obtained in a Server Response message). It typically be previously obtained in a Server Response message). It
MUST be used in Reply messages (copied from the Request 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 MUST NOT be used in Init messages. The format of the option value is
as below. as below.
0 1 2 3 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 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... | | Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for The address family is a value 0-65535 as assigned by IANA for
Internet Address Families [2]. This is followed by the group Internet Address Families [4]. This is followed by the group
address. For IPv4 the option value length will be 6, for IPv6 18. address. Length of the option value will be 6 for IPv4, and 18 for
IPv6.
Option Request Option, type 5. Length MUST be greater than 1. This 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 option MAY be used in client messages (Init and Request messages). A
in any other messages, except that a server will, in a Reply, echo server MUST NOT send this option, except that if it is present in a
back this option if present in the Request. This option contains a Request message, the server MUST include it in a reply (Reply
list of option types for options that the client is requesting from message) to the Request. This option contains a list of option types
the server. Support for this option is optional for both clients and for options that the client is requesting from the server. Support
servers. The length of this option will be a non-zero even number, for this option is optional for both clients and servers. The length
since it contains one or more option types that are two octets each. of this option will be a non-zero even number, since it contains one
The format of the option value is as below. or more option types that are two octets each. The format of the
option value is as below.
0 1 2 3 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 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 | | Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
This option might be used by the client to ask the server to include This option might be used by the client to ask the server to include
options like Timestamp or Server Information. A client MAY request options like Timestamp or Server Information. A client MAY request
skipping to change at page 7, line 40 skipping to change at page 7, line 45
Support for this option is optional. A server supporting this option Support for this option is optional. A server supporting this option
SHOULD add it in Server Response messages if and only if requested by 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 the client. The value is a UTF-8 string that might contain vendor
and version information for the server implementation. It may also and version information for the server implementation. It may also
contain information on which options the server supports. An contain information on which options the server supports. An
interactive client MAY support this option, and SHOULD then allow a interactive client MAY support this option, and SHOULD then allow a
user to request this string and display it. user to request this string and display it.
Type 7, Reserved. This option code value was used by early Type 7, Reserved. This option code value was used by early
implementations for an option that is now deprecated. This option implementations for an option that is now deprecated. This option
should no longer be used. Clients MUST not use this option, and should no longer be used. Clients MUST not use this option. Servers
Servers MUST ignore it. MUST treat it as an unknown option (not process it if received, but
if received in a Request message, it MUST be echoed back in the Reply
message).
Pad, type 8. Length can be anything, including 0. This option is Type 8, Reserved. This option code value was used by early
used by clients to increase the request size in order to have the implementations for an option that is now deprecated. This option
server deliver responses of a particular size. If the server adds should no longer be used. Clients MUST not use this option. Servers
any options when responding, it should, if possible make the response MUST treat it as an unknown option (not process it if received, but
the same size as the request by shrinking the pad option (i.e., not if received in a Request message, it MUST be echoed back in the Reply
simply including it, as is, like all other client options). If the message).
options added by the server consume as much space as the pad option
does, or more, the server should remove the entire pad option.
TTL, type 9. Length MUST be 1. This option contains a single octet 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 specifying the TTL of a Reply message. Every time a server sends a
unicast or multicast Reply message, it SHOULD include this option unicast or multicast Reply message, it SHOULD include this option
specifying the TTL. This is used by clients to determine the number 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 of hops the messages have traversed. It MUST NOT be used in other
messages. Although this option is not absolutely required, the messages. A server SHOULD specify this option if it knows what the
server is expected to use it if it knows what the TTL of the Reply TTL of the Reply will be. In general the server can specify a
will be. In general the server can specify a specific TTL to the specific TTL to the host stack. Note that the TTL is not necessarily
host stack. the same for unicast and multicast.
Multicast prefix, type 10. Length MUST be greater than 2. It MAY be 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 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 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 prefix(es) it may try to obtain a group from. It MUST NOT be used in
Request/Reply messages. Request/Reply messages. Note that this option MAY be included
multiple times to specify multiple prefixes.
0 1 2 3 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 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| | Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for The address family is a value 0-65535 as assigned by IANA for
Internet Address Families [2]. This is followed by a prefix length Internet Address Families [4]. This is followed by a prefix length
(0-32 for IPv4, 0-128 for IPv6), and finally a group address. The (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 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 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 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 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 ignored. For IPv4 the option value length will be 3-7, while for
IPv6 3-19. IPv6 3-19.
Session ID, type 11. Length MUST be non-zero. A server MAY include 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 in Server Response and Reply messages. If a client receives
this option in a message, the client MUST echo the Session ID option 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 in subsequent Reply messages, with the exact same value, until the
is received from the server. If the next message from the server has next message is received from the server. If the next message from
no Session ID or a new Session ID value, the client should do the the server has no Session ID or a new Session ID value, the client
same, either not use the Session ID, or use the new value. should do the same, either not use the Session ID, or use the new
value. The Session ID may help the server in keeping track of
clients and possibly manage client state. It is left to the server
implementer to decide whether it is useful and how to make use of it.
Server Timestamp, type 12. Length MUST be 8 bytes. A server
supporting this option, SHOULD include it in Reply messages, if
requested by the client. The timestamp specifies the time when the
Reply message 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.
4. Packet Format 4. Packet Format
The format of all messages is a one octet message type, directly The format of all messages is a one octet message type, directly
followed by a variable number of options. followed by a variable number of options.
0 1 2 3 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 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 | | Type | Option |
skipping to change at page 10, line 7 skipping to change at page 10, line 13
way (no spacing or padding), i.e., options might start at any octet way (no spacing or padding), i.e., options might start at any octet
boundary. The option format is specified above. boundary. The option format is specified above.
5. Message types and options 5. Message types and options
For the readers convenience we provide the matrix below, showing what For the readers convenience we provide the matrix below, showing what
options can go in what messages. options can go in what messages.
Option / Message Type | Init | Server Response | Request | Reply | Option / Message Type | Init | Server Response | Request | Reply |
-----------------------------------------------------------------+ -----------------------------------------------------------------+
Version (0) | MUST | MUST | MUST | ECHO | Version (0) | MUST | ECHO | MUST | ECHO |
Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | Client ID (1) |SHOULD| ECHO | SHOULD | ECHO |
Sequence number (2) | NOT | ECHO | MUST | ECHO | Sequence number (2) | NOT | ECHO | MUST | ECHO |
Timestamp (3) | NOT | NOT | SHOULD |ECHO/RQ| Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast group (4) | NOT | MAY | MUST | ECHO | Multicast group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO | Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6)| NOT | RQ | NOT | NOT | Server Information (6)| NOT | RQ | NOT | NOT |
Reserved (7) | NOT | NOT | NOT | NOT | Reserved (7) | NOT | NOT | NOT | ECHO |
Pad (8) | NOT | NOT | MAY | ECHO* | Reserved (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT |SHOULD | TTL (9) | NOT | NOT | NOT |SHOULD |
Multicast prefix (10) | MAY | MAY | NOT | NOT | Multicast prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | MAY | ECHO | MAY | Session ID (11) | NOT | MAY | ECHO | MAY |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
NOT means that the option MUST NOT be included. ECHO for a server 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 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 MUST echo the option back in the response, with the exact same option
value. The exception is ECHO* where the option value may be value. ECHO for a client means that it MUST echo the option it got
modified. ECHO for a client means that it MUST echo the option it in the last message from the server in any subsequent messages 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 sends. RQ means that the server SHOULD include the option in the
response, when requested by the client using the Option Request response, when requested by the client using the Option Request
option. option.
6. Client Behaviour 6. Client Behaviour
We will consider how a typical interactive client using the above We will consider how a typical interactive client using the above
protocol would behave. A client need only require a user to specify 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 the unicast address of the server. It can then send an Init message
with a prefix option containing the desired address family and zero with a prefix option containing the desired address family and zero
skipping to change at page 11, line 8 skipping to change at page 11, line 16
If the client receives a Server Response message containing a group If the client receives a Server Response message containing a group
address it can start sending Request messages, see the next address it can start sending Request messages, see the next
paragraph. If there is no group address option, it would typically paragraph. If there is no group address option, it would typically
exit with an error message. The server may have included some prefix exit with an error message. The server may have included some prefix
options in the Server Response. The client may use this to provide options in the Server Response. The client may use this to provide
the user some feedback on what prefixes or scopes are available. the user some feedback on what prefixes or scopes are available.
Assuming the client got a group address in a Server Response it can 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 start pinging. Before it does that it should let the user know which
group is being used. When sending ping Requests the client must group is being used. Normally, a client should send at most one ping
request per second. When sending ping Requests the client must
always specifiy the group option. If the last message from the always specifiy the group option. If the last message from the
server contained a Session ID, then it MUST also include that with 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 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 Response together with the group address, and then the ID would stay
the same during the entire ping sequence. However, if for instance the same during the entire ping sequence. However, if for instance
the server process is restarted, it may still be possible to continue 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 pinging but the Session ID may be changed by the server. Hence a
client implementation MUST always use the last Session ID it client implementation must always use the last Session ID it
received, and not necessarily the one from the Server Response received, and not necessarily the one from the Server Response
message. If a client receives a Server Response message in response message. If a client receives a Server Response message in response
to a Request message (that is, a Server Response message containing a to a Request message (that is, a Server Response message containing a
sequence number), this means there is an error and it should stop sequence number), this means there is an error and it should stop
sending Requests. This may for instance happen after server restart. sending Requests. This may for instance happen after server restart.
The client may have an option for the user to obtain server The client may have an option for the user to obtain server
information. If the user asks for server information, the client can information. If the user asks for server information, the client can
send an Init message with no prefix options, but with an Option send an Init message with no prefix options, but with an Option
Request Option, requesting the server to return a Server Information Request Option, requesting the server to return a Server Information
skipping to change at page 12, line 22 skipping to change at page 12, line 34
Server Response message containing prefix options listing what Server Response message containing prefix options listing what
prefixes may be available to the client. Finally, if the Init prefixes may be available to the client. Finally, if the Init
message requests the Server Information option, it should include message requests the Server Information option, it should include
that. that.
When the server receives a Request message, it may first check that When the server receives a Request message, it may first check that
the group address and Session ID (if provided) are valid. If the 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 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 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 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 the Request, and after that the server adds a TTL option and
server adds a TTL option and additional options if needed. E.g., it additional options if needed. E.g., it may add a timestamp if
may add a timestamp if requested by the client. If the server is not requested by the client. If the server is not happy with the Request
happy with the group address and Session ID, it may send a Server (bad group address or Session ID, request is too large etc), it may
Response message asking the client to stop. This Server Response send a Server Response message asking the client to stop. This
must echo the sequence number from the Request. This Server Response Server Response must echo the sequence number from the Request. This
may contain which prefixes the client can try to request addresses Server Response may contain which prefixes the client can try to
from. The unicast and multicast Reply messages have identical UDP request addresses from. The unicast and multicast Reply messages
payload apart from possibly TTL and timestamp option values. have identical UDP payload apart from possibly TTL and timestamp
option values.
Note that the server may receive Request messages with no prior Init Note that the server may receive Request messages with no prior Init
message. This may happen when the server restarts or if a client 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 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 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 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 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 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, prefixes. If the server adds or modifies the SessionID in replies,
it MUST use the exact same SessionID in the unicast and multicast it must use the exact same SessionID in the unicast and multicast
replies. replies.
By default a server should perform rate limiting and for a given
client, respond to at most one Request message per second. A leaky
bucket algorithm is suggested, where the rate can be higher for a few
seconds, but the average rate should by default be limited to a
message per client per second.
8. Acknowledgements 8. Acknowledgements
The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
Specific Multicast, and also the Internet Draft Specific Multicast, and also the Internet Draft
draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with
several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave
Thaler have contributed in different ways to the implementation of Thaler have contributed in different ways to the implementation of
the ssmping tools at [3]. Many people in communities like TERENA, the ssmping tools at [5]. Many people in communities like TERENA,
Internet2 and the M6Bone have used early implementations of ssmping Internet2 and the M6Bone have used early implementations of ssmping
and provided feedback that have influenced the current protocol. and provided feedback that have influenced the current protocol.
Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui,
Bharat Joshi, Olav Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola,
and Cao Wei for reviewing and providing feedback on this draft. Trond Skjesol and Cao Wei for reviewing and providing feedback on
this draft. In particular Hugo, Gorry and Bharat have provided lots
of input on several revisions of the draft
9. IANA Considerations 9. IANA Considerations
IANA is requested to provide a UDP port number for use by this IANA is requested to provide a UDP port number for use by this
protocol, and also provide a registry for ssmping option types. protocol, and also to provide registries for message and option
types.
There should be a message types registry. Message types are in the
range 0-255. Message types 0-191 can be assigned referencing an RFC
(it may be Informational), while types 192-255 are freely available
for experimental, private or vendor specifc use.
There should also be an option type registry. Option types 0-49151
can be assigned referencing an RFC (it may be Informational), while
types 49152-65535 are freely available for experimental, private or
vendor specifc use.
10. Security Considerations 10. Security Considerations
There are some security issues to consider. One is that a host may 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 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 arbitrary multicast ping server on the Internet send packets to this
host. This hehaviour is fairly harmless. The worst case is if the other host. This behaviour is fairly harmless. The worst case is if
host receiving the unicast replies also happen to be performing an the host receiving the unicast replies also happen to be joined to
ssmping test towards that particular server. In this unlikely event, the multicast group used. In this case, there would be an
there would be an amplification effect where the host receives twice amplification effect where the host receives twice as many replies as
as many replies as there are requests sent. An ssmping server should there are requests sent.
perform rate limiting, to guard against this function being used as a
DoS attack. A client should also use the client ID option to Servers should perform rate limiting, to guard against this function
distinguish replies to its own requests from replies that might be to being used as a DoS attack. By default, clients should send at most
other requests. one request per second, and servers should perform rate limiting if a
client sends more frequent requests. Server implementations should
provide administrative control of which client IP addresses to serve,
and may also allow certain clients to perform more rapid requests.
Implementors of applications/tools using this protocol should
consider the UDP guidelines [6], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per
second.
A client should use the client ID option to distinguish replies to
its own requests from replies that might be to other requests.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] "IANA, Address Family Numbers", [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
11.2. Informative References 11.2. Informative References
[3] "ssmping implementation", [5] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
Authors' Addresses [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work
in progress), February 2008.
Author's Address
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO-7465 Trondheim NO-7465
Norway Norway
Email: venaas@uninett.no Email: venaas@uninett.no
Hugo Santos
NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Email: hugo.santos@nw.neclab.eu
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 47 change blocks. 
179 lines changed or deleted 228 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/