Network Working Group                                          S. Venaas
Internet-Draft                                                   UNINETT
Intended status: Informational                                 H. Santos
Expires: January 10, May 22, 2008                                   July 9,                                    NEC Europe Ltd.
                                                       November 19, 2007

                            ssmping Protocol
                      draft-ietf-mboned-ssmping-01
                      draft-ietf-mboned-ssmping-02

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
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   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 January 10, May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The ssmping is a tool that is used to check protocol specified in this document allows for checking
   whether one can receive SSM, multicast, both Source-Specific Multicast
   (SSM) and Any-Source Multicast (ASM), as well as obtaining some to obtain additional
   multicast related information.  This protocol is based on an
   implementation of tools called ssmping requires
   both a client and a server supporting the ssmping protocol to work.
   We here specify this protocol. asmping.

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.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol specification . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Option format  . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Defined Options  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  7  8
   5.  Message types and options  . . . . . . . . . . . . . . . . . .  9
   6.  Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6. 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7. 13
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8. 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1. 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2. 13
     11.2. Informative References . . . . . . . . . . . . . . . . . .  9 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 10 15

1.  Introduction

   The ssmping is a tool that is designed to allow a local host to check
   whether it is able to receive a protocol specified in this document allows for checking
   multicast connectivity.  Not only reception of multicast flow (SSM by default, or
   ASM when specific options are used) originated by a remote host.
   Additionally it is able to report
   ASM), but can also provide other information such as the
   amount of time used to establish the like multicast tree, tree
   setup time, the number of hops the flow's packets have traveled traveled, as well as
   the packet delay and loss.  This functionality resembles resembles, in part part,
   the ICMP Echo Request/
   Reply infrastructure Request/Reply infrastructure, but over uses UDP and implemented by requires
   both the ssmping a client and server. a server implementing this protocol.

   The protocol here specified is based on the actual implementation of
   the ssmping tool and asmping tools [3] which is are widely used by the
   Internet community to conduct multicast connectivity tests.

2.  Architecture

   Before going into describing the protocol details in detail, we will describe provide a brief overview
   of how it is the protocol may be used and what information it may provide.
   The typical usage of an
   ssmping ssmping/asmping session is as follows.  A
   server runs continuously in order to serve request requests from clients.  When a host user
   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 will send a unicast address of message to the target server
   and G is the standard multicast group defined asking for use by ssmping.

   After a group
   to use.  Optionally the user may have requested a specific group or
   scope, in which case the client will ask for a group matching the
   user's request.  The server will respond with a group to use, or an
   error if no group is available.  Next, the client joins an SSM
   channel (S,G) where S is a unicast address of the target server, or
   an ASM group G, where G is the group specified by the server.

   After joining the channel, the client sends unicasts ssmping requests
   encapsulated in to
   the server.  The requests are sent using UDP with destination port
   set to the standardised ssmping port and the unicast
   address of the server. [TBD].  The requests are sent
   periodically, e.g. e.g., once per second, to the server.  The requests
   contain a serial sequence number, and typically a timestamp.  The requests
   are typically, but not
   necessarily always, simply echoed back by the server. server, except the server may add a few
   options.  To each request, the server sends two replies.  One as
   unicast back to the port and address the request was sourced sent from, and
   also one as multicast back to the port the request came from.  It is currently left open from which port the request is sourced from, whether this port should be
   standardised or not.
   originated with the requested group G as destination address.  The
   server should specify the TTL or Hop Limit of used for both the replies are set unicast and multicast
   messages (we recommend at least 64) and includes a TTL option for the
   client to
   64. compute the number of hops.  The client should leave the SSM channel
   channel/group when it has finished its measurements.

   By use of this protocol, a client can obtain information on about
   several
   aspects of the multicast quality.  First of all, delivery characteristics.  First, by receiving
   unicast replies, it can verify that the server is receiving the
   unicast requests, is operational and responding.  Hence  Hence, provided
   that the client receives unicast replies, a failure in receiving to receive
   multicast indicates either a multicast problem or a multicast
   administrative restriction.  If it does receive multicast, it knows
   not only that it can receive; it may also estimate the amount of time
   it took to establish the multicast tree (at least if it is in the
   range of seconds), whether there are packet drops, and the length and
   variation of round
   trip times Round Trip Times (RTT).  For unicast unicast, the RTT is the
   time from when the unicast request is sent to when the reply is
   received.  The measured multicast RTT also references the client's
   unicast request.  Since  By use of the server sets TTL or Hop Limit to 64, it option specifying the TTL of the
   replies when they are originated, the client can also know determine the
   number of router hops it is away from the source.  By obtaining the same
   values by  Since similar
   information is obtained in the unicast replies, the host may compare
   its multicast and unicast results and is able to check for
   differences in the number of hops, RTT, etc.  Provided that the
   server sends the unicast and multicast replies nearly simultaneously,
   it may also be able to measure the difference in one way delay for
   unicast and multicast on the path from server to client, and also
   differences in delay variation. delay.  Servers may optionally specify a timestamp.
   This may be useful since the unicast and multicast replies can not be
   sent simultaneously (the delay depending on the host's operating
   system and load), or when whether the client and server have synchronised
   clocks.

3.  Protocol specification

   The

   There are four different ssmping requests message types.  There are Echo
   Request and replies have Echo Reply messages used for the actual measurements;
   there is an Init message that SHOULD be used to initialise a ping
   session and negotiate which group to use; and finally a Server
   Response message that is mainly used in response to the Init message.

   The ssmping messages share a common format, 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  The
   Init message generally contains some prefix options asking the server
   for a number group from one of the specified prefixes.  The server responds
   with a Server Response message that contains the group address to
   use, or possibly prefix options in describing what multicast groups the
   request,
   server may be able to provide.  For an Echo Request the client
   generally includes a number of options, and a server may simply echo
   the content back (only changing the message type), without inspecting
   the options.  However, the server SHOULD add a TTL option, and there
   are a number of some other options that a server implementation may MAY support,
   where
   e.g., the client may ask for a certain information or a specific
   behaviour from the server.  In some cases the server will need to add options in the
   response.  The response will then Echo Replies (one unicast and one
   multicast) MUST first contain the exact options from the request, request (in
   the same order), and then right after those, then, immediately following, options appended by
   the server.

   This document defines a number of different options.  Some options
   don't do
   not require processing by servers and are simply returned unmodified
   in the reply.  There are however 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.

   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. same message.

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 field.  Depending
   on the option type 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

   Version, type 0.  Length MUST be 1.  This option MUST always be
   included in all messages, and the value MUST be set to 2 (in
   decimal).  Note that there are older implementations of ssmping that
   only partly follow this specification.  They can be regarded as
   version 1 and do not use this option.

   Client Identifier, ID, type 1.  Length MUST be non-zero.  Only used by
   clients.  A client SHOULD always
   include this. this option in all messages (both Init and Request).  The
   client may use any value it likes to be able to detect whether a
   reply is a reply to this
   query Init/Request or not.  A server should treat
   this as opaque data, and simply leave it unchanged in the reply. 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
   multicasted
   multicast responses to queries from other clients.  It is left to the
   client implementor how to make use of this. this option.

   Sequence number, type 2.  Length MUST be 4.  Only used by clients.  A client SHOULD MUST always
   include this in Request messages and MUST NOT include this. 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
   this.
   this in Request messages and MUST NOT include it in Init messages.  A
   server MAY support this.  If supported replying to a request MUST copy it into the Reply.  In
   addition, a server supporting this option, SHOULD be included include it in the reply Reply
   messages, if requested by the client.  Note that this means that the
   option may be present in the Reply message twice; both a client
   timestamp as part of the echoed Request, and another timestamp added
   by the server.  The timestamp specifies the time when the message
   (query or reply) is sent.  The first 4 bytes specify the number of
   seconds since the Epoch (beginning of the year 1970).  The next 4
   bytes specify the number of microseconds since the last second since
   the Epoch.

   Multicast group, type 4.  Length MUST be greater than 1.  It is
   optional for clients and servers MAY be
   used in Server Response messages to support this.  It allows a tell the client
   to specify which what group the server should send to.  This is currently to use
   in subsequent Request messages.  It MUST be used by a tool called "asmping" in Request messages
   to test ASM connectivity.  The tell the server
   may have restrictions on which groups can what group address to respond to (this group would
   typically be used. previously obtained in a Server Response message).  It
   MUST be used in Reply messages (copied from the Request message).  It
   MUST NOT be used in Init messages.  The format of the option value is
   as below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Addr        Address Family         |  Multicast group address...   |
      +-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ....                         |

   The address family is a value 0-127 0-65535 as assigned by IANA for
   Internet Address Families [2].  This is followed by the group
   address.  For IPv4 the option value length will be 5, 6, for IPv6 17. 18.

   Option Request Option, type 5.  Length MUST be greater than 1.  The  This
   option MAY be used in Init and Request messages.  It MUST NOT be used
   in any other messages, except that a server will, in a Reply, echo
   back this option if present in the Request.  This option contains a
   list of option types of for options that the client
   requests is requesting from
   the server.  Supporting  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 each are two octets. octets each.
   The format of the option value is as 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          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
   options like timestamp Timestamp or version.

   Version, type 6.  Length MUST be non-zero.  Supporting this option is
   optional. Server Information.  A server supporting this option SHOULD add it if and 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.

   Server Information, type 6.  Length MUST be non-zero.  It MAY be used
   in Server Response messages and MUST NOT be used in other messages.
   Support for this option is optional.  A server supporting this option
   SHOULD add it in Server Response messages if and only if requested by
   the client.  The value is just unformatted text a UTF-8 string that might contain vendor
   and version information for the server implementation.  It may also
   contain information on which options the server supports.  An
   interactive client MAY support this option, and SHOULD then allow a
   user to request this string and display it.

   Type 7, Reserved.  This option code value was used by early
   implementations for an option that now is now deprecated.  This option
   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 clients to increase the request sizes size in order to get have the
   server deliver responses of a particular size.  If the server adds
   any options when responding, it should should, if possible make the response
   the same size as the request by shrinking the pad option (i.e., not
   simply including
   it it, as is, like for all other client options).  If the
   options added by the server consume as much space as the pad option
   does, or more, the server should remove the entire pad option.

