idnits 2.17.1 draft-ietf-ippm-twamp-session-cntrl-03.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 : ---------------------------------------------------------------------------- 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 (February 17, 2010) is 5182 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 (==), 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: August 21, 2010 Cisco Systems 6 February 17, 2010 8 Individual Session Control Feature for TWAMP 9 draft-ietf-ippm-twamp-session-cntrl-03 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 a new 15 feature for TWAMP, that gives the controlling host the ability to 16 start and stop one or more individual test sessions using Session 17 Identifiers. The base capability of the TWAMP protocol requires all 18 test sessions previously requested and accepted to start and stop at 19 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 August 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 81 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 82 3.1. Connection Setup with Individual Session Control . . . . . 5 83 3.2. Start-N-Sessions Command with Individual Session 84 Control . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 3.3. Start-N-Ack Command with Individual Session Control . . . 9 86 3.4. Stop-N-Sessions Command with Individual Session Control . 10 87 3.5. Stop-N-Ack Command with Individual Session Control . . . . 11 88 3.6. SERVWAIT Timeout Operation . . . . . . . . . . . . . . . . 13 89 3.7. Additional considerations . . . . . . . . . . . . . . . . 14 90 4. TWAMP Test with Individual Session Control . . . . . . . . . . 14 91 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 14 92 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 15 96 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 15 97 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 16 98 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 16 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 a new feature for TWAMP. TWAMP (and OWAMP) start 118 all previously requested and accepted test sessions at once. This 119 feature allows the Control-Client to control individual test sessions 120 on the basis of their Session Identifier (SID). This feature permits 121 a short duration TWAMP test to start (and/or stop) during a longer 122 test. This feature permits a specific diagnostic test to begin if 123 intermediate results indicate that the test is warranted, for 124 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 This feature allows a Control-Client to insert a locally-specified 135 request number into the Request-TW-Session command (in octets 136 originally designated MBZ=Must Be Zero), and a compliant Server will 137 return the request number in its reply (Accept message). 139 This memo is intended to be an update to the TWAMP RFC. 141 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 142 to zero by senders and MUST be ignored by receivers. 144 2. Purpose and Scope 146 The purpose of this memo is to describe an additional function and 147 feature for TWAMP [RFC5357]. The feature needs a clear description 148 so it can be discussed and (hopefully) adopted in the IP Performance 149 Metrics Charter. 151 The scope of the memo is currently limited to specifications of the 152 following features: 154 1. Extension of the modes of operation through assignment of a new 155 value in the Mode field to communicate feature capability and 156 use, 158 2. the definitions of augmented start session and stop session 159 commands (with corresponding acknowledgements), and 161 3. the definition of related procedures for TWAMP entities. 163 The motivation for this feature is the ability to start and stop 164 individual test sessions at will, using a single TWAMP-control 165 connection. 167 When the Server and Control-Client have agreed to use the Individual 168 Session Control mode during control connection setup, then the 169 Control-Client, the Server, the Session-Sender, and the Session- 170 Reflector MUST all conform to the requirements of that mode, as 171 identified below. The original TWAMP-Control Start and Stop commands 172 MUST NOT be used. 174 3. TWAMP Control Extensions 176 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 177 and provides two-way measurement capability. TWAMP [RFC5357] uses 178 the Modes Field to identify and select specific communication 179 capabilities, and this field is a recognized extension mechanism. 180 The following sections describe one such extension. 182 3.1. Connection Setup with Individual Session Control 184 TWAMP-Control connection establishment follows the procedure defined 185 in section 3.1 of [RFC4656] OWAMP. The Individual Session Control 186 mode requires one new bit position (and value) to identify the 187 ability of the Server/Session-Reflector to start and stop specific 188 sessions (according to their Session Identifier, or SID). This new 189 feature requires an additional TWAMP mode bit assignment as follows: 191 Value Description Reference/Explanation 192 0 Reserved 193 1 Unauthenticated RFC4656, Section 3.1 194 2 Authenticated RFC4656, Section 3.1 195 4 Encrypted RFC4656, Section 3.1 196 8 Unauth. TEST protocol, RFC5618, Section 3.1 197 Auth. CONTROL 198 -------------------------------------------------------- 199 zzz Individual Session this memo, bit position (Z) 200 Control 202 In the original OWAMP mode field, setting bit positions 0, 1 or 2 203 indicated the security mode of the Control protocol, and the Test 204 protocol inherited the same mode (see section 4 of [RFC4656]). In 205 the [RFC5618] memo, bit position (3) allows a different security mode 206 in the Test protocol and uses the unauthenticated test packet format. 208 If the Server sets the new bit position (bit position Z) in the 209 Server Greeting message to indicate its capabilities, then the Server 210 and Session-Reflector MUST comply with the requirements of this memo 211 to control sessions on an individual basis if desired. 213 If the Control-Client intends to control sessions on an individual 214 basis (according to the requirements in this memo), it MUST set the 215 mode bit (Z, corresponding to the new mode) in the Setup Response 216 message. This means that: 218 1. The Control-Client and the Server MUST use the start and stop 219 commands intended for individual session control and the 220 corresponding acknowledgements, as defined in the sections that 221 follow. 223 2. The Control-Client and the Server MUST NOT use the start and stop 224 commands (2 and 3) and the acknowledgement defined in [RFC5357]. 226 The Control-Client MUST also set one mode bit to indicate the chosen 227 security mode (currently bits 0, 1, 2, or 3), consistent with the 228 modes offered by the Server. The Control-Client MAY also set Modes 229 bit Z with other features and bit positions (such as the reflect 230 octets feature). 232 If the Control-Client has selected the Reflect Octets feature 233 [I-D.ietf-ippm-twamp-reflect-octets] in combination with the 234 Individual Session Control feature (after the Server identified its 235 capability), AND utilizes the feature to insert a locally-specified 236 request number in the Request-TW-Session command, THEN the Control 237 Client MAY send more than one Request-TW-Session command to a given 238 Server without waiting for the corresponding Accept-Session message. 239 In such a case the Access-Session response reflects the locally- 240 specified request number. Note that when the Reflect Octets feature 241 is being used all Request-TW-Session command and Accept-Session 242 responses MUST include the locally-specified request number. 244 3.2. Start-N-Sessions Command with Individual Session Control 246 Having 248 o initiated Individual Session Control mode in the Setup Response, 250 o requested one or more test sessions, and 252 o received affirmative Accept-Session response(s), 254 a TWAMP Client MAY start the execution of one or more test sessions 255 by sending a Start-N-Sessions message to the Server (note that "N" 256 indicates that this command is applicable to one or more sessions, 257 and does not change with the number of sessions identified in the 258 command). 260 The format of the Start-N-Sessions message is as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 265 | 7 | | 266 +-+-+-+-+-+-+-+-+ + 267 | MBZ (11 octets) | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Number of Sessions | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 272 | | 273 | First SID (16 octets) | 274 | | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 277 | | 278 . remaining SIDs (16 octets each) . 279 . . 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 282 | | 283 | HMAC (16 octets) | 284 | | 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 288 The Command Number value of 7 indicates that this is a Start-N- 289 Sessions command. The Control-Client MUST compose this command, and 290 the Server MUST interpret this command, according to the field 291 descriptions below. 293 The Number of Sessions field indicates the count of sessions that 294 this Start command applies to, and must be one or greater. The 295 number of SID fields that follow MUST be equal to the value in the 296 Number of Sessions field (otherwise, the command MUST NOT be affirmed 297 with a zero Accept field in the Start-N-Ack response). 299 All SID fields are constructed as defined in the last paragraph of 300 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 301 SID is assigned by the Server during the session request exchange. 303 The message is terminated with a single block HMAC, as illustrated 304 above. 306 The Server MUST respond with one or more Start-N-Ack messages (which 307 SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL 308 have the format defined in the next session. 310 When using Individual Session Control mode and its Start-N-Ack 311 command as described in the next section, multiple Start-N-Sessions 312 commands MAY be sent without waiting for acknowledgement, and the 313 Start-N-sessions commands MAY arrive in any order. 315 3.3. Start-N-Ack Command with Individual Session Control 317 The Server responds to the Start-N-Sessions command (for one or more 318 specific sessions referenced by their SIDs) with one or more Start-N- 319 Ack commands with Accept fields corresponding to one or more of the 320 SIDs. This allows for the possibility that a Server cannot 321 immediately start one or more the sessions referenced in a particular 322 Start-N-Sessions command, but can start one or more of the sessions. 324 The format of the message is as follows. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 329 | 8 | Accept | MBZ | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | MBZ (8 octets) | 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Number of Sessions | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 336 | | 337 | First SID (16 octets) | 338 | | 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 341 | | 342 . remaining SIDs (16 octets each) . 343 . . 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 346 | | 347 | HMAC (16 octets) | 348 | | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 The Command Number value of 8 indicates that this is a Start-N-Ack 353 message. The Server MUST compose this command, and the Control- 354 Client MUST interpret this command, according to the field 355 descriptions below. 357 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 359 The Number of Sessions field indicates the count of sessions that 360 this Start-N-Ack command applies to, and must be one or greater. The 361 number of SID fields that follow MUST be equal to the value in the 362 Number of Sessions field. 364 All SID fields are constructed as defined in the last paragraph of 365 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 366 SID is assigned by the Server during the session request exchange. 368 The message is terminated with a single block HMAC, as illustrated 369 above. 371 Note that the SIDs for all Sessions with the same 'Accept' code can 372 be acknowledged using the same Start-N-Ack message. 374 For example, say that the Server receives a Start-N-Sessions command 375 for SIDs 1, 2, 3, and 4. The Server determines that the resources 376 for SID=3 are temporarily unavailable. The Server responds with two 377 Start-N-Ack commands with fields as follows: 379 Accept = 0 Number of Sessions = 3 SIDs 1, 2, 4 381 Accept = 5 Number of Sessions = 1 SID 3 383 3.4. Stop-N-Sessions Command with Individual Session Control 385 The Stop-N-Sessions command can only be issued by the Control-Client. 386 The command MUST contain at least one SID. 388 The TWAMP Stop-N-Sessions command for use in Individual Session 389 Control mode is formatted as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 394 | 9 | | 395 +-+-+-+-+-+-+-+-+ + 396 | MBZ (11 octets) | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Number of Sessions | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 401 | | 402 | First SID (16 octets) | 403 | | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 406 | | 407 . remaining SIDs (16 octets each) . 408 . . 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 411 | | 412 | HMAC (16 octets) | 413 | | 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 417 The Command Number value of 9 indicates that this is a Stop-N- 418 Sessions command. The Control-Client MUST compose this command, and 419 the Server MUST interpret this command, according to the field 420 descriptions below. 422 The Number of sessions field indicates the count of sessions that 423 this Stop-N-Sessions command applies to. The SID is as defined in 424 OWAMP (and TWAMP) section 3.5 [RFC4656] and the value must be one or 425 greater. The number of SID fields that follow MUST be equal to the 426 value in the Number of Sessions field. 428 The message is terminated with a single block HMAC, as illustrated 429 above. 431 The Server MUST respond with one or more Stop-N-Ack messages (which 432 SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL 433 have the format defined in the next session. 435 3.5. Stop-N-Ack Command with Individual Session Control 437 In response to the Stop-N-Sessions command (for one or more specific 438 sessions referenced by their SIDs), the Server MUST reply with one or 439 more Stop-N-Ack commands with Accept fields corresponding to one or 440 more of the SIDs. This allows for the possibility that a Server 441 cannot immediately stop one or more the sessions referenced in a 442 particular Stop-N-Sessions command, but can stop one or more of the 443 sessions. 445 The format for the Stop-N-Ack command is as follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 450 | 10 | Accept | MBZ | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | MBZ (8 octets) | 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Number of Sessions | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 457 | | 458 | First SID (16 octets) | 459 | | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 462 | | 463 . remaining SIDs (16 octets each) . 464 . . 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 467 | | 468 | HMAC (16 octets) | 469 | | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 The Command Number value of 10 indicates that this is a Stop-N-Ack 474 message. The Server MUST compose this command, and the Control- 475 Client MUST interpret this command, according to the field 476 descriptions below. 478 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 480 The Number of Sessions field indicates the count of sessions that 481 this Stop-N-Ack command applies to, and must be one or greater. The 482 number of SID fields that follow MUST be equal to the value in the 483 Number of Sessions field. 485 All SID fields are constructed as defined in the last paragraph of 486 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 487 SID is assigned by the Server during the session request exchange. 489 The message is terminated with a single block HMAC, as illustrated 490 above. 492 Note that the SIDs for all Sessions with the same 'Accept' code can 493 be acknowledged using the same Stop-N-Ack message. 495 3.6. SERVWAIT Timeout Operation 497 Section 3.1 of [RFC5357] describes the operation of the optional 498 SERVWAIT timer. In normal TWAMP operation, the Server suspends 499 monitoring the SERVWAIT timer while test sessions are in progress. 500 When the Individual Session Control feature is utilized, this 501 suspension is extended to cover the time when ANY test session is in 502 progress. 504 Thus, the Server SHALL suspend monitoring control connection activity 505 after receiving any Start-N-Sessions command, and after receiving a 506 Stop-N-Sessions command for all corresponding SIDs (and no test 507 sessions are in-progress), OR when REFWAIT expires on ALL test 508 sessions initiated by a TWAMP-Control connection, then the SERVWAIT 509 monitoring SHALL resume (as though a Stop-N-Sessions command had been 510 received). An implementation which supports the SERVWAIT timeout 511 option SHOULD also implement the REFWAIT timeout option. 513 The diagram below illustrates the operation of timers SERVWAIT and 514 REFWAIT. 516 SERVWAIT REFWAIT SERVWAIT 517 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 518 (no sessions 519 in-progress) 520 +-+-+-+-+-+-+-+-+-+-+-+ 521 SID="1" 523 +-+-+-+-+ 524 SID="2" 526 +-+-+-+-+-+-+-+-+ 527 SID="3" 529 >>>>>>>>>> Time >>>>>>>>>>>>>>>>>>> Time >>>>>>>>>>>>>>>> Time >>>>> 531 3.7. Additional considerations 533 The value of the Modes field sent by the Server (in the Server 534 Greeting message) is the bit-wise OR of the mode values that it is 535 willing to support during this session. 537 If this feature is adopted, the last ???? bits of the Modes 32-bit 538 field are used. A Control-Client MAY ignore other bit positions 539 greater than 2 in the Modes Field, or it MAY support other features 540 that are communicated in these bit positions. (The unassigned bits 541 are available for future protocol extensions.) 543 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 545 4. TWAMP Test with Individual Session Control 547 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 548 protocol with the exception that the Session-Reflector transmits test 549 packets to the Session-Sender in response to each test packet it 550 receives. TWAMP [RFC5357] defines two different test packet formats, 551 one for packets transmitted by the Session-Sender and one for packets 552 transmitted by the Session-Reflector. As with OWAMP-Test protocol 553 there are three security modes: unauthenticated, authenticated, and 554 encrypted. Unauthenticated mode has one test packet format, while 555 authenticated and encrypted modes use another (common) format. 557 4.1. Sender Behavior 559 The individual session control feature requires that the sender MUST 560 manage test sessions according to their SID. Otherwise, the sender 561 behavior is as described in section 4.1 of [RFC5357]. 563 4.2. Reflector Behavior 565 The TWAMP Reflector follows the procedures and guidelines in section 566 4.2 of [RFC5357], with the following additional functions required by 567 this feature: 569 o The Session-Reflector MUST manage all test sessions accepted 570 according to their SID. 572 o Upon receipt of a TWAMP-Control Stop-N-Sessions command 573 referencing a specific session/SID, the Session-Reflector MUST 574 ignore TWAMP-Test packets (in the same session/SID) that arrive at 575 the current time plus the Timeout (in the Request-TW-Session 576 command and assuming subsequent acknowledgement). The Session- 577 Reflector MUST NOT generate a test packet to the Session-Sender 578 for packets that are ignored. 580 o If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be 581 enforced when any test session is in-progress (started and not 582 stopped). 584 5. Security Considerations 586 The security considerations that apply to any active measurement of 587 live networks are relevant here as well. See the security 588 considerations in[RFC4656] and [RFC5357]. 590 6. IANA Considerations 592 This memo requests assignment of one mode bit position/value to the 593 IANA registry for the TWAMP Mode field, and describes behavior when 594 the new mode is used. This field is a recognized extension mechanism 595 for TWAMP. 597 This memo also requests assignment of four command numbers in the 598 TWAMP-Control Command Number registry, and describes the use of the 599 new commands. The command number field is a recognized extension 600 mechanism for TWAMP. 602 6.1. Registry Specification 604 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 605 TWAMP-Modes are specified in TWAMP Server Greeting messages and 606 Set-up Response messages, as described in section 3.1 of [RFC5357], 607 consistent with section 3.1 of [RFC4656], and extended by this memo. 608 Modes are indicated by setting bits in the 32-bit Modes field. Thus, 609 this registry can contain a total of 32 possible values. 611 IANA has also created a TWAMP-Control Command Number registry. 612 TWAMP-Control commands are specified by the first octet in TWAMP- 613 Control messages as specified in section 3.5 of [RFC5357], and 614 augmented by this memo. This registry may contain 256 possible 615 values. 617 6.2. Registry Management 619 Because the TWAMP-Control Command Number registry can contain only 620 256 values and TWAMP-Modes can only contain thirty-two values, and 621 because TWAMP is an IETF protocol, these registries must be updated 622 only by "IETF Consensus" as specified in [RFC5226] (an RFC 623 documenting registry use that is approved by the IESG). Management 624 of these registries is described in section 8.2 of [RFC5357] and 625 [RFC5618]. 627 This memo proposes assignment of values 7, 8, 9 and 10 in the Command 628 number Registry, and the next available bit position (indicated by 629 "Z") and corresponding value (indicated by "zzz") in section 3.1 630 above. Note that these values should be replaced by IANA or the RFC 631 Editor when assigned. 633 6.3. Experimental Numbers 635 One experimental value has been assigned in the TWAMP-Control Command 636 Number registry. 638 No additional experimental values are assigned in the TWAMP-Modes 639 registry. 641 6.4. Registry Contents 643 TWAMP-Control Command Number Registry 645 Value Description Semantics Definition 646 0 Reserved 647 1 Forbidden 648 2 Start-Sessions RFC4656, Section 3.7 649 3 Stop-Sessions RFC4656, Section 3.8 650 4 Reserved 651 5 Request-TW-Session RFC5357, Section 3.5 652 6 Experimentation RFC5357, Section 8.3 653 ------------------------------------------------------------------ 654 7 Start-N-Sessions this memo, Section 3.2 655 8 Start-N-Ack this memo, Section 3.3 656 9 Stop-N-Sessions this memo, Section 3.4 657 10 Stop-N-Ack this memo, Section 3.5 659 TWAMP-Modes Registry 660 Value Description Reference/Explanation 661 0 Reserved 662 1 Unauthenticated RFC4656, Section 3.1 663 2 Authenticated RFC4656, Section 3.1 664 4 Encrypted RFC4656, Section 3.1 665 8 Unauth. TEST protocol, RFC5618, Section 3.1 666 Auth. CONTROL 667 -------------------------------------------------------- 668 zzz Individual Session this memo, Section 3.1 669 Control bit position (Z) 670 The suggested values are: 672 Z=4 zzz=16 674 7. Acknowledgements 676 The authors thank everyone who provided comments on this feature. 678 8. References 680 8.1. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 686 Zekauskas, "A One-way Active Measurement Protocol 687 (OWAMP)", RFC 4656, September 2006. 689 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 May 2008. 693 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 694 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 695 RFC 5357, October 2008. 697 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 698 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 699 August 2009. 701 8.2. Informative References 703 [I-D.ietf-ippm-twamp-reflect-octets] 704 Morton, A. and L. Ciavattone, "TWAMP Reflect Octets and 705 Symmetrical Size Features", 706 draft-ietf-ippm-twamp-reflect-octets-03 (work in 707 progress), October 2009. 709 [x] "". 711 Authors' Addresses 713 Al Morton 714 AT&T Labs 715 200 Laurel Avenue South 716 Middletown,, NJ 07748 717 USA 719 Phone: +1 732 420 1571 720 Fax: +1 732 368 1192 721 Email: acmorton@att.com 722 URI: http://home.comcast.net/~acmacm/ 724 Murtaza Chiba 725 Cisco Systems 726 170 W. Tasman Drive 727 San Jose, 95134 728 USA 730 Phone: +1 800 553 NETS 731 Fax: +1 732 Email: mchiba@cisco.com 733 URI: