draft-ietf-mboned-ssmping-00.txt   draft-ietf-mboned-ssmping-01.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Informational May 22, 2007 Intended status: Informational H. Santos
Expires: November 23, 2007 Expires: January 10, 2008 July 9, 2007
ssmping Protocol ssmping Protocol
draft-ietf-mboned-ssmping-00 draft-ietf-mboned-ssmping-01
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 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 November 23, 2007. This Internet-Draft will expire on January 10, 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, ssmping is a tool that is used to check whether one can receive SSM,
as well as obtaining some additional information. ssmping requires as well as obtaining some additional information. ssmping requires
both a client and a server supporting the ssmping protocol to work. both a client and a server supporting the ssmping protocol to work.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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. Protocol description . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
ssmping is a tool that is used to check whether one can receive SSM, ssmping is a tool that is designed to allow a local host to check
and it can also give other information like the time to establish the whether it is able to receive a multicast flow (SSM by default, or
tree, number of router hops the packets have traveled, packet delay ASM when specific options are used) originated by a remote host.
and loss. The ssmping functionality resembles ICMP echo request/ Additionally it is able to report other information such as the
reply using UDP and a client and a server that supports the ssmping amount of time used to establish the multicast tree, the number of
protocol. It is used by a client to verify that it can receive hops the flow's packets have traveled as well as the packet delay and
multicast from the server, as well as some additional information. loss. This functionality resembles in part the ICMP Echo Request/
The protocol as specified here is based on an actual implementation Reply infrastructure but over UDP and implemented by both the ssmping
of a tool [3] that has been found useful by many organisations. client and server. The protocol here specified is based on the
actual implementation of the ssmping tool [3] which is widely used by
the Internet community to conduct multicast connectivity tests.
2. Protocol description 2. Architecture
Before going into the protocol details we will describe how it is Before going into the protocol details we will describe how it is
used and what information it may provide. The typical usage is as used and what information it may provide. The typical usage of an
follows. A server runs continuously in order to serve request from ssmping session is as follows. A server runs continuously in order
clients. At some point a client application may try to verify to serve request from clients. When a host decides to verify the
multicast reception from such a server. The client will need to know multicast reception from a specific server (knowing one of the
a unicast address of a server. The client joins an SSM channel (S,G) server's unicast addresses is required), the ssmping client joins an
where S is a unicast address of the server, and G is a standardised SSM channel (S,G) where S is a unicast address of the target server
multicast group for use by ssmping. After joining the channel, the and G is the standard multicast group defined for use by ssmping.
client sends ssmping requests as UDP to a standardised ssmping port
and the unicast address of the server. The requests are sent After joining the channel, the client sends ssmping requests
periodically, e.g. once per second, to the server. The requests encapsulated in UDP to the standardised ssmping port and the unicast
contain a serial number, and typically a timestamp. The requests are address of the server. The requests are sent periodically, e.g. once
typically, but not necessarily always, simply echoed back by the per second, to the server. The requests contain a serial number, and
server. To each request, the server sends two replies. One as typically a timestamp. The requests are typically, but not
unicast back to the port and address the request was sourced from, necessarily always, simply echoed back by the server. To each
and also as multicast back to the port the request came from. It is request, the server sends two replies. One as unicast back to the
currently left open which port the request is sourced from, whether port and address the request was sourced from, and also as multicast
this port should be standardised or not. The TTL or Hop Limit of the back to the port the request came from. It is currently left open
replies are set to 64. The client should leave the SSM channel when which port the request is sourced from, whether this port should be
it has finished its measurements. standardised or not. The TTL or Hop Limit of the replies are set to
64. The client should leave the SSM channel 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 on several
aspects of the multicast quality. First of all, by receiving unicast aspects of the multicast quality. First of all, 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 that the requests, is operational and responding. Hence provided that the
client receives unicast replies, a failure in receiving multicast is client receives unicast replies, a failure in receiving multicast
indeed caused by a multicast problem. If it does receive multicast, indicates either a multicast problem or a multicast administrative
it knows not only that it can receive, but it may get some restriction. If it does receive multicast, it knows not only that it
information on how long it takes to establish the multicast tree (at can receive; it may estimate the amount of time it took to establish
least if it is in the range of seconds), whether there are packet the multicast tree (at least if it is in the range of seconds),
drops, and the length and variation of round trip times (RTT). For whether there are packet drops, and the length and variation of round
unicast the RTT is the time from unicast request is sent to when the trip times (RTT). For unicast the RTT is the time from the unicast
reply is received. For multicast we also talk about RTT, but then we request is sent to when the reply is received. The measured
mean from the unicast request is sent to when the multicast reply is multicast RTT also references the client's unicast request. Since
received. Since the server sets TTL or Hop Limit to 64, it can also the server sets TTL or Hop Limit to 64, it can also know the number
know the number of router hops it is away from the source. By of router hops it is away from the source. By obtaining the same
comparing with the unicast replies, it can see whether there are values by the unicast replies, the host may compare its multicast and
differences in RTT and number of hops etc for unicast and multicast. unicast results and is able to check for differences in the number of
Provided that the server sends the unicast and multicast replies hops, RTT, etc. Provided that the server sends the unicast and
nearly simultaneously, it may also be able to measure difference in multicast replies nearly simultaneously, it may also be able to
one way delay for unicast and multicast on the path from server to measure difference in one way delay for unicast and multicast on the
client, and also if there are differences in delay variation. path from server to client, and also differences in delay variation.
Servers may optionally specify a timestamp. This may be useful if Servers may optionally specify a timestamp. This may be useful since
the unicast and multicast replies can not be sent nearly the unicast and multicast replies can not be sent simultaneously (the
simultaneously, or if the client and server have synchronised clocks. delay depending on the host's operating system and load), or when the
client and server have synchronised clocks.
3. Protocol specification
The ssmping requests and replies have a common format, one octet The ssmping requests and replies have a common format, one octet
specifying the message type, followed by a number of options in TLV specifying the message type, followed by a number of options in TLV
(Type, Length and Value) format. This makes the protocol easily (Type, Length and Value) format. This makes the protocol easily
extendible. Generally the client includes a number of options in the extendible. Generally the client includes a number of options in the
request, and a server may simply echo the content back (only changing request, and a server may simply echo the content back (only changing
the message type), without inspecting the options. However, there the message type), without inspecting the options. However, there
are a number of options that a server implementation may support, are a number of options that a server implementation may support,
where the client may ask for a certain information or behaviour from 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 the server. In some cases the server will need to add options in the
response. The response will then first contain the exact options response. The response will then first contain the exact options
from the request, and then right after those, options appended by the from the request, and then right after those, options appended by the
server. server.
3. Options This document defines a number of different options. Some options
don't 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. Generally a simple client will only include a
few options, and get exactly the same options and values echoed back.
Strictly speaking the protocol could work without any options. The
protocol here defined does not require the use of any options, and a
client may operate without specifying any. However some of the
options allow the client to obtain additional information.
There are a number of different options. Most of the options are Unless otherwise specified, an option MUST NOT be used multiple times
only used by clients and simply echoed back by the server, where the in a request. Also unless otherwise specified, an option MUST NOT be
server doesn't care about their contents. There are however some appended by the server multiple times. Note that some options, like
client options that the server may care about. There are also server timestamp, may be added by both the client and the server. In that
options that may be requested by the client. Generally a simple case the timestamp option would be in the response twice. But as
client will only include a few options, and get exactly the same said above, it is not used multiple times in the request, and not
options and values echoed back. Strictly speaking the protocol could appended multiple times by the server.
work without any options. Without sending any options a client would
still be able to tell whether multicast is working or not, however
with the use of some of the basic options a client can obtain a lot
more information.
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. Depending on Length (2 octets) specifies the length of the value field. Depending
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 Client Identifier, type 1. Length MUST be non-zero. Only used by
clients. A client SHOULD include this. The client may use any value clients. A client SHOULD include this. The client may use any value
it likes to be able to detect whether a reply is a reply to this it likes to be able to detect whether a reply is a reply to this
skipping to change at page 6, line 43 skipping to change at page 7, line 6
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 version.
Version, type 6. Length MUST be non-zero. Supporting this option is Version, type 6. Length MUST be non-zero. Supporting this option is
optional. A server supporting this option SHOULD add it if and only optional. A server supporting this option SHOULD add it if and only
if requested by the client. The value is just unformatted text that if requested by the client. The value is just unformatted text that
might contain vendor and version information for the server might contain vendor and version information for the server
implementation. It may also contain information on which options the implementation. It may also contain information on which options the
server supports. server supports.
Reply size, type 7. Length MUST be 2 octets. This option is Type 7, Reserved. This option code value was used by early
optional for clients and servers. It can be used to request the implementations for an option that now is deprecated. This should no
server response to be of a certain size. The value specifies the longer be used. Clients MUST not use this option, and Servers MUST
desired response size in octets. A server supporting this will if ignore it.
necessary use the pad option to increase the size of the response. A
server should however not try to make the response shorter due to
this option. That is, it should not omit or shorten any option
values to try to accommodate this. The response should never be
shorter than if this option were not included. Also, the pad option
requires at least 3 octets, so the server will not pad the response
size if the requested size is not at least 3 octets longer than the
normal response size.
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 servers to increase the response size if the client asks for used by clients to increase the request sizes in order to get
a reply that is larger than what the server normally would send. The responses of a particular size. If the server adds any options when
addition of this option consumes a minimum of 3 octets, so it should responding, it should if possible make the response the same size as
only be added if the requested size is at least 3 octets more than the request by shrinking the pad option (i.e., not simply including
the size of the normal (non-padded) response. it like for other client options). If the options added by the
server consume as much space as the pad option does, or more, the
server should remove the entire pad option.
4. Packet Format 4. Packet Format
The format of the ssmping messages is a one octet message type, The format of the ssmping messages is a one octet message type,
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 8, line 4 skipping to change at page 8, line 7
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two message types defined. Type 81 (the character Q in There are two message types defined. Type 81 (the character Q in
ASCII) specifies a query. Type 65 (the character A in ASCII) ASCII) specifies a query. Type 65 (the character A in ASCII)
specifies a response (answer). specifies a response (answer).
The options follow right after the type octet and are not aligned in The options follow right after the type octet and are not aligned in
any way (no spacing or padding). I.e., options might start at any any way (no spacing or padding). I.e., options might start at any
octet boundary. The option format is specified below octet boundary. The option format is specified above.
5. Acknowledgements 5. Acknowledgements
The ssmping idea was proposed by Pavan Namburi, Kamil Sarac and Kevin The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
Multicast, and also the Internet Draft draft-sarac-mping-00.txt. Specific Multicast, and also the Internet Draft
Mickael Hoerdt has contributed with several ideas. Alexander Gall, draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with
Nick Lamb and Dave Thaler have contributed in different ways to my several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave
implementation of the ssmping tools [3]. Hugo Santos has made an Thaler have contributed in different ways to my implementation of the
independent implementation of an ssmping server. Many people in ssmping tools [3]. Many people in communities like TERENA, Internet2
communities like TERENA, Internet2 and the M6Bone have used early and the M6Bone have used early implementations of ssmping and
implementations of ssmping and provided feedback that have influenced provided feedback that have influenced the current protocol. Thanks
the current protocol. Thanks to Olav Kvittem, Kamil Sarac and Trond to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Olav
Skjesol for reviewing and providing feedback on this draft. Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei for
reviewing and providing feedback on this draft.
6. IANA Considerations 6. IANA Considerations
As currently specified, ssmping would need a well known port number As currently specified, ssmping would need a well known port number
which the servers listen to. It might be desirable to use SRV which the servers listen to. It might be desirable to use SRV
records instead or in addition to this. For IPv6 SSM ssmping should records instead or in addition to this. For IPv6 SSM ssmping should
ideally have a reserved group ID. For the optional ASM functionality 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 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 same as the one used for SSM. It may also be useful to have a
dedicated group for the optional IPv4 ASM functionality. This dedicated group for the optional IPv4 ASM functionality. This
section needs further work. section needs further work.
There may also be a need for an ssmping option registry. The exact
IANA considerations need to be clarified before this document can go
to working group last call.
7. Security Considerations 7. 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 a
random ssmping server on the Internet send packets to this other random ssmping server on the Internet send packets to this other
host. This is fairly harmless. The worst case is if the host host. This is fairly harmless. The worst case is if the host
receiving the unicast replies also happen to be performing an ssmping receiving the unicast replies also happen to be performing an ssmping
test towards that particular server. In this unlikely event there test towards that particular server. In this unlikely event there
would be an amplification effect where the host receives twice as would be an amplification effect where the host receives twice as
many replies as there are requests sent. An ssmping server should many replies as there are requests sent. An ssmping server should
perform rate limiting, to guard against this being used as an DoS perform rate limiting, to guard against this being used as a DoS
attack. A client should also use the client identifier option to be attack. A client should also use the client identifier option to be
able to distinguish replies to its own requests from replies that able to distinguish replies to its own requests from replies that
might be to other requests. How the protocol should be designed to might be to other requests. How the protocol should be designed to
cope with rate limiting at the server requires further study. One cope with rate limiting at the server requires further study. One
possibility might be that the server can choose to send generic possibility might be that the server can choose to send generic
replies, e.g. a packet every second without the usual client options replies, e.g. a packet every second without the usual client options
but including sequence number and server time stamp, and where but including sequence number and server time stamp, and where
clients do not send requests as long as they receive generic replies. clients do not send requests as long as they receive generic replies.
8. References 8. References
skipping to change at page 9, line 21 skipping to change at page 9, line 28
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 8.2. Informative References
[3] "ssmping implementation", [3] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
Author's Address 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
Urb Glicinias, Smart Residence, 211
Aveiro 3810
Portugal
Email: hugo@fivebits.net
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 20 change blocks. 
102 lines changed or deleted 120 lines changed or added

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