idnits 2.17.1 draft-morton-ippm-twamp-session-cntrl-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 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. 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 (July 6, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 435, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-twamp-08 == Outdated reference: A later version (-02) exists of draft-morton-ippm-more-twamp-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track July 6, 2008 5 Expires: January 7, 2009 7 Independent Session Control Feature for TWAMP 8 draft-morton-ippm-twamp-session-cntrl-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 January 7, 2009. 35 Abstract 37 The IETF is completing its work on TWAMP - the Two-Way Active 38 Measurement Protocol. This memo describes a proposed feature for 39 TWAMP, intended for discussion in the IP Performance Metrics WG. The 40 feature gives the sender the ability to start and stop one or more 41 test sessions using the Session Identifiers. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 53 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 54 3.1. Connection Setup with Individual Session Control . . . . . 4 55 3.2. Start-Sessions Command with Session Control . . . . . . . 5 56 3.3. Stop-Sessions Command with Session Control . . . . . . . . 6 57 3.4. SERVWAIT Timer Operation . . . . . . . . . . . . . . . . . 6 58 3.5. Additional considerations . . . . . . . . . . . . . . . . 7 59 4. TWAMP Test with Individual Session Control . . . . . . . . . . 7 60 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 8 65 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 9 66 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 9 67 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Intellectual Property and Copyright Statements . . . . . . . . . . 12 75 1. Introduction 77 The IETF is completing its work on TWAMP - the Two-Way Active 78 Measurement Protocol [I-D.ietf-ippm-twamp], which is an extension to 79 the One-way Active Measurement Protocol, OWAMP [RFC4656]. 81 This memo describes a new proposed feature for TWAMP, so it can be 82 discussed and interest to take-up the feature assessed. TWAMP (and 83 OWAMP) start all previously requested and accepted test sessions at 84 once. This feature allows the Control-Client to control the test 85 sessions on the basis of their Session Identifier (SID). The feature 86 permits a short duration TWAMP test to start (and stop) during a 87 longer test. For example, this feature permits a specific diagnostic 88 test to begin if intermediate results indicate that the test is 89 warranted. 91 This feature requires a Mode bit position assignment and the 92 assignment of two new TWAMP command numbers (for the augmented Start 93 and Stop commands). 95 The relationship between this memo and TWAMP is intended to be an 96 update to the TWAMP RFC when published. 98 2. Purpose and Scope 100 The purpose of this memo is to describe an additional function and 101 feature for TWAMP [I-D.ietf-ippm-twamp]. The feature needs a clear 102 description so it can be discussed and (hopefully) adopted in the IP 103 Performance Metrics Charter. 105 The scope of the memo is currently limited to specifications of the 106 following features: 108 1. Extension of the modes of operation through assignment of a new 109 value in the Mode field to communicate feature capability and 110 use, the definition of augmented Start Session and Stop Session 111 commands, and the definition of related procedures for TWAMP 112 entities. The motivation for this added feature is the ability 113 to start and stop individual test sessions at will, using a 114 single TWAMP-control connection. 116 When new features are discussed and reach consensus, they may become 117 chartered work items in IETF IPPM (and may appear in a different 118 memo). 120 3. TWAMP Control Extensions 122 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 123 and provides two-way measurement capability. TWAMP 124 [I-D.ietf-ippm-twamp] uses the Mode field to identify and select 125 specific communication capabilities, and this field is a recognized 126 extension mechanism. The following sections describe one such 127 extension. 129 3.1. Connection Setup with Individual Session Control 131 TWAMP connection establishment follows the procedure defined in 132 section 3.1 of [RFC4656]. The Individual Session Control mode 133 requires one new bit position (and value) to identify the ability of 134 the Server/Session-Reflector to start and stop specific sessions 135 (according to their Session Identifier, or SID). This new feature 136 requires an additional TWAMP mode bit assignment as follows: 138 Value Description Reference/Explanation 139 0 Reserved 140 1 Unauthenticated RFC4656, Section 3.1 141 2 Authenticated RFC4656, Section 3.1 142 4 Encrypted RFC4656, Section 3.1 143 8 Unauth. TEST protocol, draft-...-more-twamp (3) 144 Auth. CONTROL 145 16 Unauth. TEST protocol, draft-...-more-twamp (4) 146 Encrypted CONTROL 147 32 Auth. TEST protocol, draft-...-more-twamp (5) 148 Encrypted CONTROL 149 -------------------------------------------------------- 150 zzz Individual Session this memo, bit position (Z) 151 Control 153 In the original OWAMP mode field, setting bit positions 0, 1 or 2 154 indicated the security mode of the Control protocol, and the Test 155 protocol inherited the same mode (see section 4 of [RFC4656]). In 156 the [I-D.morton-ippm-more-twamp] proposal, bit positions (3, 4 or 5) 157 discontinue the inheritance of the security mode in the Test 158 protocol. 160 The Server sets the new bit position (possibly bit 8) in the Server 161 Greeting message to indicate its capabilities and willingness to 162 control sessions on an individual basis if desired. 164 If the Control-Client intends to control sessions on an individual 165 basis, it MUST set the mode bit corresponding to that mode in the 166 Setup Response message. 168 3.2. Start-Sessions Command with Session Control 170 Having requested one or more test sessions and received affirmative 171 Accept-Session responses, an OWAMP client MAY start the execution of 172 the requested test sessions by sending a Start-Sessions message to 173 the server. 175 The format of this message is as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | 7 | | 181 +-+-+-+-+-+-+-+-+ + 182 | MBZ (7 octets) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Number of Sessions | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 | First SID (16 octets) | 188 | | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | remaining SIDs (16 octets each) | 193 | | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 | HMAC (16 octets) | 198 | | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 The Number of sessions field indicates the count of sessions that 203 this Start command applies to. The SID is as defined in OWAMP (and 204 TWAMP) section 3.5 [RFC4656]. 206 The Server MUST respond with a Start-Ack message (which SHOULD be 207 sent as quickly as possible). Start-Ack messages have the format 208 defined in section 3.7 of [RFC4656]. 210 The Control Client MUST NOT send a subsequent Start Sessions command 211 until an outstanding message is acknowledged with a Start-Ack 212 message. 214 3.3. Stop-Sessions Command with Session Control 216 The Stop-Sessions command can only be issued by the Control-Client. 217 The message MUST contain at least one SID. The message is terminated 218 with a single block HMAC, to complete the Stop-Sessions Command. 220 Thus, the TWAMP Stop-Sessions command for individual session control 221 is constructed as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 8 | Accept | MBZ | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Number of Sessions | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | First SID (16 octets) | 232 | | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 | remaining SIDs (16 octets each) | 237 | | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | MBZ (8 octets) | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 | HMAC (16 octets) | 245 | | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 The Number of sessions field indicates the count of sessions that 250 this Stop command applies to. The SID is as defined in OWAMP (and 251 TWAMP) section 3.5 [RFC4656]. 253 3.4. SERVWAIT Timer Operation 255 Section 3.1 of [I-D.ietf-ippm-twamp] describes the operation of the 256 optional SERVWAIT timer. In normal TWAMP operation, the Server 257 suspends monitoring the SERVWAIT timer while test sessions are in 258 progress. When the Individual Session Control feature is utilized, 259 this suspension is extended to cover the time when ANY test session 260 is in progress. 262 Thus, the Server SHALL suspend monitoring control connection activity 263 after receiving any Start-Sessions command, and SHALL resume after 264 receiving a Stop-Sessions command for all corresponding SIDs (and no 265 test sessions are in-progress). 267 3.5. Additional considerations 269 The value of the Modes field sent by the Server (in the Server 270 Greeting message) is the bit-wise OR of the mode values that it is 271 willing to support during this session. 273 If this feature is adopted, the last seven bits of the Modes 32-bit 274 field are used. The first 25 bits MUST be zero. A client conforming 275 to this version of the specification MUST ignore the values in the 276 first 25 bits of the Modes value. (This way, the bits are available 277 for future protocol extensions.) 279 Other ways in which TWAMP extends OWAMP are described in 280 [I-D.ietf-ippm-twamp]. 282 4. TWAMP Test with Individual Session Control 284 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 285 protocol with the exception that the Session-Reflector transmits test 286 packets to the Session-Sender in response to each test packet it 287 receives. TWAMP [I-D.ietf-ippm-twamp] defines two different test 288 packet formats, one for packets transmitted by the Session-Sender and 289 one for packets transmitted by the Session-Reflector. As with OWAMP- 290 Test protocol there are three security modes: unauthenticated, 291 authenticated, and encrypted. Unauthenticated mode has one test 292 packet format, while authenticated and encrypted modes use another 293 (common) format. 295 4.1. Sender Behavior 297 The individual session control feature requires that the sender MUST 298 manage test sessions according to their SID. Otherwise, the sender 299 behavior is as describe in section 4.1 of [I-D.ietf-ippm-twamp]. 301 4.2. Reflector Behavior 303 The TWAMP Reflector follows the procedures and guidelines in section 304 4.2 of [I-D.ietf-ippm-twamp], with the following additional functions 305 required by this feature: 307 o The session reflector MUST manage test sessions according to their 308 SID. 310 o Packets for a specific session/SID not received within the Timeout 311 (following the Stop-Session command) MUST be ignored by the 312 Reflector. The Session-Reflector MUST NOT generate a test packet 313 to the Session-Sender for packets that are ignored. 315 o If the optional REFWAIT timer is implemented, it SHOULD be 316 enforced when any test session is in-progress (started and not 317 stopped). 319 5. Security Considerations 321 These extended modes of operation permit stronger integrity 322 protection on the TWAMP-Control protocol while simultaneously 323 emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus 324 enhancing overall security when compared to the previous options. 326 The security considerations that apply to any active measurement of 327 live networks are relevant here as well. See the security 328 considerations in[RFC4656] and [I-D.ietf-ippm-twamp]. 330 6. IANA Considerations 332 This memo requests assignment of one mode bit position/value to the 333 IANA registry for the TWAMP Mode field, and describes behavior when 334 the new mode is used. This field is a recognized extension mechanism 335 for TWAMP. 337 This memo also requests assignment of two command numbers in the 338 TWAMP-Control Command Number registry, and describes the use of the 339 new commands. The command number field is a recognized extension 340 mechanism for TWAMP. 342 6.1. Registry Specification 344 IANA has created a TWAMP-Modes registry (as requested in 345 [I-D.morton-ippm-more-twamp]). TWAMP-Modes are specified in TWAMP 346 Server Greeting messages and Set-up Response messages, as described 347 in section 3.1 of [I-D.ietf-ippm-twamp], consistent with section 3.1 348 of [RFC4656], and extended by this memo. Modes are indicated by 349 setting bits in the 32-bit Modes field. Thus, this registry can 350 contain a total of 32 possible values. 352 IANA has also created a TWAMP-Control Command Number registry. 354 TWAMP-Control commands are specified by the first octet in TWAMP- 355 Control messages as specified in section 3.5 of 356 [I-D.ietf-ippm-twamp], and augmented by this memo. This registry may 357 contain sixteen possible values. 359 6.2. Registry Management 361 Because the TWAMP-Control Command Number registry can contain only 362 sixteen values, TWAMP-Modes can only contain thirty-two values, and 363 because TWAMP is an IETF protocol, these registries must be updated 364 only by "IETF Consensus" as specified in [RFC2434](an RFC documenting 365 registry use that is approved by the IESG). Management of these 366 registries is described in section 8.2 of [I-D.ietf-ippm-twamp] and 367 [I-D.morton-ippm-more-twamp]. 369 This memo proposes assignment of values 7 and 8. 371 6.3. Experimental Numbers 373 One experimental value has been assigned in the TWAMP-Control Command 374 Number registry. 376 No additional experimental values are assigned in the TWAMP-Modes 377 registry. 379 6.4. Registry Contents 381 TWAMP-Control Command Number Registry 383 Value Description Semantics Definition 384 0 Reserved 385 1 Forbidden 386 2 Start-Sessions RFC4656, Section 3.7 387 3 Stop-Sessions RFC4656, Section 3.8 388 4 Reserved 389 5 Request-TW-Session draft-ietf-ippm-twamp, Section 3.5 390 6 Experimentation draft-ietf-ippm-twamp, Section 8.3 391 ------------------------------------------------------------------ 392 7 Start-Sessions with this memo, Section 3.2 393 Individ. Session Cntrl. 394 8 Stop-Sessions with this memo, Section 3.3 395 Individ. Session Cntrl. 397 TWAMP-Modes Registry 398 Value Description Reference/Explanation 399 0 Reserved 400 1 Unauthenticated RFC4656, Section 3.1 401 2 Authenticated RFC4656, Section 3.1 402 4 Encrypted RFC4656, Section 3.1 403 8 Unauth. TEST protocol, draft-...-more-twamp (3) 404 Auth. CONTROL 405 16 Unauth. TEST protocol, draft-...-more-twamp (4) 406 Encrypted CONTROL 407 32 Auth. TEST protocol, draft-...-more-twamp (5) 408 Encrypted CONTROL 409 -------------------------------------------------------- 410 zzz Individual Session this memo, Section 3.1 411 Control bit position (Z) 413 7. Acknowledgements 415 The author would like to thank Murtaza Chiba for suggesting this 416 feature. 418 8. References 420 8.1. Normative References 422 [I-D.ietf-ippm-twamp] 423 Babiarz, J., "A Two-way Active Measurement Protocol 424 (TWAMP)", draft-ietf-ippm-twamp-08 (work in progress), 425 June 2008. 427 [I-D.morton-ippm-more-twamp] 428 Morton, A. and K. Hedayat, "More Features for TWAMP", 429 draft-morton-ippm-more-twamp-00 (work in progress), 430 February 2008. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 436 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 437 October 1998. 439 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 440 Zekauskas, "A One-way Active Measurement Protocol 441 (OWAMP)", RFC 4656, September 2006. 443 8.2. Informative References 445 [x] "". 447 Author's Address 449 Al Morton 450 AT&T Labs 451 200 Laurel Avenue South 452 Middletown,, NJ 07748 453 USA 455 Phone: +1 732 420 1571 456 Fax: +1 732 368 1192 457 Email: acmorton@att.com 458 URI: http://home.comcast.net/~acmacm/ 460 Full Copyright Statement 462 Copyright (C) The IETF Trust (2008). 464 This document is subject to the rights, licenses and restrictions 465 contained in BCP 78, and except as set forth therein, the authors 466 retain all their rights. 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 471 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 472 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 473 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Intellectual Property 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org.