idnits 2.17.1 draft-ietf-ippm-twamp-session-cntrl-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5357, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5357, updated by this document, for RFC5378 checks: 2005-11-11) -- 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 (February 28, 2010) is 5170 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-twamp-reflect-octets-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 Updates: 5357 (if approved) M. Chiba 5 Intended status: Standards Track Cisco Systems 6 Expires: September 1, 2010 February 28, 2010 8 Individual Session Control Feature for TWAMP 9 draft-ietf-ippm-twamp-session-cntrl-04 11 Abstract 13 The IETF has completed its work on the core specification of TWAMP - 14 the Two-Way Active Measurement Protocol. This memo describes an 15 OPTIONAL feature for TWAMP, that gives the controlling host the 16 ability to start and stop one or more individual test sessions using 17 Session Identifiers. The base capability of the TWAMP protocol 18 requires all test sessions previously requested and accepted to start 19 and stop at the same time. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 1, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 81 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 82 3.1. Connection Setup with Individual Session Control . . . . . 4 83 3.2. Start-N-Sessions Command with Individual Session 84 Control . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.3. Start-N-Ack Command with Individual Session Control . . . 8 86 3.4. Stop-N-Sessions Command with Individual Session Control . 9 87 3.5. Stop-N-Ack Command with Individual Session Control . . . . 10 88 3.6. SERVWAIT Timeout Operation . . . . . . . . . . . . . . . . 12 89 3.7. Additional considerations . . . . . . . . . . . . . . . . 13 90 4. TWAMP Test with Individual Session Control . . . . . . . . . . 13 91 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 13 92 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 13 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 14 96 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 14 97 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 15 98 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 15 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 102 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 The IETF has completed its work on the core specification of TWAMP - 108 the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an 109 extension of the One-way Active Measurement Protocol, OWAMP 110 [RFC4656]. The TWAMP specification gathered wide review as it 111 approached completion, and the by-products were several 112 recommendations for new features in TWAMP. There are a growing 113 number of TWAMP implementations at present, and wide-spread usage is 114 expected. There are even devices that are designed to test 115 implementations for protocol compliance. 117 This memo describes an OPTIONAL feature for TWAMP. TWAMP (and OWAMP) 118 start all previously requested and accepted test sessions at once. 119 This feature allows the Control-Client to control individual test 120 sessions on the basis of their Session Identifier (SID). This 121 feature permits a short duration TWAMP test to start (and/or stop) 122 during a longer test. This feature permits a specific diagnostic 123 test to begin if intermediate results indicate that the test is 124 warranted, for example. 126 This feature requires a Mode bit position assignment and the 127 assignment of two new TWAMP command numbers (for the augmented Start 128 and Stop commands). This feature also specifies a new Stop-ACK 129 Server response, to complete the symmetry of the session stopping 130 process in the same way as the Start-ACK response. 132 Implementers of this feature MAY also wish to implement the "Reflect 133 Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets], 134 once it has been published as an RFC. This feature allows a Control- 135 Client to insert a locally-specified request number into the Request- 136 TW-Session command (in octets originally designated MBZ=Must Be 137 Zero), and a compliant Server will return the request number in its 138 reply (Accept message). 140 This memo is intended to be an update to the TWAMP core protocol 141 specified in [RFC5357]. It is not required to implement the feature 142 described in this memo to claim compliance with [RFC5357]. 144 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 145 to zero by senders and MUST be ignored by receivers. 147 2. Purpose and Scope 149 The purpose of this memo is to describe an additional OPTIONAL 150 function and feature for TWAMP [RFC5357]. The feature needs a clear 151 description so it can be discussed and (hopefully) adopted in the IP 152 Performance Metrics Charter. 154 The scope of the memo is currently limited to specifications of the 155 following features: 157 1. Extension of the modes of operation through assignment of a new 158 value in the Mode field to communicate feature capability and 159 use, 161 2. the definitions of augmented start session and stop session 162 commands (with corresponding acknowledgements), and 164 3. the definition of related procedures for TWAMP entities. 166 The motivation for this feature is the ability to start and stop 167 individual test sessions at will, using a single TWAMP-control 168 connection. 170 When the Server and Control-Client have agreed to use the Individual 171 Session Control mode during control connection setup, then the 172 Control-Client, the Server, the Session-Sender, and the Session- 173 Reflector MUST all conform to the requirements of that mode, as 174 identified below. The original TWAMP-Control Start and Stop commands 175 MUST NOT be used. 177 3. TWAMP Control Extensions 179 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 180 and provides two-way measurement capability. TWAMP [RFC5357] uses 181 the Modes Field to identify and select specific communication 182 capabilities, and this field is a recognized extension mechanism. 183 The following sections describe one such extension. 185 3.1. Connection Setup with Individual Session Control 187 TWAMP-Control connection establishment follows the procedure defined 188 in section 3.1 of [RFC4656] OWAMP. The Individual Session Control 189 mode requires one new bit position (and value) to identify the 190 ability of the Server/Session-Reflector to start and stop specific 191 sessions (according to their Session Identifier, or SID). This new 192 feature requires an additional TWAMP mode bit assignment as follows: 194 Value Description Reference/Explanation 195 0 Reserved 196 1 Unauthenticated RFC4656, Section 3.1 197 2 Authenticated RFC4656, Section 3.1 198 4 Encrypted RFC4656, Section 3.1 199 8 Unauth. TEST protocol, RFC5618, Section 3.1 200 Auth. CONTROL 201 -------------------------------------------------------- 202 zzz Individual Session this memo, bit position (Z) 203 Control 205 In the original OWAMP mode field, setting bit positions 0, 1 or 2 206 indicated the security mode of the Control protocol, and the Test 207 protocol inherited the same mode (see section 4 of [RFC4656]). In 208 the [RFC5618] memo, bit position (3) allows a different security mode 209 in the Test protocol and uses the unauthenticated test packet format. 211 If the Server sets the new bit position (bit position Z) in the 212 Server Greeting message to indicate its capabilities, then the Server 213 and Session-Reflector MUST comply with the requirements of this memo 214 to control sessions on an individual basis if desired. 216 If the Control-Client intends to control sessions on an individual 217 basis (according to the requirements in this memo), it MUST set the 218 mode bit (Z, corresponding to the new mode) in the Setup Response 219 message. This means that: 221 1. The Control-Client and the Server MUST use the start and stop 222 commands intended for individual session control and the 223 corresponding acknowledgements, as defined in the sections that 224 follow. 226 2. The Control-Client and the Server MUST NOT use the start and stop 227 commands (2 and 3) and the acknowledgement defined in [RFC5357]. 229 The Control-Client MUST also set one mode bit to indicate the chosen 230 security mode (currently bits 0, 1, 2, or 3), consistent with the 231 modes offered by the Server. The Control-Client MAY also set Modes 232 bit Z with other features and bit positions (such as the reflect 233 octets feature). 235 If the Control-Client has selected the Reflect Octets feature 236 [I-D.ietf-ippm-twamp-reflect-octets] in combination with the 237 Individual Session Control feature (after the Server identified its 238 capability), AND utilizes the feature to insert a locally-specified 239 request number in the Request-TW-Session command, THEN the Control 240 Client MAY send more than one Request-TW-Session command to a given 241 Server without waiting for the corresponding Accept-Session message. 242 In such a case the Access-Session response reflects the locally- 243 specified request number. Note that when the Reflect Octets feature 244 is being used all Request-TW-Session command and Accept-Session 245 responses MUST include the locally-specified request number. 247 3.2. Start-N-Sessions Command with Individual Session Control 249 Having 251 o initiated Individual Session Control mode in the Setup Response, 253 o requested one or more test sessions, and 255 o received affirmative Accept-Session response(s), 257 a TWAMP Client MAY start the execution of one or more test sessions 258 by sending a Start-N-Sessions message to the Server (note that "N" 259 indicates that this command is applicable to one or more sessions, 260 and does not change with the number of sessions identified in the 261 command). 263 The format of the Start-N-Sessions message is as follows: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 268 | 7 | | 269 +-+-+-+-+-+-+-+-+ + 270 | MBZ (11 octets) | 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Number of Sessions | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 275 | | 276 | First SID (16 octets) | 277 | | 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 280 | | 281 . remaining SIDs (16 octets each) . 282 . . 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 285 | | 286 | HMAC (16 octets) | 287 | | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 291 The Command Number value of 7 indicates that this is a Start-N- 292 Sessions command. The Control-Client MUST compose this command, and 293 the Server MUST interpret this command, according to the field 294 descriptions below. 296 The Number of Sessions field indicates the count of sessions that 297 this Start command applies to, and must be one or greater. The 298 number of SID fields that follow MUST be equal to the value in the 299 Number of Sessions field (otherwise, the command MUST NOT be affirmed 300 with a zero Accept field in the Start-N-Ack response). 302 All SID fields are constructed as defined in the last paragraph of 303 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 304 SID is assigned by the Server during the session request exchange. 306 The message is terminated with a single block HMAC, as illustrated 307 above. 309 The Server MUST respond with one or more Start-N-Ack messages (which 310 SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL 311 have the format defined in the next session. 313 When using Individual Session Control mode and its Start-N-Ack 314 command as described in the next section, multiple Start-N-Sessions 315 commands MAY be sent without waiting for acknowledgement, and the 316 Start-N-sessions commands MAY arrive in any order. 318 3.3. Start-N-Ack Command with Individual Session Control 320 The Server responds to the Start-N-Sessions command (for one or more 321 specific sessions referenced by their SIDs) with one or more Start-N- 322 Ack commands with Accept fields corresponding to one or more of the 323 SIDs. This allows for the possibility that a Server cannot 324 immediately start one or more the sessions referenced in a particular 325 Start-N-Sessions command, but can start one or more of the sessions. 327 The format of the message is as follows. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 332 | 8 | Accept | MBZ | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | MBZ (8 octets) | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Number of Sessions | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 339 | | 340 | First SID (16 octets) | 341 | | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 344 | | 345 . remaining SIDs (16 octets each) . 346 . . 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 349 | | 350 | HMAC (16 octets) | 351 | | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 The Command Number value of 8 indicates that this is a Start-N-Ack 356 message. The Server MUST compose this command, and the Control- 357 Client MUST interpret this command, according to the field 358 descriptions below. 360 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 362 The Number of Sessions field indicates the count of sessions that 363 this Start-N-Ack command applies to, and must be one or greater. The 364 number of SID fields that follow MUST be equal to the value in the 365 Number of Sessions field. 367 All SID fields are constructed as defined in the last paragraph of 368 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 369 SID is assigned by the Server during the session request exchange. 371 The message is terminated with a single block HMAC, as illustrated 372 above. 374 Note that the SIDs for all Sessions with the same 'Accept' code can 375 be acknowledged using the same Start-N-Ack message. 377 For example, say that the Server receives a Start-N-Sessions command 378 for SIDs 1, 2, 3, and 4. The Server determines that the resources 379 for SID=3 are temporarily unavailable. The Server responds with two 380 Start-N-Ack commands with fields as follows: 382 Accept = 0 Number of Sessions = 3 SIDs 1, 2, 4 384 Accept = 5 Number of Sessions = 1 SID 3 386 3.4. Stop-N-Sessions Command with Individual Session Control 388 The Stop-N-Sessions command can only be issued by the Control-Client. 389 The command MUST contain at least one SID. 391 The TWAMP Stop-N-Sessions command for use in Individual Session 392 Control mode is formatted as follows: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 397 | 9 | | 398 +-+-+-+-+-+-+-+-+ + 399 | MBZ (11 octets) | 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Number of Sessions | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 404 | | 405 | First SID (16 octets) | 406 | | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 409 | | 410 . remaining SIDs (16 octets each) . 411 . . 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 414 | | 415 | HMAC (16 octets) | 416 | | 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 420 The Command Number value of 9 indicates that this is a Stop-N- 421 Sessions command. The Control-Client MUST compose this command, and 422 the Server MUST interpret this command, according to the field 423 descriptions below. 425 The Number of sessions field indicates the count of sessions that 426 this Stop-N-Sessions command applies to. The SID is as defined in 427 OWAMP (and TWAMP) section 3.5 [RFC4656] and the value must be one or 428 greater. The number of SID fields that follow MUST be equal to the 429 value in the Number of Sessions field. 431 The message is terminated with a single block HMAC, as illustrated 432 above. 434 The Server MUST respond with one or more Stop-N-Ack messages (which 435 SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL 436 have the format defined in the next session. 438 3.5. Stop-N-Ack Command with Individual Session Control 440 In response to the Stop-N-Sessions command (for one or more specific 441 sessions referenced by their SIDs), the Server MUST reply with one or 442 more Stop-N-Ack commands with Accept fields corresponding to one or 443 more of the SIDs. This allows for the possibility that a Server 444 cannot immediately stop one or more the sessions referenced in a 445 particular Stop-N-Sessions command, but can stop one or more of the 446 sessions. 448 The format for the Stop-N-Ack command is as follows: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 453 | 10 | Accept | MBZ | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | MBZ (8 octets) | 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Number of Sessions | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 460 | | 461 | First SID (16 octets) | 462 | | 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 465 | | 466 . remaining SIDs (16 octets each) . 467 . . 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 470 | | 471 | HMAC (16 octets) | 472 | | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 The Command Number value of 10 indicates that this is a Stop-N-Ack 477 message. The Server MUST compose this command, and the Control- 478 Client MUST interpret this command, according to the field 479 descriptions below. 481 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 483 The Number of Sessions field indicates the count of sessions that 484 this Stop-N-Ack command applies to, and must be one or greater. The 485 number of SID fields that follow MUST be equal to the value in the 486 Number of Sessions field. 488 All SID fields are constructed as defined in the last paragraph of 489 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 490 SID is assigned by the Server during the session request exchange. 492 The message is terminated with a single block HMAC, as illustrated 493 above. 495 Note that the SIDs for all Sessions with the same 'Accept' code can 496 be acknowledged using the same Stop-N-Ack message. 498 3.6. SERVWAIT Timeout Operation 500 Section 3.1 of [RFC5357] describes the operation of the optional 501 SERVWAIT timer. In normal TWAMP operation, the Server suspends 502 monitoring the SERVWAIT timer while test sessions are in progress. 503 When the Individual Session Control feature is utilized, this 504 suspension is extended to cover the time when ANY test session is in 505 progress. 507 Thus, the Server SHALL suspend monitoring control connection activity 508 after receiving any Start-N-Sessions command, and after receiving a 509 Stop-N-Sessions command for all corresponding SIDs (and no test 510 sessions are in-progress), OR when REFWAIT expires on ALL test 511 sessions initiated by a TWAMP-Control connection, then the SERVWAIT 512 monitoring SHALL resume (as though a Stop-N-Sessions command had been 513 received). An implementation which supports the SERVWAIT timeout 514 option SHOULD also implement the REFWAIT timeout option. 516 The diagram below illustrates the operation of timers SERVWAIT and 517 REFWAIT. 519 SERVWAIT REFWAIT SERVWAIT 520 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 521 (no sessions 522 in-progress) 523 +-+-+-+-+-+-+-+-+-+-+-+ 524 SID="1" 526 +-+-+-+-+ 527 SID="2" 529 +-+-+-+-+-+-+-+-+ 530 SID="3" 532 >>>>>>>>>> Time >>>>>>>>>>>>>>>>>>> Time >>>>>>>>>>>>>>>> Time >>>>> 534 3.7. Additional considerations 536 The value of the Modes field sent by the Server (in the Server 537 Greeting message) is the bit-wise OR of the mode values that it is 538 willing to support during this session. 540 With the publication of this feature, bit positions 0 through (Z=4) 541 of the Modes 32-bit field are used. A Control-Client MAY ignore bit 542 positions greater than 2 in the Modes Field, or it MAY support 543 OPTIONAL features that are communicated in bit positions 3 and 544 higher. (The unassigned bits are available for future protocol 545 extensions.) 547 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 549 4. TWAMP Test with Individual Session Control 551 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 552 protocol with the exception that the Session-Reflector transmits test 553 packets to the Session-Sender in response to each test packet it 554 receives. TWAMP [RFC5357] defines two different test packet formats, 555 one for packets transmitted by the Session-Sender and one for packets 556 transmitted by the Session-Reflector. As with OWAMP-Test protocol 557 there are three security modes: unauthenticated, authenticated, and 558 encrypted. Unauthenticated mode has one test packet format, while 559 authenticated and encrypted modes use another (common) format. 561 4.1. Sender Behavior 563 The individual session control feature requires that the sender MUST 564 manage test sessions according to their SID. Otherwise, the sender 565 behavior is as described in section 4.1 of [RFC5357]. 567 4.2. Reflector Behavior 569 The TWAMP Reflector follows the procedures and guidelines in section 570 4.2 of [RFC5357], with the following additional functions required by 571 this feature: 573 o The Session-Reflector MUST manage all test sessions accepted 574 according to their SID. 576 o Upon receipt of a TWAMP-Control Stop-N-Sessions command 577 referencing a specific session/SID, the Session-Reflector MUST 578 ignore TWAMP-Test packets (in the same session/SID) that arrive at 579 the current time plus the Timeout (in the Request-TW-Session 580 command and assuming subsequent acknowledgement). The Session- 581 Reflector MUST NOT generate a test packet to the Session-Sender 582 for packets that are ignored. 584 o If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be 585 enforced when any test session is in-progress (started and not 586 stopped). 588 5. Security Considerations 590 The security considerations that apply to any active measurement of 591 live networks are relevant here as well. See the security 592 considerations in[RFC4656] and [RFC5357]. 594 6. IANA Considerations 596 This memo requests assignment of one mode bit position/value to the 597 IANA registry for the TWAMP Mode field, and describes behavior when 598 the new mode is used. This field is a recognized extension mechanism 599 for TWAMP. 601 This memo also requests assignment of four command numbers in the 602 TWAMP-Control Command Number registry, and describes the use of the 603 new commands. The command number field is a recognized extension 604 mechanism for TWAMP. 606 6.1. Registry Specification 608 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 609 TWAMP-Modes are specified in TWAMP Server Greeting messages and 610 Set-up Response messages, as described in section 3.1 of [RFC5357], 611 consistent with section 3.1 of [RFC4656], and extended by this memo. 612 Modes are indicated by setting bits in the 32-bit Modes field. Thus, 613 this registry can contain a total of 32 possible values. 615 IANA has also created a TWAMP-Control Command Number registry. 616 TWAMP-Control commands are specified by the first octet in TWAMP- 617 Control messages as specified in section 3.5 of [RFC5357], and 618 augmented by this memo. This registry may contain 256 possible 619 values. 621 6.2. Registry Management 623 Because the TWAMP-Control Command Number registry can contain only 624 256 values and TWAMP-Modes can only contain thirty-two values, and 625 because TWAMP is an IETF protocol, these registries must be updated 626 only by "IETF Consensus" as specified in [RFC5226] (an RFC 627 documenting registry use that is approved by the IESG). Management 628 of these registries is described in section 8.2 of [RFC5357] and 629 [RFC5618]. 631 This memo proposes assignment of values 7, 8, 9 and 10 in the Command 632 number Registry, and the next available bit position (indicated by 633 "Z") and corresponding value (indicated by "zzz") in sections 3.1 and 634 3.7 above. Note that these values should be replaced by IANA or the 635 RFC Editor when assigned. 637 6.3. Experimental Numbers 639 One experimental value has been assigned in the TWAMP-Control Command 640 Number registry. 642 No additional experimental values are assigned in the TWAMP-Modes 643 registry. 645 6.4. Registry Contents 647 TWAMP-Control Command Number Registry 649 Value Description Semantics Definition 650 0 Reserved 651 1 Forbidden 652 2 Start-Sessions RFC4656, Section 3.7 653 3 Stop-Sessions RFC4656, Section 3.8 654 4 Reserved 655 5 Request-TW-Session RFC5357, Section 3.5 656 6 Experimentation RFC5357, Section 8.3 657 ------------------------------------------------------------------ 658 7 Start-N-Sessions this memo, Section 3.2 659 8 Start-N-Ack this memo, Section 3.3 660 9 Stop-N-Sessions this memo, Section 3.4 661 10 Stop-N-Ack this memo, Section 3.5 663 TWAMP-Modes Registry 664 Value Description Reference/Explanation 665 0 Reserved 666 1 Unauthenticated RFC4656, Section 3.1 667 2 Authenticated RFC4656, Section 3.1 668 4 Encrypted RFC4656, Section 3.1 669 8 Unauth. TEST protocol, RFC5618, Section 3.1 670 Auth. CONTROL 671 -------------------------------------------------------- 672 zzz Individual Session this memo, Section 3.1 673 Control bit position (Z) 674 The suggested values are: 676 Z=4 zzz=16 678 7. Acknowledgements 680 The authors thank everyone who provided comments on this feature. 682 8. References 684 8.1. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 690 Zekauskas, "A One-way Active Measurement Protocol 691 (OWAMP)", RFC 4656, September 2006. 693 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 694 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 695 May 2008. 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 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 702 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 703 August 2009. 705 8.2. Informative References 707 [I-D.ietf-ippm-twamp-reflect-octets] 708 Morton, A. and L. Ciavattone, "TWAMP Reflect Octets and 709 Symmetrical Size Features", 710 draft-ietf-ippm-twamp-reflect-octets-03 (work in 711 progress), October 2009. 713 Authors' Addresses 715 Al Morton 716 AT&T Labs 717 200 Laurel Avenue South 718 Middletown,, NJ 07748 719 USA 721 Phone: +1 732 420 1571 722 Fax: +1 732 368 1192 723 Email: acmorton@att.com 724 URI: http://home.comcast.net/~acmacm/ 726 Murtaza Chiba 727 Cisco Systems 728 170 W. Tasman Drive 729 San Jose, 95134 730 USA 732 Phone: +1 800 553 NETS 733 Fax: +1 734 Email: mchiba@cisco.com 735 URI: