draft-ietf-mboned-ssmping-01.txt   draft-ietf-mboned-ssmping-02.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 H. Santos
Expires: January 10, 2008 July 9, 2007 Expires: May 22, 2008 NEC Europe Ltd.
November 19, 2007
ssmping Protocol ssmping Protocol
draft-ietf-mboned-ssmping-01 draft-ietf-mboned-ssmping-02
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 34 skipping to change at page 1, line 35
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 January 10, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
ssmping is a tool that is used to check whether one can receive SSM, The ssmping protocol specified in this document allows for checking
as well as obtaining some additional information. ssmping requires whether one can receive multicast, both Source-Specific Multicast
both a client and a server supporting the ssmping protocol to work. (SSM) and Any-Source Multicast (ASM), as well as to obtain additional
We here specify this protocol. multicast related information. This protocol is based on an
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 . . . . . . . . . . . . . . . . . . . . . 5
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message types and options . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
ssmping is a tool that is designed to allow a local host to check The ssmping protocol specified in this document allows for checking
whether it is able to receive a multicast flow (SSM by default, or multicast connectivity. Not only reception of multicast (SSM or
ASM when specific options are used) originated by a remote host. ASM), but can also provide other information like multicast tree
Additionally it is able to report other information such as the setup time, the number of hops the packets have traveled, as well as
amount of time used to establish the multicast tree, the number of the packet delay and loss. This functionality resembles, in part,
hops the flow's packets have traveled as well as the packet delay and the ICMP Echo Request/Reply infrastructure, but uses UDP and requires
loss. This functionality resembles in part the ICMP Echo Request/ both a client and a server implementing this protocol.
Reply infrastructure but over UDP and implemented by both the ssmping
client and server. The protocol here specified is based on the The protocol here specified is based on the actual implementation of
actual implementation of the ssmping tool [3] which is widely used by the ssmping and asmping tools [3] which are widely used by the
the Internet community to conduct multicast connectivity tests. Internet community to conduct multicast connectivity tests.
2. Architecture 2. Architecture
Before going into the protocol details we will describe how it is Before describing the protocol in detail, we provide a brief overview
used and what information it may provide. The typical usage of an of how the protocol may be used and what information it may provide.
ssmping session is as follows. A server runs continuously in order The typical usage of an ssmping/asmping session is as follows. A
to serve request from clients. When a host decides to verify the server runs continuously to serve requests from clients. When a user
multicast reception from a specific server (knowing one of the decides to verify the multicast reception from a specific server
server's unicast addresses is required), the ssmping client joins an (knowing one of the server's unicast addresses is required), the
SSM channel (S,G) where S is a unicast address of the target server client will send a unicast message to the server asking for a group
and G is the standard multicast group defined for use by ssmping. 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.
After joining the channel, the client sends ssmping requests After joining the channel, the client unicasts ssmping requests to
encapsulated in UDP to the standardised ssmping port and the unicast the server. The requests are sent using UDP with destination port
address of the server. The requests are sent periodically, e.g. once set to the standardised ssmping port [TBD]. The requests are sent
per second, to the server. The requests contain a serial number, and periodically, e.g., once per second, to the server. The requests
typically a timestamp. The requests are typically, but not contain a sequence number, and typically a timestamp. The requests
necessarily always, simply echoed back by the server. To each are echoed back by the server, except the server may add a few
request, the server sends two replies. One as unicast back to the options. To each request, the server sends two replies. One as
port and address the request was sourced from, and also as multicast unicast back to the port and address the request was sent from, and
back to the port the request came from. It is currently left open also one as multicast back to the port from which the request
which port the request is sourced from, whether this port should be originated with the requested group G as destination address. The
standardised or not. The TTL or Hop Limit of the replies are set to server should specify the TTL used for both the unicast and multicast
64. The client should leave the SSM channel when it has finished its messages (we recommend at least 64) and includes a TTL option for the
measurements. 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 on several By use of this protocol, a client can obtain information about
aspects of the multicast quality. First of all, by receiving unicast several multicast delivery characteristics. First, by receiving
replies, it can verify that the server is receiving the unicast unicast replies, it can verify that the server is receiving the
requests, is operational and responding. Hence provided that the unicast requests, is operational and responding. Hence, provided
client receives unicast replies, a failure in receiving multicast that the client receives unicast replies, a failure to receive
indicates either a multicast problem or a multicast administrative multicast indicates either a multicast problem or a multicast
restriction. If it does receive multicast, it knows not only that it administrative restriction. If it does receive multicast, it knows
can receive; it may estimate the amount of time it took to establish not only that it can receive; it may also estimate the amount of time
the multicast tree (at least if it is in the range of seconds), it took to establish the multicast tree (at least if it is in the
whether there are packet drops, and the length and variation of round range of seconds), whether there are packet drops, and the length and
trip times (RTT). For unicast the RTT is the time from the unicast variation of Round Trip Times (RTT). For unicast, the RTT is the
request is sent to when the reply is received. The measured time from when the unicast request is sent to when the reply is
multicast RTT also references the client's unicast request. Since received. The measured multicast RTT also references the client's
the server sets TTL or Hop Limit to 64, it can also know the number unicast request. By use of the TTL option specifying the TTL of the
of router hops it is away from the source. By obtaining the same replies when they are originated, the client can also determine the
values by the unicast replies, the host may compare its multicast and number of router hops it is from the source. Since similar
unicast results and is able to check for differences in the number of information is obtained in the unicast replies, the host may compare
hops, RTT, etc. Provided that the server sends the unicast and its multicast and unicast results and is able to check for
multicast replies nearly simultaneously, it may also be able to differences in the number of hops, RTT, etc. Provided that the
measure difference in one way delay for unicast and multicast on the server sends the unicast and multicast replies nearly simultaneously,
path from server to client, and also differences in delay variation. it may also be able to measure the difference in one way delay for
Servers may optionally specify a timestamp. This may be useful since unicast and multicast on the path from server to client, and also
the unicast and multicast replies can not be sent simultaneously (the differences in delay. Servers may optionally specify a timestamp.
delay depending on the host's operating system and load), or when the This may be useful since the unicast and multicast replies can not be
client and server have synchronised clocks. sent simultaneously (the delay depending on the host's operating
system and load), or whether the client and server have synchronised
clocks.
3. Protocol specification 3. Protocol specification
The ssmping requests and replies have a common format, one octet There are four different ssmping message types. There are Echo
specifying the message type, followed by a number of options in TLV Request and Echo Reply messages used for the actual measurements;
(Type, Length and Value) format. This makes the protocol easily there is an Init message that SHOULD be used to initialise a ping
extendible. Generally the client includes a number of options in the session and negotiate which group to use; and finally a Server
request, and a server may simply echo the content back (only changing Response message that is mainly used in response to the Init message.
the message type), without inspecting the options. However, there
are a number of options that a server implementation may support,
where the client may ask for a certain information or behaviour from
the server. In some cases the server will need to add options in the
response. The response will then first contain the exact options
from the request, and then right after those, options appended by the
server.
This document defines a number of different options. Some options The ssmping messages share a common format: one octet specifying the
don't require processing by servers and are simply returned message type, followed by a number of options in TLV (Type, Length
unmodified in the reply. There are however other client options that and Value) format. This makes the protocol easily extendible. The
the server may care about, and also server options that may be Init message generally contains some prefix options asking the server
requested by a client. Generally a simple client will only include a for a group from one of the specified prefixes. The server responds
few options, and get exactly the same options and values echoed back. with a Server Response message that contains the group address to
Strictly speaking the protocol could work without any options. The use, or possibly prefix options describing what multicast groups the
protocol here defined does not require the use of any options, and a server may be able to provide. For an Echo Request the client
client may operate without specifying any. However some of the generally includes a number of options, and a server may simply echo
options allow the client to obtain additional information. 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.
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.
Unless otherwise specified, an option MUST NOT be used multiple times Unless otherwise specified, an option MUST NOT be used multiple times
in a request. Also unless otherwise specified, an option MUST NOT be in the same message.
appended by the server multiple times. Note that some options, like
timestamp, may be added by both the client and the server. In that
case the timestamp option would be in the response twice. But as
said above, it is not used multiple times in the request, and not
appended multiple times by the server.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets) specifies the option. The different options are Type (2 octets) specifies the option. The different options are
defined below. defined below.
Length (2 octets) specifies the length of the value field. Depending Length (2 octets) specifies the length of the value field. Depending
on the option type it can be from 0 to 65535. on the option type, it can be from 0 to 65535.
Value. The value must always be of the specified length. See the Value. The value must always be of the specified length. See the
respective option definitions for possible values. If the length is respective option definitions for possible values. If the length is
0, the value field is not included. 0, the value field is not included.
3.2. Defined Options 3.2. Defined Options
Client Identifier, type 1. Length MUST be non-zero. Only used by Version, type 0. Length MUST be 1. This option MUST always be
clients. A client SHOULD include this. The client may use any value included in all messages, and the value MUST be set to 2 (in
it likes to be able to detect whether a reply is a reply to this decimal). Note that there are older implementations of ssmping that
query or not. A server should treat this as opaque data, and simply only partly follow this specification. They can be regarded as
leave it unchanged in the reply. The value might be a process ID, version 1 and do not use this option.
perhaps process ID combined with an IP address because it may receive
multicasted responses to queries from other clients. It is left to
the client implementor how to make use of this.
Sequence number, type 2. Length MUST be 4. Only used by clients. A Client ID, type 1. Length MUST be non-zero. A client SHOULD always
client SHOULD include this. This contains a 32 bit sequence number. include this option in all messages (both Init and Request). The
The values would typically start at 1 and increase by one for each client may use any value it likes to be able to detect whether a
request in a sequence. 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.
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.
Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include
this. A server MAY support this. If supported it SHOULD be included this in Request messages and MUST NOT include it in Init messages. A
in the reply if requested by the client. The timestamp specifies the server replying to a request MUST copy it into the Reply. In
time when the message (query or reply) is sent. The first 4 bytes addition, a server supporting this option, SHOULD include it in Reply
specify the number of seconds since the Epoch (beginning of the year messages, if requested by the client. Note that this means that the
1970). The next 4 bytes specify the number of microseconds since the option may be present in the Reply message twice; both a client
last second since the Epoch. 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.
Multicast group, type 4. Length MUST be greater than 1. It is Multicast group, type 4. Length MUST be greater than 1. It MAY be
optional for clients and servers to support this. It allows a client used in Server Response messages to tell the client what group to use
to specify which group the server should send to. This is currently in subsequent Request messages. It MUST be used in Request messages
used by a tool called "asmping" to test ASM connectivity. The server to tell the server what group address to respond to (this group would
may have restrictions on which groups can be used. The format of the typically be previously obtained in a Server Response message). It
option value is as below. 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Multicast group address... | | Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+ .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-127 as assigned by IANA for Internet The address family is a value 0-65535 as assigned by IANA for
Address Families [2]. This is followed by the group address. For Internet Address Families [2]. This is followed by the group
IPv4 the option value length will be 5, for IPv6 17. address. For IPv4 the option value length will be 6, for IPv6 18.
Option Request Option, type 5. Length MUST be greater than 1. The Option Request Option, type 5. Length MUST be greater than 1. This
option contains a list of option types of options that the client option MAY be used in Init and Request messages. It MUST NOT be used
requests from the server. Supporting this is optional for both in any other messages, except that a server will, in a Reply, echo
clients and servers. The length of this option will be a non-zero back this option if present in the Request. This option contains a
even number, since it contains option types that each are two octets. list of option types for options that the client is requesting from
The format of the value is as below. 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
The value might contain an odd number of options, including just one.
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 version. 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.
Version, type 6. Length MUST be non-zero. Supporting this option is Server Information, type 6. Length MUST be non-zero. It MAY be used
optional. A server supporting this option SHOULD add it if and only in Server Response messages and MUST NOT be used in other messages.
if requested by the client. The value is just unformatted text that Support for this option is optional. A server supporting this option
might contain vendor and version information for the server SHOULD add it in Server Response messages if and only if requested by
implementation. It may also contain information on which options the the client. The value is a UTF-8 string that might contain vendor
server supports. 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.
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 now is deprecated. This should no implementations for an option that is now deprecated. This option
longer be used. Clients MUST not use this option, and Servers MUST should no longer be used. Clients MUST not use this option, and
ignore it. Servers MUST ignore it.
Pad, type 8. Length can be anything, including 0. This option is Pad, type 8. Length can be anything, including 0. This option is
used by clients to increase the request sizes in order to get used by clients to increase the request size in order to have the
responses of a particular size. If the server adds any options when server deliver responses of a particular size. If the server adds
responding, it should if possible make the response the same size as any options when responding, it should, if possible make the response
the request by shrinking the pad option (i.e., not simply including the same size as the request by shrinking the pad option (i.e., not
it like for other client options). If the options added by the simply including it, as is, like all other client options). If the
server consume as much space as the pad option does, or more, the options added by the server consume as much space as the pad option
server should remove the entire 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
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.
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.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for
Internet Address Families [2]. 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.
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.
4. Packet Format 4. Packet Format
The format of the ssmping messages is a one octet message type, 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 7, line 48 skipping to change at page 9, line 28
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | | Option |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two message types defined. Type 81 (the character Q in There are four message types defined. Type 81 (the character Q in
ASCII) specifies a query. Type 65 (the character A in ASCII) ASCII) specifies an Echo Request (Query). Type 65 (the character A
specifies a response (answer). 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.
The options follow right after the type octet and are not aligned in The options directly follow the type octet and are not aligned in any
any way (no spacing or padding). I.e., options might start at any way (no spacing or padding), i.e., options might start at any octet
octet boundary. The option format is specified above. boundary. The option format is specified above.
5. Acknowledgements 5. Message types and options
For the readers convenience we provide the matrix below, showing what
options can go in what messages.
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 |
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.
6. Client Behaviour
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.
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.
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.
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.
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.
7. Server Behaviour
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.
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.
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.
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 my implementation of the Thaler have contributed in different ways to the implementation of
ssmping tools [3]. Many people in communities like TERENA, Internet2 the ssmping tools at [3]. Many people in communities like TERENA,
and the M6Bone have used early implementations of ssmping and Internet2 and the M6Bone have used early implementations of ssmping
provided feedback that have influenced the current protocol. Thanks and provided feedback that have influenced the current protocol.
to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Olav Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui,
Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei for Bharat Joshi, Olav Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol
reviewing and providing feedback on this draft. and Cao Wei for reviewing and providing feedback on this draft.
6. IANA Considerations
As currently specified, ssmping would need a well known port number 9. IANA Considerations
which the servers listen to. It might be desirable to use SRV
records instead or in addition to this. For IPv6 SSM ssmping should
ideally have a reserved group ID. For the optional ASM functionality
it would be useful to have a reserved IPv6 group ID, this may be the
same as the one used for SSM. It may also be useful to have a
dedicated group for the optional IPv4 ASM functionality. This
section needs further work.
There may also be a need for an ssmping option registry. The exact IANA is requested to provide a UDP port number for use by this
IANA considerations need to be clarified before this document can go protocol, and also provide a registry for ssmping option types.
to working group last call.
7. 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 a send a request with an IP source address of another host, and make an
random ssmping server on the Internet send packets to this other arbitrary ssmping server on the Internet send packets to this other
host. This is fairly harmless. The worst case is if the host host. This hehaviour is fairly harmless. The worst case is if the
receiving the unicast replies also happen to be performing an ssmping host receiving the unicast replies also happen to be performing an
test towards that particular server. In this unlikely event there ssmping test towards that particular server. In this unlikely event,
would be an amplification effect where the host receives twice as there would be an amplification effect where the host receives twice
many replies as there are requests sent. An ssmping server should as many replies as there are requests sent. An ssmping server should
perform rate limiting, to guard against this being used as a DoS perform rate limiting, to guard against this function being used as a
attack. A client should also use the client identifier option to be DoS attack. A client should also use the client ID option to
able to distinguish replies to its own requests from replies that distinguish replies to its own requests from replies that might be to
might be to other requests. How the protocol should be designed to other requests.
cope with rate limiting at the server requires further study. One
possibility might be that the server can choose to send generic
replies, e.g. a packet every second without the usual client options
but including sequence number and server time stamp, and where
clients do not send requests as long as they receive generic replies.
8. References 11. References
8.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] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
8.2. Informative References 11.2. Informative References
[3] "ssmping implementation", [3] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
Authors' Addresses Authors' Addresses
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO-7465 Trondheim NO-7465
Norway Norway
Email: venaas@uninett.no Email: venaas@uninett.no
Hugo Santos Hugo Santos
Urb Glicinias, Smart Residence, 211 NEC Europe Ltd.
Aveiro 3810 Kurfuersten-Anlage 36
Portugal Heidelberg 69115
Germany
Email: hugo@fivebits.net Email: hugo.santos@nw.neclab.eu
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
 End of changes. 39 change blocks. 
207 lines changed or deleted 411 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/