4.  Packet Format

   The format

   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 ssmping 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 one octet message type,
   followed by 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 variable number of options. 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |          Option                               |
      +-+-+-+-+-+-+-+-+            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Option                               |
      |                            .                                  |
      |                            .        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

   The format of all messages is a one octet message type, directly
   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                               |
      +-+-+-+-+-+-+-+-+            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Option                               |
      |                            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   .
                                   .
                                   .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Option                               |
      |                            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   There are two four message types defined.  Type 81 (the character Q in
   ASCII) specifies a query. an Echo Request (Query).  Type 65 (the character A
   in ASCII) specifies an Echo Response (Answer).  Type 73 (the
   character I in ASCII) is an Init message, and type 83 (the character
   S in ACII) is a Server Response message.

   The options directly follow the type octet and are not aligned in any
   way (no spacing or padding), i.e., options might start at any octet
   boundary.  The option format is specified above.

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 response (answer). client
   sends a Request with no prior Init message.  The options follow right after the type octet server may go ahead
   and are not aligned respond if it is okay with the group used.  In the responses it
   may add a Session ID which will then be in
   any way (no spacing or padding).  I.e., options might start at any
   octet boundary. later requests from the
   client.  If the group is not okay, the server sends back a Server
   Response.  The option format Response is specified above.

5. 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
   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 the implementation of
   the ssmping tools at [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,
   Bharat Joshi, Olav Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol
   and Cao Wei for reviewing and providing feedback on this draft.

6.

9.  IANA Considerations

   As currently specified, ssmping would need

   IANA is requested to provide a well known UDP port number
   which the servers listen to.  It might be desirable to for 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, by 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
   protocol, and also be provide a need registry for an ssmping option registry.  The exact
   IANA considerations need to be clarified before this document can go
   to working group last call.

7. types.

10.  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 an
   arbitrary ssmping server on the Internet send packets to this other
   host.  This hehaviour is fairly harmless.  The worst case is if the
   host receiving the unicast replies also happen to be performing an
   ssmping test towards that particular server.  In this unlikely event event,
   there would be an amplification effect where the host receives twice
   as many replies as there are requests sent.  An ssmping server should
   perform rate limiting, to guard against this function being used as a
   DoS attack.  A client should also use the client identifier ID 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.

11.  References

8.1.

11.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  "IANA, Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

8.2.

11.2.  Informative References

   [3]  "ssmping implementation",
        <http://www.venaas.no/multicast/ssmping/>.

Authors' Addresses

   Stig Venaas
   UNINETT
   Trondheim  NO-7465
   Norway

   Email: venaas@uninett.no

   Hugo Santos
   Urb Glicinias, Smart Residence, 211
   Aveiro  3810
   Portugal
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Email: hugo@fivebits.net hugo.santos@nw.neclab.eu

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
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).