--- 1/draft-ietf-mboned-ssmping-00.txt 2007-07-11 22:12:12.000000000 +0200 +++ 2/draft-ietf-mboned-ssmping-01.txt 2007-07-11 22:12:12.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group S. Venaas Internet-Draft UNINETT -Intended status: Informational May 22, 2007 -Expires: November 23, 2007 +Intended status: Informational H. Santos +Expires: January 10, 2008 July 9, 2007 ssmping Protocol - draft-ietf-mboned-ssmping-00 + draft-ietf-mboned-ssmping-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +23,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 23, 2007. + This Internet-Draft will expire on January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract ssmping is a tool that is used to check whether one can receive SSM, as well as obtaining some additional information. ssmping requires both a client and a server supporting the ssmping protocol to work. @@ -45,141 +45,153 @@ Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol description . . . . . . . . . . . . . . . . . . . . . 3 - 3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 1. Introduction - ssmping is a tool that is used to check whether one can receive SSM, - and it can also give other information like the time to establish the - tree, number of router hops the packets have traveled, packet delay - and loss. The ssmping functionality resembles ICMP echo request/ - reply using UDP and a client and a server that supports the ssmping - protocol. It is used by a client to verify that it can receive - multicast from the server, as well as some additional information. - The protocol as specified here is based on an actual implementation - of a tool [3] that has been found useful by many organisations. + ssmping is a tool that is designed to allow a local host to check + whether it is able to receive a multicast flow (SSM by default, or + ASM when specific options are used) originated by a remote host. + Additionally it is able to report other information such as the + amount of time used to establish the multicast tree, the number of + hops the flow's packets have traveled as well as the packet delay and + loss. This functionality resembles in part the ICMP Echo Request/ + Reply infrastructure but over UDP and implemented by both the ssmping + 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 - used and what information it may provide. The typical usage is as - follows. A server runs continuously in order to serve request from - clients. At some point a client application may try to verify - multicast reception from such a server. The client will need to know - a unicast address of a server. The client joins an SSM channel (S,G) - where S is a unicast address of the server, and G is a standardised - multicast group for use by ssmping. After joining the channel, the - client sends ssmping requests as UDP to a standardised ssmping port - and the unicast address of the server. The requests are sent - periodically, e.g. once per second, to the server. The requests - contain a serial number, and typically a timestamp. The requests are - typically, but not necessarily always, simply echoed back by the - server. To each request, the server sends two replies. One as - unicast back to the port and address the request was sourced from, - and also as multicast back to the port the request came from. It is - currently left open which port the request is sourced from, whether - this port should be 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. + used and what information it may provide. The typical usage of an + ssmping session is as follows. A server runs continuously in order + to serve request from clients. When a host decides to verify the + multicast reception from a specific server (knowing one of the + server's unicast addresses is required), the ssmping client joins an + SSM channel (S,G) where S is a unicast address of the target server + and G is the standard multicast group defined for use by ssmping. + + After joining the channel, the client sends ssmping requests + encapsulated in UDP to the standardised ssmping port and the unicast + address of the server. The requests are sent periodically, e.g. once + per second, to the server. The requests contain a serial number, and + typically a timestamp. The requests are typically, but not + necessarily always, simply echoed back by the server. To each + request, the server sends two replies. One as unicast back to the + port and address the request was sourced from, and also as multicast + back to the port the request came from. It is currently left open + which port the request is sourced from, whether this port should be + 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 aspects of the multicast quality. First of all, by receiving unicast replies, it can verify that the server is receiving the unicast requests, is operational and responding. Hence provided that the - client receives unicast replies, a failure in receiving multicast is - indeed caused by a multicast problem. If it does receive multicast, - it knows not only that it can receive, but it may get some - information on how long it takes to establish the multicast tree (at - least if it is in the range of seconds), whether there are packet - drops, and the length and variation of round trip times (RTT). For - unicast the RTT is the time from unicast request is sent to when the - reply is received. For multicast we also talk about RTT, but then we - mean from the unicast request is sent to when the multicast reply is - received. Since the server sets TTL or Hop Limit to 64, it can also - know the number of router hops it is away from the source. By - comparing with the unicast replies, it can see whether there are - differences in RTT and number of hops etc for unicast and multicast. - Provided that the server sends the unicast and multicast replies - nearly simultaneously, it may also be able to measure difference in - one way delay for unicast and multicast on the path from server to - client, and also if there are differences in delay variation. - Servers may optionally specify a timestamp. This may be useful if - the unicast and multicast replies can not be sent nearly - simultaneously, or if the client and server have synchronised clocks. + client receives unicast replies, a failure in receiving multicast + indicates either a multicast problem or a multicast administrative + restriction. If it does receive multicast, it knows not only that it + can receive; it may estimate the amount of time it took to establish + the multicast tree (at least if it is in the range of seconds), + whether there are packet drops, and the length and variation of round + trip times (RTT). For unicast the RTT is the time from the unicast + request is sent to when the reply is received. The measured + multicast RTT also references the client's unicast request. Since + the server sets TTL or Hop Limit to 64, it can also know the number + of router hops it is away from the source. By obtaining the same + values by the unicast replies, the host may compare its multicast and + unicast results and is able to check for differences in the number of + hops, RTT, etc. Provided that the server sends the unicast and + multicast replies nearly simultaneously, it may also be able to + measure difference in one way delay for unicast and multicast on the + path from server to client, and also differences in delay variation. + Servers may optionally specify a timestamp. This may be useful since + the unicast and multicast replies can not be sent simultaneously (the + delay depending on the host's operating system and load), or when the + client and server have synchronised clocks. + +3. Protocol specification The ssmping requests and replies have a common format, one octet specifying the message type, followed by a number of options in TLV (Type, Length and Value) format. This makes the protocol easily extendible. Generally the client includes a number of options in the request, and a server may simply echo the content back (only changing 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. -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 - only used by clients and simply echoed back by the server, where the - server doesn't care about their contents. There are however some - client options that the server may care about. There are also server - options that may be requested by the 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. 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. + Unless otherwise specified, an option MUST NOT be used multiple times + in a request. Also unless otherwise specified, an option MUST NOT be + 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 All options are TLVs formatted as specified below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (2 octets) specifies the option. The different options are defined below. - Length (2 octets) specifies the length of the value. Depending on - the option type it can be from 0 to 65535. + Length (2 octets) specifies the length of the value field. Depending + on the option type it can be from 0 to 65535. Value. The value must always be of the specified length. See the respective option definitions for possible values. If the length is 0, the value field is not included. 3.2. Defined Options Client Identifier, type 1. Length MUST be non-zero. Only used by 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 @@ -237,39 +249,33 @@ This option might be used by the client to ask the server to include options like timestamp or version. Version, type 6. Length MUST be non-zero. Supporting this option is optional. A server supporting this option SHOULD add it if and only if requested by the client. The value is just unformatted text that might contain vendor and version information for the server implementation. It may also contain information on which options the server supports. - Reply size, type 7. Length MUST be 2 octets. This option is - optional for clients and servers. It can be used to request the - server response to be of a certain size. The value specifies the - desired response size in octets. A server supporting this will if - 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. + Type 7, Reserved. This option code value was used by early + implementations for an option that now is deprecated. This should no + longer be used. Clients MUST not use this option, and Servers MUST + ignore it. 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 - a reply that is larger than what the server normally would send. The - addition of this option consumes a minimum of 3 octets, so it should - only be added if the requested size is at least 3 octets more than - the size of the normal (non-padded) response. + used by clients to increase the request sizes in order to get + responses of a particular size. If the server adds any options when + responding, it should if possible make the response the same size as + the request by shrinking the pad option (i.e., not simply including + it 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 The format of the ssmping messages is a one octet message type, followed by a variable number of options. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Option | @@ -291,58 +297,63 @@ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are two message types defined. Type 81 (the character Q in ASCII) specifies a query. Type 65 (the character A in ASCII) specifies a response (answer). 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 - octet boundary. The option format is specified below + octet boundary. The option format is specified above. 5. Acknowledgements - The ssmping idea was proposed by Pavan Namburi, Kamil Sarac and Kevin - C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific - Multicast, and also the Internet Draft draft-sarac-mping-00.txt. - Mickael Hoerdt has contributed with several ideas. Alexander Gall, - Nick Lamb and Dave Thaler have contributed in different ways to my - implementation of the ssmping tools [3]. Hugo Santos has made an - independent implementation of an ssmping server. Many people in - communities like TERENA, Internet2 and the M6Bone have used early - implementations of ssmping and provided feedback that have influenced - the current protocol. Thanks to Olav Kvittem, Kamil Sarac and Trond - Skjesol for reviewing and providing feedback on this draft. + The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and + Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source + Specific Multicast, and also the Internet Draft + draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with + several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave + Thaler have contributed in different ways to my implementation of the + ssmping tools [3]. Many people in communities like TERENA, Internet2 + and the M6Bone have used early implementations of ssmping and + provided feedback that have influenced the current protocol. Thanks + to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Olav + Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol 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 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 considerations need to be clarified before this document can go + to working group last call. + 7. Security Considerations 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 random ssmping server on the Internet send packets to this other host. This is fairly harmless. The worst case is if the host receiving the unicast replies also happen to be performing an ssmping test towards that particular server. In this unlikely event there would be an amplification effect where the host receives twice as many replies as there are requests sent. An ssmping server should - perform rate limiting, to guard against this 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 able to distinguish replies to its own requests from replies that might be to other requests. How the protocol should be designed to 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 @@ -353,29 +364,36 @@ Levels", BCP 14, RFC 2119, March 1997. [2] "IANA, Address Family Numbers", . 8.2. Informative References [3] "ssmping implementation", . -Author's Address +Authors' Addresses Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no + Hugo Santos + Urb Glicinias, Smart Residence, 211 + Aveiro 3810 + Portugal + + Email: hugo@fivebits.net + Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS