idnits 2.17.1 draft-ietf-mboned-ssmping-01.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 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- 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 (July 9, 2007) is 6130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 H. Santos 5 Expires: January 10, 2008 July 9, 2007 7 ssmping Protocol 8 draft-ietf-mboned-ssmping-01 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 January 10, 2008. 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. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 ssmping is a tool that is designed to allow a local host to check 72 whether it is able to receive a multicast flow (SSM by default, or 73 ASM when specific options are used) originated by a remote host. 74 Additionally it is able to report other information such as the 75 amount of time used to establish the multicast tree, the number of 76 hops the flow's packets have traveled as well as the packet delay and 77 loss. This functionality resembles in part the ICMP Echo Request/ 78 Reply infrastructure but over UDP and implemented by both the ssmping 79 client and server. The protocol here specified is based on the 80 actual implementation of the ssmping tool [3] which is widely used by 81 the Internet community to conduct multicast connectivity tests. 83 2. Architecture 85 Before going into the protocol details we will describe how it is 86 used and what information it may provide. The typical usage of an 87 ssmping session is as follows. A server runs continuously in order 88 to serve request from clients. When a host decides to verify the 89 multicast reception from a specific server (knowing one of the 90 server's unicast addresses is required), the ssmping client joins an 91 SSM channel (S,G) where S is a unicast address of the target server 92 and G is the standard multicast group defined for use by ssmping. 94 After joining the channel, the client sends ssmping requests 95 encapsulated in UDP to the standardised ssmping port and the unicast 96 address of the server. The requests are sent periodically, e.g. once 97 per second, to the server. The requests contain a serial number, and 98 typically a timestamp. The requests are typically, but not 99 necessarily always, simply echoed back by the server. To each 100 request, the server sends two replies. One as unicast back to the 101 port and address the request was sourced from, and also as multicast 102 back to the port the request came from. It is currently left open 103 which port the request is sourced from, whether this port should be 104 standardised or not. The TTL or Hop Limit of the replies are set to 105 64. The client should leave the SSM channel when it has finished its 106 measurements. 108 By use of this protocol, a client can obtain information on several 109 aspects of the multicast quality. First of all, by receiving unicast 110 replies, it can verify that the server is receiving the unicast 111 requests, is operational and responding. Hence provided that the 112 client receives unicast replies, a failure in receiving multicast 113 indicates either a multicast problem or a multicast administrative 114 restriction. If it does receive multicast, it knows not only that it 115 can receive; it may estimate the amount of time it took to establish 116 the multicast tree (at least if it is in the range of seconds), 117 whether there are packet drops, and the length and variation of round 118 trip times (RTT). For unicast the RTT is the time from the unicast 119 request is sent to when the reply is received. The measured 120 multicast RTT also references the client's unicast request. Since 121 the server sets TTL or Hop Limit to 64, it can also know the number 122 of router hops it is away from the source. By obtaining the same 123 values by the unicast replies, the host may compare its multicast and 124 unicast results and is able to check for differences in the number of 125 hops, RTT, etc. Provided that the server sends the unicast and 126 multicast replies nearly simultaneously, it may also be able to 127 measure difference in one way delay for unicast and multicast on the 128 path from server to client, and also differences in delay variation. 129 Servers may optionally specify a timestamp. This may be useful since 130 the unicast and multicast replies can not be sent simultaneously (the 131 delay depending on the host's operating system and load), or when the 132 client and server have synchronised clocks. 134 3. Protocol specification 136 The ssmping requests and replies have a common format, one octet 137 specifying the message type, followed by a number of options in TLV 138 (Type, Length and Value) format. This makes the protocol easily 139 extendible. Generally the client includes a number of options in the 140 request, and a server may simply echo the content back (only changing 141 the message type), without inspecting the options. However, there 142 are a number of options that a server implementation may support, 143 where the client may ask for a certain information or behaviour from 144 the server. In some cases the server will need to add options in the 145 response. The response will then first contain the exact options 146 from the request, and then right after those, options appended by the 147 server. 149 This document defines a number of different options. Some options 150 don't require processing by servers and are simply returned 151 unmodified in the reply. There are however other client options that 152 the server may care about, and also server options that may be 153 requested by a client. Generally a simple client will only include a 154 few options, and get exactly the same options and values echoed back. 155 Strictly speaking the protocol could work without any options. The 156 protocol here defined does not require the use of any options, and a 157 client may operate without specifying any. However some of the 158 options allow the client to obtain additional information. 160 Unless otherwise specified, an option MUST NOT be used multiple times 161 in a request. Also unless otherwise specified, an option MUST NOT be 162 appended by the server multiple times. Note that some options, like 163 timestamp, may be added by both the client and the server. In that 164 case the timestamp option would be in the response twice. But as 165 said above, it is not used multiple times in the request, and not 166 appended multiple times by the server. 168 3.1. Option format 170 All options are TLVs formatted as specified below. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Value | 178 | . | 179 | . | 180 | . | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Type (2 octets) specifies the option. The different options are 184 defined below. 186 Length (2 octets) specifies the length of the value field. Depending 187 on the option type it can be from 0 to 65535. 189 Value. The value must always be of the specified length. See the 190 respective option definitions for possible values. If the length is 191 0, the value field is not included. 193 3.2. Defined Options 195 Client Identifier, type 1. Length MUST be non-zero. Only used by 196 clients. A client SHOULD include this. The client may use any value 197 it likes to be able to detect whether a reply is a reply to this 198 query or not. A server should treat this as opaque data, and simply 199 leave it unchanged in the reply. The value might be a process ID, 200 perhaps process ID combined with an IP address because it may receive 201 multicasted responses to queries from other clients. It is left to 202 the client implementor how to make use of this. 204 Sequence number, type 2. Length MUST be 4. Only used by clients. A 205 client SHOULD include this. This contains a 32 bit sequence number. 206 The values would typically start at 1 and increase by one for each 207 request in a sequence. 209 Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include 210 this. A server MAY support this. If supported it SHOULD be included 211 in the reply if requested by the client. The timestamp specifies the 212 time when the message (query or reply) is sent. The first 4 bytes 213 specify the number of seconds since the Epoch (beginning of the year 214 1970). The next 4 bytes specify the number of microseconds since the 215 last second since the Epoch. 217 Multicast group, type 4. Length MUST be greater than 1. It is 218 optional for clients and servers to support this. It allows a client 219 to specify which group the server should send to. This is currently 220 used by a tool called "asmping" to test ASM connectivity. The server 221 may have restrictions on which groups can be used. The format of the 222 option value is as below. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Addr Family | Multicast group address... | 228 +-+-+-+-+-+-+-+-+ .... | 230 The address family is a value 0-127 as assigned by IANA for Internet 231 Address Families [2]. This is followed by the group address. For 232 IPv4 the option value length will be 5, for IPv6 17. 234 Option Request Option, type 5. Length MUST be greater than 1. The 235 option contains a list of option types of options that the client 236 requests from the server. Supporting this is optional for both 237 clients and servers. The length of this option will be a non-zero 238 even number, since it contains option types that each are two octets. 239 The format of the value is as below. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Option Type | Option Type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | ..... | 248 The value might contain an odd number of options, including just one. 249 This option might be used by the client to ask the server to include 250 options like timestamp or version. 252 Version, type 6. Length MUST be non-zero. Supporting this option is 253 optional. A server supporting this option SHOULD add it if and only 254 if requested by the client. The value is just unformatted text that 255 might contain vendor and version information for the server 256 implementation. It may also contain information on which options the 257 server supports. 259 Type 7, Reserved. This option code value was used by early 260 implementations for an option that now is deprecated. This should no 261 longer be used. Clients MUST not use this option, and Servers MUST 262 ignore it. 264 Pad, type 8. Length can be anything, including 0. This option is 265 used by clients to increase the request sizes in order to get 266 responses of a particular size. If the server adds any options when 267 responding, it should if possible make the response the same size as 268 the request by shrinking the pad option (i.e., not simply including 269 it like for other client options). If the options added by the 270 server consume as much space as the pad option does, or more, the 271 server should remove the entire pad option. 273 4. Packet Format 275 The format of the ssmping messages is a one octet message type, 276 followed by a variable number of options. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Option | 282 +-+-+-+-+-+-+-+-+ . | 283 | . | 284 | . | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Option | 287 | . | 288 | . | 289 | . | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 . 292 . 293 . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Option | 296 | . | 297 | . | 298 | . | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 There are two message types defined. Type 81 (the character Q in 302 ASCII) specifies a query. Type 65 (the character A in ASCII) 303 specifies a response (answer). 305 The options follow right after the type octet and are not aligned in 306 any way (no spacing or padding). I.e., options might start at any 307 octet boundary. The option format is specified above. 309 5. Acknowledgements 311 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 312 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 313 Specific Multicast, and also the Internet Draft 314 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 315 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 316 Thaler have contributed in different ways to my implementation of the 317 ssmping tools [3]. Many people in communities like TERENA, Internet2 318 and the M6Bone have used early implementations of ssmping and 319 provided feedback that have influenced the current protocol. Thanks 320 to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Olav 321 Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei for 322 reviewing and providing feedback on this draft. 324 6. IANA Considerations 326 As currently specified, ssmping would need a well known port number 327 which the servers listen to. It might be desirable to use SRV 328 records instead or in addition to this. For IPv6 SSM ssmping should 329 ideally have a reserved group ID. For the optional ASM functionality 330 it would be useful to have a reserved IPv6 group ID, this may be the 331 same as the one used for SSM. It may also be useful to have a 332 dedicated group for the optional IPv4 ASM functionality. This 333 section needs further work. 335 There may also be a need for an ssmping option registry. The exact 336 IANA considerations need to be clarified before this document can go 337 to working group last call. 339 7. Security Considerations 341 There are some security issues to consider. One is that a host may 342 send a request with an IP source address of another host, and make a 343 random ssmping server on the Internet send packets to this other 344 host. This is fairly harmless. The worst case is if the host 345 receiving the unicast replies also happen to be performing an ssmping 346 test towards that particular server. In this unlikely event there 347 would be an amplification effect where the host receives twice as 348 many replies as there are requests sent. An ssmping server should 349 perform rate limiting, to guard against this being used as a DoS 350 attack. A client should also use the client identifier option to be 351 able to distinguish replies to its own requests from replies that 352 might be to other requests. How the protocol should be designed to 353 cope with rate limiting at the server requires further study. One 354 possibility might be that the server can choose to send generic 355 replies, e.g. a packet every second without the usual client options 356 but including sequence number and server time stamp, and where 357 clients do not send requests as long as they receive generic replies. 359 8. References 361 8.1. Normative References 363 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 364 Levels", BCP 14, RFC 2119, March 1997. 366 [2] "IANA, Address Family Numbers", 367 . 369 8.2. Informative References 371 [3] "ssmping implementation", 372 . 374 Authors' Addresses 376 Stig Venaas 377 UNINETT 378 Trondheim NO-7465 379 Norway 381 Email: venaas@uninett.no 383 Hugo Santos 384 Urb Glicinias, Smart Residence, 211 385 Aveiro 3810 386 Portugal 388 Email: hugo@fivebits.net 390 Full Copyright Statement 392 Copyright (C) The IETF Trust (2007). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org. 430 Acknowledgment 432 Funding for the RFC Editor function is provided by the IETF 433 Administrative Support Activity (IASA).