idnits 2.17.1 draft-ietf-ippm-twamp-session-cntrl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2009) is 5528 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 689, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ippm-more-twamp-00 == Outdated reference: A later version (-09) exists of draft-ietf-ippm-twamp-reflect-octets-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 M. Chiba 5 Expires: September 7, 2009 Cisco Systems 6 March 6, 2009 8 Individual Session Control Feature for TWAMP 9 draft-ietf-ippm-twamp-session-cntrl-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 7, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The IETF has completed its work on the core specification of TWAMP - 58 the Two-Way Active Measurement Protocol. This memo describes a new 59 feature for TWAMP, that gives the controlling host the ability to 60 start and stop one or more individual test sessions using Session 61 Identifiers. The base capability of the TWAMP protocol requires all 62 test sessions previously requested and accepted to start and stop at 63 the same time. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 75 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 76 3.1. Connection Setup with Individual Session Control . . . . . 5 77 3.2. Start-N-Sessions Command with Individual Session 78 Control . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.3. Start-N-Ack Command with Individual Session Control . . . 8 80 3.4. Stop-N-Sessions Command with Individual Session Control . 10 81 3.5. Stop-N-Ack Command with Individual Session Control . . . . 11 82 3.6. SERVWAIT Timeout Operation . . . . . . . . . . . . . . . . 13 83 3.7. Additional considerations . . . . . . . . . . . . . . . . 13 84 4. TWAMP Test with Individual Session Control . . . . . . . . . . 14 85 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 14 86 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 15 90 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 15 91 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 15 92 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 16 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 The IETF has completed its work on the core specification of TWAMP - 102 the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an 103 extension of the One-way Active Measurement Protocol, OWAMP 104 [RFC4656]. The TWAMP specification gathered wide review as it 105 approached completion, and the by-products were several 106 recommendations for new features in TWAMP. There are a growing 107 number of TWAMP implementations at present, and wide-spread usage is 108 expected. There are even devices that are designed to test 109 implementations for protocol compliance. 111 This memo describes a new feature for TWAMP. TWAMP (and OWAMP) start 112 all previously requested and accepted test sessions at once. This 113 feature allows the Control-Client to control individual test sessions 114 on the basis of their Session Identifier (SID). This feature permits 115 a short duration TWAMP test to start (and/or stop) during a longer 116 test. This feature permits a specific diagnostic test to begin if 117 intermediate results indicate that the test is warranted, for 118 example. 120 This feature requires a Mode bit position assignment and the 121 assignment of two new TWAMP command numbers (for the augmented Start 122 and Stop commands). This feature also specifies a new Stop-ACK 123 Server response, to complete the symmetry of the session stopping 124 process in the same way as the Start-ACK response. 126 Implementers of this feature may also wish to implement the "Reflect 127 Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets]. 128 This feature allows a Control-Client to insert a locally-specified 129 request number into the Request-TW-Session command (in octets 130 originally designated MBZ=Must Be Zero), and a compliant Server will 131 return the request number in its reply (Accept message). 133 This memo is intended to be an update to the TWAMP RFC. 135 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 136 to zero by senders and MUST be ignored by receivers. 138 2. Purpose and Scope 140 The purpose of this memo is to describe an additional function and 141 feature for TWAMP [RFC5357]. The feature needs a clear description 142 so it can be discussed and (hopefully) adopted in the IP Performance 143 Metrics Charter. 145 The scope of the memo is currently limited to specifications of the 146 following features: 148 1. Extension of the modes of operation through assignment of a new 149 value in the Mode field to communicate feature capability and 150 use, 152 2. the definitions of augmented start session and stop session 153 commands (with corresponding acknowledgements), and 155 3. the definition of related procedures for TWAMP entities. 157 The motivation for this feature is the ability to start and stop 158 individual test sessions at will, using a single TWAMP-control 159 connection. 161 3. TWAMP Control Extensions 163 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 164 and provides two-way measurement capability. TWAMP [RFC5357] uses 165 the Modes Field to identify and select specific communication 166 capabilities, and this field is a recognized extension mechanism. 167 The following sections describe one such extension. 169 3.1. Connection Setup with Individual Session Control 171 TWAMP-Control connection establishment follows the procedure defined 172 in section 3.1 of [RFC4656] OWAMP. The Individual Session Control 173 mode requires one new bit position (and value) to identify the 174 ability of the Server/Session-Reflector to start and stop specific 175 sessions (according to their Session Identifier, or SID). This new 176 feature requires an additional TWAMP mode bit assignment as follows: 178 Value Description Reference/Explanation 179 0 Reserved 180 1 Unauthenticated RFC4656, Section 3.1 181 2 Authenticated RFC4656, Section 3.1 182 4 Encrypted RFC4656, Section 3.1 183 8 Unauth. TEST protocol, draft-...-more-twamp (3) 184 Auth. CONTROL 185 -------------------------------------------------------- 186 zzz Individual Session this memo, bit position (Z) 187 Control 189 In the original OWAMP mode field, setting bit positions 0, 1 or 2 190 indicated the security mode of the Control protocol, and the Test 191 protocol inherited the same mode (see section 4 of [RFC4656]). In 192 the [I-D.ietf-ippm-more-twamp] memo, bit position (3) allows a 193 different security mode in the Test protocol and uses the 194 unauthenticated test packet format. 196 If the Server sets the new bit position (bit position Z) in the 197 Server Greeting message to indicate its capabilities, then the Server 198 and Session-Reflector MUST comply with the requirements of this memo 199 to control sessions on an individual basis if desired. 201 If the Control-Client intends to control sessions on an individual 202 basis (according to the requirements in this memo), it MUST set the 203 mode bit (Z, corresponding to the new mode) in the Setup Response 204 message. This means that: 206 1. The Control-Client and the Server MUST use the start and stop 207 commands intended for individual session control and the 208 corresponding acknowledgements, as defined in the sections that 209 follow. 211 2. The Control-Client and the Server MUST NOT use the start and stop 212 commands (2 and 3) and the acknowledgement defined in [RFC5357]. 214 The Control-Client MUST also set one mode bit to indicate the chosen 215 security mode (currently bits 0, 1, 2, or 3), consistent with the 216 modes offered by the Server. The Control-Client MAY also set Modes 217 bit Z with other features and bit positions (such as the reflect 218 octets feature). 220 If the Control-Client has selected the Reflect Octets feature 221 [I-D.ietf-ippm-twamp-reflect-octets] in combination with the 222 Individual Session Control feature (after the Server identified its 223 capability), AND utilizes the feature to insert a locally-specified 224 request number in the Request-TW-Session command, THEN the Control 225 Client MAY send more than one Request-TW-Session command to a given 226 Server without waiting for the corresponding Accept-Session message. 227 In such a case the Access-Session response reflects the locally- 228 specified request number. Note that when the Reflect Octets feature 229 is being used all Request-TW-Session command and Accept-Session 230 responses MUST include the locally-specified request number. 232 3.2. Start-N-Sessions Command with Individual Session Control 234 Having 236 o initiated Individual Session Control mode in the Setup Response, 238 o requested one or more test sessions, and 239 o received affirmative Accept-Session response(s), 241 a TWAMP Client MAY start the execution of one or more test sessions 242 by sending a Start-N-Sessions message to the Server (note that "N" 243 indicates that this command is applicable to one or more sessions, 244 and does not change with the number of sessions identified in the 245 command). 247 The format of the Start-N-Sessions message is as follows: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 252 | 7 | | 253 +-+-+-+-+-+-+-+-+ + 254 | MBZ (11 octets) | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Number of Sessions | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 259 | | 260 | First SID (16 octets) | 261 | | 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 264 | | 265 . remaining SIDs (16 octets each) . 266 . . 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 269 | | 270 | HMAC (16 octets) | 271 | | 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 275 The Command Number value of 7 indicates that this is a Start-N- 276 Sessions command. The Control-Client MUST compose this command, and 277 the Server MUST interpret this command, according to the field 278 descriptions below. 280 The Number of Sessions field indicates the count of sessions that 281 this Start command applies to, and must be one or greater. The 282 number of SID fields that follow MUST be equal to the value in the 283 Number of Sessions field (otherwise, the command MUST NOT be affirmed 284 with a zero Accept field in the Start-N-Ack response). 286 All SID fields are constructed as defined in the last paragraph of 287 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 288 SID is assigned by the Server during the session request exchange. 290 The message is terminated with a single block HMAC, as illustrated 291 above. 293 The Server MUST respond with one or more Start-N-Ack messages (which 294 SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL 295 have the format defined in the next session. 297 <<<<< Comment: Al thinks we don't need the limitation below now, 298 unless it refers to the EXISTING Start-Sessions command. The real 299 question is, Do we require (MUST) the use of the -N- commands in 300 Indiv.Sess.Cntrl mode, or allow both types??? I'm leaning toward -N- 301 commands ONLY. >>>> The Control Client MUST NOT send a subsequent 302 Start Sessions command until an outstanding message is acknowledged 303 with a Start-Ack message. 305 When using Individual Session Control mode and its Start-N-Ack 306 command as described in the next section, multiple Start-N-Sessions 307 commands MAY be sent without waiting for acknowledgement, and the 308 Start-N-sessions commands MAY arrive in any order. 310 3.3. Start-N-Ack Command with Individual Session Control 312 The Server responds to the Start-N-Sessions command (for one or more 313 specific sessions referenced by their SIDs) with one or more Start-N- 314 Ack commands with Accept fields corresponding to one or more of the 315 SIDs. This allows for the possibility that a Server cannot 316 immediately start one or more the sessions referenced in a particular 317 Start-N-Sessions command, but can start one or more of the sessions. 319 The format of the message is as follows. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 324 | 8 | Accept | MBZ | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | MBZ (8 octets) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Number of Sessions | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 331 | | 332 | First SID (16 octets) | 333 | | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 336 | | 337 . remaining SIDs (16 octets each) . 338 . . 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 341 | | 342 | HMAC (16 octets) | 343 | | 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 The Command Number value of 8 indicates that this is a Start-N-Ack 348 message. The Server MUST compose this command, and the Control- 349 Client MUST interpret this command, according to the field 350 descriptions below. 352 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 354 The Number of Sessions field indicates the count of sessions that 355 this Start-N-Ack command applies to, and must be one or greater. The 356 number of SID fields that follow MUST be equal to the value in the 357 Number of Sessions field. 359 All SID fields are constructed as defined in the last paragraph of 360 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 361 SID is assigned by the Server during the session request exchange. 363 The message is terminated with a single block HMAC, as illustrated 364 above. 366 Note that the SIDs for all Sessions with the same 'Accept' code can 367 be acknowledged using the same Start-N-Ack message. 369 For example, say that the Server receives a Start-N-Sessions command 370 for SIDs 1, 2, 3, and 4. The Server determines that the resources 371 for SID=3 are temporarily unavailable. The Server responds with two 372 Start-N-Ack commands with fields as follows: 374 Accept = 0 Number of Sessions = 3 SIDs 1, 2, 4 376 Accept = 5 Number of Sessions = 1 SID 3 378 3.4. Stop-N-Sessions Command with Individual Session Control 380 The Stop-N-Sessions command can only be issued by the Control-Client. 381 The command MUST contain at least one SID. 383 The TWAMP Stop-N-Sessions command for use in Individual Session 384 Control mode is formatted as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 389 | 9 | | 390 +-+-+-+-+-+-+-+-+ + 391 | MBZ (11 octets) | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Number of Sessions | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 396 | | 397 | First SID (16 octets) | 398 | | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 401 | | 402 . remaining SIDs (16 octets each) . 403 . . 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 406 | | 407 | HMAC (16 octets) | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 412 The Command Number value of 9 indicates that this is a Stop-N- 413 Sessions command. The Control-Client MUST compose this command, and 414 the Server MUST interpret this command, according to the field 415 descriptions below. 417 The Number of sessions field indicates the count of sessions that 418 this Stop-N-Sessions command applies to. The SID is as defined in 419 OWAMP (and TWAMP) section 3.5 [RFC4656] and the value must be one or 420 greater. The number of SID fields that follow MUST be equal to the 421 value in the Number of Sessions field. 423 The message is terminated with a single block HMAC, as illustrated 424 above. 426 The Server MUST respond with one or more Stop-N-Ack messages (which 427 SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL 428 have the format defined in the next session. 430 3.5. Stop-N-Ack Command with Individual Session Control 432 In response to the Stop-N-Sessions command (for one or more specific 433 sessions referenced by their SIDs), the Server MUST reply with one or 434 more Stop-N-Ack commands with Accept fields corresponding to one or 435 more of the SIDs. This allows for the possibility that a Server 436 cannot immediately stop one or more the sessions referenced in a 437 particular Stop-N-Sessions command, but can stop one or more of the 438 sessions. 440 The format for the Stop-N-Ack command is as follows: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 445 | 10 | Accept | MBZ | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | MBZ (8 octets) | 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Number of Sessions | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 452 | | 453 | First SID (16 octets) | 454 | | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 457 | | 458 . remaining SIDs (16 octets each) . 459 . . 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 462 | | 463 | HMAC (16 octets) | 464 | | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 The Command Number value of 10 indicates that this is a Stop-N-Ack 469 message. The Server MUST compose this command, and the Control- 470 Client MUST interpret this command, according to the field 471 descriptions below. 473 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 475 The Number of Sessions field indicates the count of sessions that 476 this Stop-N-Ack command applies to, and must be one or greater. The 477 number of SID fields that follow MUST be equal to the value in the 478 Number of Sessions field. 480 All SID fields are constructed as defined in the last paragraph of 481 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 482 SID is assigned by the Server during the session request exchange. 484 The message is terminated with a single block HMAC, as illustrated 485 above. 487 Note that the SIDs for all Sessions with the same 'Accept' code can 488 be acknowledged using the same Stop-N-Ack message. 490 3.6. SERVWAIT Timeout Operation 492 Section 3.1 of [RFC5357] describes the operation of the optional 493 SERVWAIT timer. In normal TWAMP operation, the Server suspends 494 monitoring the SERVWAIT timer while test sessions are in progress. 495 When the Individual Session Control feature is utilized, this 496 suspension is extended to cover the time when ANY test session is in 497 progress. 499 Thus, the Server SHALL suspend monitoring control connection activity 500 after receiving any Start-N-Sessions command, and after receiving a 501 Stop-N-Sessions command for all corresponding SIDs (and no test 502 sessions are in-progress), OR when REFWAIT expires on ALL test 503 sessions initiated by a TWAMP-Control connection, then the SERVWAIT 504 monitoring SHALL resume (as though a Stop-N-Sessions command had been 505 received). An implementation which supports the SERVWAIT timeout 506 option SHOULD also implement the REFWAIT timeout option. 508 The diagram below illustrates the operation of timers SERVWAIT and 509 REFWAIT. 511 SERVWAIT REFWAIT SERVWAIT 512 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 513 (no sessions 514 in-progress) 515 +-+-+-+-+-+-+-+-+-+-+-+ 516 SID="1" 518 +-+-+-+-+ 519 SID="2" 521 +-+-+-+-+-+-+-+-+ 522 SID="3" 524 >>>>>>>>>> Time >>>>>>>>>>>>>>>>>>> Time >>>>>>>>>>>>>>>> Time >>>>> 526 3.7. Additional considerations 528 The value of the Modes field sent by the Server (in the Server 529 Greeting message) is the bit-wise OR of the mode values that it is 530 willing to support during this session. 532 If this feature is adopted, the last ???? bits of the Modes 32-bit 533 field are used. A Control-Client MAY ignore other bit positions 534 greater than 2 in the Modes Field, or it MAY support other features 535 that are communicated in these bit positions. (The unassigned bits 536 are available for future protocol extensions.) 537 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 539 4. TWAMP Test with Individual Session Control 541 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 542 protocol with the exception that the Session-Reflector transmits test 543 packets to the Session-Sender in response to each test packet it 544 receives. TWAMP [RFC5357] defines two different test packet formats, 545 one for packets transmitted by the Session-Sender and one for packets 546 transmitted by the Session-Reflector. As with OWAMP-Test protocol 547 there are three security modes: unauthenticated, authenticated, and 548 encrypted. Unauthenticated mode has one test packet format, while 549 authenticated and encrypted modes use another (common) format. 551 4.1. Sender Behavior 553 The individual session control feature requires that the sender MUST 554 manage test sessions according to their SID. Otherwise, the sender 555 behavior is as described in section 4.1 of [RFC5357]. 557 4.2. Reflector Behavior 559 The TWAMP Reflector follows the procedures and guidelines in section 560 4.2 of [RFC5357], with the following additional functions required by 561 this feature: 563 o The Session-Reflector MUST manage all test sessions accepted 564 according to their SID. 566 o Upon receipt of a TWAMP-Control Stop-N-Sessions command 567 referencing a specific session/SID, the Session-Reflector MUST 568 ignore TWAMP-Test packets (in the same session/SID) that arrive at 569 the current time plus the Timeout (in the Request-TW-Session 570 command and assuming subsequent acknowledgement). The Session- 571 Reflector MUST NOT generate a test packet to the Session-Sender 572 for packets that are ignored. 574 o If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be 575 enforced when any test session is in-progress (started and not 576 stopped). 578 5. Security Considerations 580 The security considerations that apply to any active measurement of 581 live networks are relevant here as well. See the security 582 considerations in[RFC4656] and [RFC5357]. 584 6. IANA Considerations 586 This memo requests assignment of one mode bit position/value to the 587 IANA registry for the TWAMP Mode field, and describes behavior when 588 the new mode is used. This field is a recognized extension mechanism 589 for TWAMP. 591 This memo also requests assignment of four command numbers in the 592 TWAMP-Control Command Number registry, and describes the use of the 593 new commands. The command number field is a recognized extension 594 mechanism for TWAMP. 596 6.1. Registry Specification 598 IANA has created a TWAMP-Modes registry (as requested in 599 [I-D.ietf-ippm-more-twamp]). TWAMP-Modes are specified in TWAMP 600 Server Greeting messages and Set-up Response messages, as described 601 in section 3.1 of [RFC5357], consistent with section 3.1 of 602 [RFC4656], and extended by this memo. Modes are indicated by setting 603 bits in the 32-bit Modes field. Thus, this registry can contain a 604 total of 32 possible values. 606 IANA has also created a TWAMP-Control Command Number registry. 607 TWAMP-Control commands are specified by the first octet in TWAMP- 608 Control messages as specified in section 3.5 of [RFC5357], and 609 augmented by this memo. This registry may contain 256 possible 610 values. 612 6.2. Registry Management 614 Because the TWAMP-Control Command Number registry can contain only 615 256 values and TWAMP-Modes can only contain thirty-two values, and 616 because TWAMP is an IETF protocol, these registries must be updated 617 only by "IETF Consensus" as specified in [RFC2434](an RFC documenting 618 registry use that is approved by the IESG). Management of these 619 registries is described in section 8.2 of [RFC5357] and 620 [I-D.ietf-ippm-more-twamp]. 622 This memo proposes assignment of values 7, 8, 9 and 10 in the Command 623 number Registry, and the next available bit position (indicated by 624 "Z") and corresponding value (indicated by "zzz") in section 3.1 625 above. Note that these values should be replaced by IANA or the RFC 626 Editor when assigned. 628 6.3. Experimental Numbers 630 One experimental value has been assigned in the TWAMP-Control Command 631 Number registry. 633 No additional experimental values are assigned in the TWAMP-Modes 634 registry. 636 6.4. Registry Contents 638 TWAMP-Control Command Number Registry 640 Value Description Semantics Definition 641 0 Reserved 642 1 Forbidden 643 2 Start-Sessions RFC4656, Section 3.7 644 3 Stop-Sessions RFC4656, Section 3.8 645 4 Reserved 646 5 Request-TW-Session RFC5357, Section 3.5 647 6 Experimentation RFC5357, Section 8.3 648 ------------------------------------------------------------------ 649 7 Start-N-Sessions this memo, Section 3.2 650 8 Start-N-Ack this memo, Section 3.3 651 9 Stop-N-Sessions this memo, Section 3.4 652 10 Stop-N-Ack this memo, Section 3.5 654 TWAMP-Modes Registry 656 Value Description Reference/Explanation 657 0 Reserved 658 1 Unauthenticated RFC4656, Section 3.1 659 2 Authenticated RFC4656, Section 3.1 660 4 Encrypted RFC4656, Section 3.1 661 8 Unauth. TEST protocol, draft-...-more-twamp (3) 662 Auth. CONTROL 663 -------------------------------------------------------- 664 zzz Individual Session this memo, Section 3.1 665 Control bit position (Z) 667 7. Acknowledgements 669 The author would like to thank anyone who provides valuable comments 670 on this feature. 672 8. References 674 8.1. Normative References 676 [I-D.ietf-ippm-more-twamp] 677 Morton, A. and K. Hedayat, "More Features for TWAMP", 678 draft-ietf-ippm-more-twamp-00 (work in progress), 679 October 2008. 681 [I-D.ietf-ippm-twamp-reflect-octets] 682 Morton, A. and L. Ciavattone, "TWAMP Reflect Octets 683 Feature", draft-ietf-ippm-twamp-reflect-octets-00 (work in 684 progress), October 2008. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 691 October 1998. 693 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 694 Zekauskas, "A One-way Active Measurement Protocol 695 (OWAMP)", RFC 4656, September 2006. 697 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 698 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 699 RFC 5357, October 2008. 701 8.2. Informative References 703 [x] "". 705 Authors' Addresses 707 Al Morton 708 AT&T Labs 709 200 Laurel Avenue South 710 Middletown,, NJ 07748 711 USA 713 Phone: +1 732 420 1571 714 Fax: +1 732 368 1192 715 Email: acmorton@att.com 716 URI: http://home.comcast.net/~acmacm/ 717 Murtaza Chiba 718 Cisco Systems 719 170 W. Tasman Drive 720 San Jose, 95134 721 USA 723 Phone: +1 800 553 NETS 724 Fax: +1 725 Email: mchiba@cisco.com 726 URI: