idnits 2.17.1 draft-venaas-mboned-ssmping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 410. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2007) is 6231 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft UNINETT 4 Intended status: Informational February 26, 2007 5 Expires: August 30, 2007 7 ssmping Protocol 8 draft-venaas-mboned-ssmping-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 ssmping is a tool that is used to check whether one can receive SSM, 42 as well as obtaining some additional information. ssmping requires 43 both a client and a server supporting the ssmping protocol to work. 44 We here specify this protocol. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [1]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Protocol description . . . . . . . . . . . . . . . . . . . . . 3 56 3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5 59 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 ssmping is a tool that is used to check whether one can receive SSM, 72 and it can also give other information like the time to establish the 73 tree, number of router hops the packets have traveled, packet delay 74 and loss. The ssmping functionality resembles ICMP echo request/ 75 reply using UDP and a client and a server that supports the ssmping 76 protocol. It is used by a client to verify that it can receive 77 multicast from the server, as well as some additional information. 78 The protocol as specified here is based on an actual implementation 79 of a tool [3] that has been found useful by many organisations. 81 2. Protocol description 83 Before going into the protocol details we will describe how it is 84 used and what information it may provide. The typical usage is as 85 follows. A server runs continuously in order to serve request from 86 clients. At some point a client application may try to verify 87 multicast reception from such a server. The client will need to know 88 a unicast address of a server. The client joins an SSM channel (S,G) 89 where S is a unicast address of the server, and G is a standardised 90 multicast group for use by ssmping. After joining the channel, the 91 client sends ssmping requests as UDP to a standardised ssmping port 92 and the unicast address of the server. The requests are sent 93 periodically, e.g. once per second, to the server. The requests 94 contain a serial number, and typically a timestamp. The requests are 95 typically, but not necessarily always, simply echoed back by the 96 server. To each request, the server sends two replies. One as 97 unicast back to the port and address the request was sourced from, 98 and also as multicast back to the port the request came from. It is 99 currently left open which port the request is sourced from, whether 100 this port should be standardised or not. The TTL or Hop Limit of the 101 replies are set to 64. The client should leave the SSM channel when 102 it has finished its measurements. 104 By use of this protocol, a client can obtain information on several 105 aspects of the multicast quality. First of all, by receiving unicast 106 replies, it can verify that the server is receiving the unicast 107 requests, is operational and responding. Hence provided that the 108 client receives unicast replies, a failure in receiving multicast is 109 indeed caused by a multicast problem. If it does receive multicast, 110 it knows not only that it can receive, but it may get some 111 information on how long it takes to establish the multicast tree (at 112 least if it is in the range of seconds), whether there are packet 113 drops, and the length and variation of round trip times (RTT). For 114 unicast the RTT is the time from unicast request is sent to when the 115 reply is received. For multicast we also talk about RTT, but then we 116 mean from the unicast request is sent to when the multicast reply is 117 received. Since the server sets TTL or Hop Limit to 64, it can also 118 know the number of router hops it is away from the source. By 119 comparing with the unicast replies, it can see whether there are 120 differences in RTT and number of hops etc for unicast and multicast. 121 Provided that the server sends the unicast and multicast replies 122 nearly simultaneously, it may also be able to measure difference in 123 one way delay for unicast and multicast on the path from server to 124 client, and also if there are differences in delay variation. 125 Servers may optionally specify a timestamp. This may be useful if 126 the unicast and multicast replies can not be sent nearly 127 simultaneously, or if the client and server have synchronised clocks. 129 The ssmping requests and replies have a common format, one octet 130 specifying the message type, followed by a number of options in TLV 131 (Type, Length and Value) format. This makes the protocol easily 132 extendible. Generally the client includes a number of options in the 133 request, and a server may simply echo the content back (only changing 134 the message type), without inspecting the options. However, there 135 are a number of options that a server implementation may support, 136 where the client may ask for a certain information or behaviour from 137 the server. In some cases the server will need to add options in the 138 response. The response will then first contain the exact options 139 from the request, and then right after those, options appended by the 140 server. 142 3. Options 144 There are a number of different options. Most of the options are 145 only used by clients and simply echoed back by the server, where the 146 server doesn't care about their contents. There are however some 147 client options that the server may care about. There are also server 148 options that may be requested by the client. Generally a simple 149 client will only include a few options, and get exactly the same 150 options and values echoed back. Strictly speaking the protocol could 151 work without any options. Without sending any options a client would 152 still be able to tell whether multicast is working or not, however 153 with the use of some of the basic options a client can obtain a lot 154 more information. 156 3.1. Option format 158 All options are TLVs formatted as specified below. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Value | 166 | . | 167 | . | 168 | . | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type (2 octets) specifies the option. The different options are 172 defined below. 174 Length (2 octets) specifies the length of the value. Depending on 175 the option type it can be from 0 to 65535. 177 Value. The value must always be of the specified length. See the 178 respective option definitions for possible values. If the length is 179 0, the value field is not included. 181 3.2. Defined Options 183 Client Identifier, type 1. Length MUST be non-zero. Only used by 184 clients. A client SHOULD include this. The client may use any value 185 it likes to be able to detect whether a reply is a reply to this 186 query or not. A server should treat this as opaque data, and simply 187 leave it unchanged in the reply. The value might be a process ID, 188 perhaps process ID combined with an IP address because it may receive 189 multicasted responses to queries from other clients. It is left to 190 the client implementor how to make use of this. 192 Sequence number, type 2. Length MUST be 4. Only used by clients. A 193 client SHOULD include this. This contains a 32 bit sequence number. 194 The values would typically start at 1 and increase by one for each 195 request in a sequence. 197 Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include 198 this. A server MAY support this. If supported it SHOULD be included 199 in the reply if requested by the client. The timestamp specifies the 200 time when the message (query or reply) is sent. The first 4 bytes 201 specify the number of seconds since the Epoch (beginning of the year 202 1970). The next 4 bytes specify the number of microseconds since the 203 last second since the Epoch. 205 Multicast group, type 4. Length MUST be greater than 1. It is 206 optional for clients and servers to support this. It allows a client 207 to specify which group the server should send to. This is currently 208 used by a tool called "asmping" to test ASM connectivity. The server 209 may have restrictions on which groups can be used. The format of the 210 option value is as below. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Addr Family | Multicast group address... | 216 +-+-+-+-+-+-+-+-+ .... | 218 The address family is a value 0-127 as assigned by IANA for Internet 219 Address Families [2]. This is followed by the group address. For 220 IPv4 the option value length will be 5, for IPv6 17. 222 Option Request Option, type 5. Length MUST be greater than 1. The 223 option contains a list of option types of options that the client 224 requests from the server. Supporting this is optional for both 225 clients and servers. The length of this option will be a non-zero 226 even number, since it contains option types that each are two octets. 227 The format of the value is as below. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Option Type | Option Type | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | ..... | 236 The value might contain an odd number of options, including just one. 237 This option might be used by the client to ask the server to include 238 options like timestamp or version. 240 Version, type 6. Length MUST be non-zero. Supporting this option is 241 optional. A server supporting this option SHOULD add it if and only 242 if requested by the client. The value is just unformatted text that 243 might contain vendor and version information for the server 244 implementation. It may also contain information on which options the 245 server supports. 247 Reply size, type 7. Length MUST be 2 octets. This option is 248 optional for clients and servers. It can be used to request the 249 server response to be of a certain size. The value specifies the 250 desired response size in octets. A server supporting this will if 251 necessary use the pad option to increase the size of the response. A 252 server should however not try to make the response shorter due to 253 this option. That is, it should not omit or shorten any option 254 values to try to accommodate this. The response should never be 255 shorter than if this option were not included. Also, the pad option 256 requires at least 3 octets, so the server will not pad the response 257 size if the requested size is not at least 3 octets longer than the 258 normal response size. 260 Pad, type 8. Length can be anything, including 0. This option is 261 used by servers to increase the response size if the client asks for 262 a reply that is larger than what the server normally would send. The 263 addition of this option consumes a minimum of 3 octets, so it should 264 only be added if the requested size is at least 3 octets more than 265 the size of the normal (non-padded) response. 267 4. Packet Format 269 The format of the ssmping messages is a one octet message type, 270 followed by a variable number of options. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Option | 276 +-+-+-+-+-+-+-+-+ . | 277 | . | 278 | . | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Option | 281 | . | 282 | . | 283 | . | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 . 286 . 287 . 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Option | 290 | . | 291 | . | 292 | . | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 There are two message types defined. Type 81 (the character Q in 296 ASCII) specifies a query. Type 65 (the character A in ASCII) 297 specifies a response (answer). 299 The options follow right after the type octet and are not aligned in 300 any way (no spacing or padding). I.e., options might start at any 301 octet boundary. The option format is specified below 303 5. Acknowledgements 305 The ssmping idea was proposed by Pavan Namburi, Kamil Sarac and Kevin 306 C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific 307 Multicast, and also the Internet Draft draft-sarac-mping-00.txt. 308 Mickael Hoerdt has contributed with several ideas. Alexander Gall, 309 Nick Lamb and Dave Thaler have contributed in different ways to my 310 implementation of the ssmping tools [3]. Hugo Santos has made an 311 independent implementation of an ssmping server. Many people in 312 communities like TERENA, Internet2 and the M6Bone have used early 313 implementations of ssmping and provided feedback that have influenced 314 the current protocol. Thanks to Olav Kvittem, Kamil Sarac and Trond 315 Skjesol for reviewing and providing feedback on this draft. 317 6. IANA Considerations 319 As currently specified, ssmping would need a well known port number 320 which the servers listen to. It might be desirable to use SRV 321 records instead or in addition to this. For IPv6 SSM ssmping should 322 ideally have a reserved group ID. For the optional ASM functionality 323 it would be useful to have a reserved IPv6 group ID, this may be the 324 same as the one used for SSM. It may also be useful to have a 325 dedicated group for the optional IPv4 ASM functionality. This 326 section needs further work. 328 7. Security Considerations 330 There are some security issues to consider. One is that a host may 331 send a request with an IP source address of another host, and make a 332 random ssmping server on the Internet send packets to this other 333 host. This is fairly harmless. The worst case is if the host 334 receiving the unicast replies also happen to be performing an ssmping 335 test towards that particular server. In this unlikely event there 336 would be an amplification effect where the host receives twice as 337 many replies as there are requests sent. An ssmping server should 338 perform rate limiting, to guard against this being used as an DoS 339 attack. A client should also use the client identifier option to be 340 able to distinguish replies to its own requests from replies that 341 might be to other requests. How the protocol should be designed to 342 cope with rate limiting at the server requires further study. One 343 possibility might be that the server can choose to send generic 344 replies, e.g. a packet every second without the usual client options 345 but including sequence number and server time stamp, and where 346 clients do not send requests as long as they receive generic replies. 348 8. References 350 8.1. Normative References 352 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 353 Levels", BCP 14, RFC 2119, March 1997. 355 [2] "IANA, Address Family Numbers", 356 . 358 8.2. Informative References 360 [3] "ssmping implementation", 361 . 363 Author's Address 365 Stig Venaas 366 UNINETT 367 Trondheim NO-7465 368 Norway 370 Email: venaas@uninett.no 372 Full Copyright Statement 374 Copyright (C) The IETF Trust (2007). 376 This document is subject to the rights, licenses and restrictions 377 contained in BCP 78, and except as set forth therein, the authors 378 retain all their rights. 380 This document and the information contained herein are provided on an 381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 383 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 384 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 385 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 388 Intellectual Property 390 The IETF takes no position regarding the validity or scope of any 391 Intellectual Property Rights or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; nor does it represent that it has 395 made any independent effort to identify any such rights. Information 396 on the procedures with respect to rights in RFC documents can be 397 found in BCP 78 and BCP 79. 399 Copies of IPR disclosures made to the IETF Secretariat and any 400 assurances of licenses to be made available, or the result of an 401 attempt made to obtain a general license or permission for the use of 402 such proprietary rights by implementers or users of this 403 specification can be obtained from the IETF on-line IPR repository at 404 http://www.ietf.org/ipr. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights that may cover technology that may be required to implement 409 this standard. Please address the information to the IETF at 410 ietf-ipr@ietf.org. 412 Acknowledgment 414 Funding for the RFC Editor function is provided by the IETF 415 Administrative Support Activity (IASA).