idnits 2.17.1 draft-ietf-ippm-twamp-session-cntrl-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 8, 2010) is 5130 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-04 Summary: 1 error (**), 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: October 10, 2010 April 8, 2010 8 Individual Session Control Feature for TWAMP 9 draft-ietf-ippm-twamp-session-cntrl-07 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 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 10, 2010. 44 Copyright Notice 46 Copyright (c) 2010 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 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 16 92 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 16 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 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 an OPTIONAL feature for TWAMP. [RFC5357] TWAMP 112 (and OWAMP) start all previously requested and accepted test sessions 113 at once. This feature allows the Control-Client to control 114 individual test sessions on the basis of their Session Identifier 115 (SID). This feature permits a short duration TWAMP test to start 116 (and/or stop) during a longer test. This feature permits a specific 117 diagnostic test to begin if intermediate results indicate that the 118 test is warranted, for 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 The Individual Session Control feature gives the Control-Client new 127 flexibility to manage any number of test sessions once they are 128 established. However, [RFC5357] test sessions are established in 129 serial order and the total establishment time grows with the number 130 of sessions and the round-trip time. Therefore, implementers of this 131 feature may also wish to implement the "Reflect Octets" feature, 132 described in [I-D.ietf-ippm-twamp-reflect-octets], once it has been 133 published as an RFC. This feature allows a Control-Client to 134 distinguish between parallel Request-TW-Session commands, because a 135 participating Server can return octets (e.g., the Control-Client's 136 local index) in its reply to the request. Thus, the Reflect Octets 137 feature supports the efficient establishment of many simultaneous 138 test sessions which the Individual Session Control feature can then 139 manage (start/stop). 141 This memo is an update to the TWAMP core protocol specified in 142 [RFC5357]. Measurement systems are not required to implement the 143 feature described in this memo to claim compliance with [RFC5357]. 145 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 146 to zero by senders and MUST be ignored by receivers. Also, the HMAC 147 (Hashed Message Authentication Code) MUST be calculated as defined in 148 Section 3.2 of [RFC4656]. 150 2. Purpose and Scope 152 The purpose of this memo is to describe an additional OPTIONAL 153 function and feature for TWAMP [RFC5357]. 155 The scope of the memo is limited to specifications of the following 156 features: 158 1. Extension of the modes of operation through assignment of a new 159 value in the Mode field to communicate feature capability and 160 use, 162 2. the definitions of augmented start session and stop session 163 commands (with corresponding acknowledgements), and 165 3. the definition of related procedures for TWAMP entities. 167 The motivation for this feature is the ability to start and stop 168 individual test sessions at will, using a single TWAMP-control 169 connection. 171 When the Server and Control-Client have agreed to use the Individual 172 Session Control mode during control connection setup, then the 173 Control-Client, the Server, the Session-Sender, and the Session- 174 Reflector MUST all conform to the requirements of that mode, as 175 identified below. The original TWAMP-Control Start and Stop commands 176 MUST NOT be used. 178 3. TWAMP Control Extensions 180 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 181 and provides two-way measurement capability. TWAMP [RFC5357] uses 182 the Modes Field to identify and select specific communication 183 capabilities, and this field is a recognized extension mechanism. 184 The following sections describe one such extension. 186 3.1. Connection Setup with Individual Session Control 188 TWAMP-Control connection establishment follows the procedure defined 189 in section 3.1 of [RFC4656] OWAMP. The Individual Session Control 190 mode requires one new bit position (and value) to identify the 191 ability of the Server/Session-Reflector to start and stop specific 192 sessions (according to their Session Identifier, or SID). This new 193 feature requires an additional TWAMP mode bit assignment as follows: 195 Value Description Reference/Explanation 196 0 Reserved 197 1 Unauthenticated RFC4656, Section 3.1 198 2 Authenticated RFC4656, Section 3.1 199 4 Encrypted RFC4656, Section 3.1 200 8 Unauth. TEST protocol, RFC5618, Section 3.1 201 Auth. CONTROL 202 -------------------------------------------------------- 203 zzz Individual Session this memo, bit position (Z) 204 Control 206 In the original OWAMP mode field, setting bit positions 0, 1 or 2 207 indicated the security mode of the Control protocol, and the Test 208 protocol inherited the same mode (see section 4 of [RFC4656]). In 209 the [RFC5618] memo, bit position (3) allows a different security mode 210 in the Test protocol and uses the unauthenticated test packet format. 212 If the Server sets the new bit position (bit position Z) in the 213 Server Greeting message to indicate its capabilities, then the Server 214 and Session-Reflector MUST comply with the requirements of this memo 215 to control sessions on an individual basis if desired. 217 If the Control-Client intends to control sessions on an individual 218 basis (according to the requirements in this memo), it MUST set the 219 mode bit (Z, corresponding to the new mode) in the Setup Response 220 message. This means that: 222 1. The Control-Client and the Server MUST use the start and stop 223 commands intended for individual session control and the 224 corresponding acknowledgements, as defined in the sections that 225 follow. 227 2. The Control-Client and the Server MUST NOT use the start and stop 228 commands (2 and 3) and the acknowledgement defined in [RFC5357]. 230 The Control-Client MUST also set one mode bit to indicate the chosen 231 security mode (currently bits 0, 1, 2, or 3), consistent with the 232 modes offered by the Server. The Control-Client MAY also set Modes 233 bit Z with other features and bit positions (such as the reflect 234 octets feature). 236 3.2. Start-N-Sessions Command with Individual Session Control 238 Having 239 o initiated Individual Session Control mode in the Setup Response, 241 o requested one or more test sessions, and 243 o received affirmative Accept-Session response(s), 245 a TWAMP Client MAY start the execution of one or more test sessions 246 by sending a Start-N-Sessions message to the Server (note that "N" 247 indicates that this command is applicable to one or more sessions, 248 and does not change with the number of sessions identified in the 249 command). 251 The format of the Start-N-Sessions message is as follows: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 256 | 7 | | 257 +-+-+-+-+-+-+-+-+ + 258 | MBZ (11 octets) | 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Number of Sessions | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 263 | | 264 | First SID (16 octets) | 265 | | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 268 | | 269 . remaining SIDs (16 octets each) . 270 . . 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 273 | | 274 | HMAC (16 octets) | 275 | | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 279 The Command Number value of 7 indicates that this is a Start-N- 280 Sessions command. The Control-Client MUST compose this command, and 281 the Server MUST interpret this command, according to the field 282 descriptions below. 284 The Number of Sessions field indicates the count of sessions that 285 this Start command applies to, and MUST be one or greater. The 286 number of SID fields that follow MUST be equal to the value in the 287 Number of Sessions field (otherwise, the command MUST NOT be affirmed 288 with a zero Accept field in the Start-N-Ack response). 290 All SID fields are constructed as defined in the last paragraph of 291 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 292 SID is assigned by the Server during the session request exchange. 294 The message is terminated with a single block HMAC, as illustrated 295 above. 297 The Server MUST respond with one or more Start-N-Ack messages (which 298 SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL 299 have the format defined in the next session. 301 When using Individual Session Control mode and its Start-N-Ack 302 command as described in the next section, multiple Start-N-Sessions 303 commands MAY be sent without waiting for acknowledgement, and the 304 Start-N-sessions commands MAY arrive in any order. 306 3.3. Start-N-Ack Command with Individual Session Control 308 The Server responds to the Start-N-Sessions command (for one or more 309 specific sessions referenced by their SIDs) with one or more Start-N- 310 Ack commands with Accept fields corresponding to one or more of the 311 SIDs. This allows for the possibility that a Server cannot 312 immediately start one or more of the sessions referenced in a 313 particular Start-N-Sessions command, but can start one or more of the 314 sessions. 316 The format of the message is as follows. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 321 | 8 | Accept | MBZ | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | MBZ (8 octets) | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Number of Sessions | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 328 | | 329 | First SID (16 octets) | 330 | | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 333 | | 334 . remaining SIDs (16 octets each) . 335 . . 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 338 | | 339 | HMAC (16 octets) | 340 | | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 The Command Number value of 8 indicates that this is a Start-N-Ack 345 message. The Server MUST compose this command, and the Control- 346 Client MUST interpret this command, according to the field 347 descriptions below. 349 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 351 The Number of Sessions field indicates the count of sessions that 352 this Start-N-Ack command applies to, and MUST be one or greater. The 353 number of SID fields that follow MUST be equal to the value in the 354 Number of Sessions field. 356 All SID fields are constructed as defined in the last paragraph of 357 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 358 SID is assigned by the Server during the session request exchange. 360 The message is terminated with a single block HMAC, as illustrated 361 above. 363 Note that the SIDs for all Sessions with the same 'Accept' code can 364 be acknowledged using the same Start-N-Ack message. 366 For example, say that the Server receives a Start-N-Sessions command 367 for SIDs 1, 2, 3, and 4. The Server determines that the resources 368 for SID=3 are temporarily unavailable. The Server responds with two 369 Start-N-Ack commands with fields as follows: 371 Accept = 0 Number of Sessions = 3 SIDs 1, 2, 4 373 Accept = 5 Number of Sessions = 1 SID 3 375 3.4. Stop-N-Sessions Command with Individual Session Control 377 The Stop-N-Sessions command can only be issued by the Control-Client. 378 The command MUST contain at least one SID. 380 The TWAMP Stop-N-Sessions command for use in Individual Session 381 Control mode is formatted as follows: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 386 | 9 | | 387 +-+-+-+-+-+-+-+-+ + 388 | MBZ (11 octets) | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Number of Sessions | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 393 | | 394 | First SID (16 octets) | 395 | | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 398 | | 399 . remaining SIDs (16 octets each) . 400 . . 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 403 | | 404 | HMAC (16 octets) | 405 | | 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 409 The Command Number value of 9 indicates that this is a Stop-N- 410 Sessions command. The Control-Client MUST compose this command, and 411 the Server MUST interpret this command, according to the field 412 descriptions below. 414 The Number of sessions field indicates the count of sessions that 415 this Stop-N-Sessions command applies to. The SID is as defined in 416 OWAMP (and TWAMP) section 3.5 [RFC4656] and the value MUST be one or 417 greater. The number of SID fields that follow MUST be equal to the 418 value in the Number of Sessions field. 420 The message is terminated with a single block HMAC, as illustrated 421 above. 423 The Server MUST respond with one or more Stop-N-Ack messages (which 424 SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL 425 have the format defined in the next session. 427 3.5. Stop-N-Ack Command with Individual Session Control 429 In response to the Stop-N-Sessions command (for one or more specific 430 sessions referenced by their SIDs), the Server MUST reply with one or 431 more Stop-N-Ack commands with Accept fields corresponding to one or 432 more of the SIDs. This allows for the possibility that a Server 433 cannot immediately stop one or more of the sessions referenced in a 434 particular Stop-N-Sessions command, but can stop one or more of the 435 sessions. 437 The format for the Stop-N-Ack command is as follows: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 442 | 10 | Accept | MBZ | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | MBZ (8 octets) | 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Number of Sessions | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 449 | | 450 | First SID (16 octets) | 451 | | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 454 | | 455 . remaining SIDs (16 octets each) . 456 . . 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B 459 | | 460 | HMAC (16 octets) | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The Command Number value of 10 indicates that this is a Stop-N-Ack 466 message. The Server MUST compose this command, and the Control- 467 Client MUST interpret this command, according to the field 468 descriptions below. 470 The Accept Field values are defined in OWAMP section 3.3 [RFC4656]. 472 The Number of Sessions field indicates the count of sessions that 473 this Stop-N-Ack command applies to, and MUST be one or greater. The 474 number of SID fields that follow MUST be equal to the value in the 475 Number of Sessions field. 477 All SID fields are constructed as defined in the last paragraph of 478 OWAMP section 3.5 [RFC4656] (and referenced in TWAMP). Note that the 479 SID is assigned by the Server during the session request exchange. 481 The message is terminated with a single block HMAC, as illustrated 482 above. 484 Note that the SIDs for all Sessions with the same 'Accept' code can 485 be acknowledged using the same Stop-N-Ack message. 487 3.6. SERVWAIT Timeout Operation 489 Section 3.1 of [RFC5357] describes the operation of the optional 490 SERVWAIT timer. In normal TWAMP operation, the Server suspends 491 monitoring the SERVWAIT timer while test sessions are in progress. 492 When the Individual Session Control feature is utilized, this 493 suspension is extended to cover the time when ANY test session is in 494 progress. 496 Thus, the Server SHALL suspend monitoring control connection activity 497 after receiving any Start-N-Sessions command, and after receiving a 498 Stop-N-Sessions command for all corresponding SIDs (and no test 499 sessions are in-progress), OR when REFWAIT expires on ALL test 500 sessions initiated by a TWAMP-Control connection, then the SERVWAIT 501 monitoring SHALL resume (as though a Stop-N-Sessions command had been 502 received). An implementation which supports the SERVWAIT timeout 503 option SHOULD also implement the REFWAIT timeout option. 505 The diagram below illustrates the operation of timers SERVWAIT and 506 REFWAIT. 508 SERVWAIT REFWAIT SERVWAIT 509 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 510 (no sessions 511 in-progress) 512 +-+-+-+-+-+-+-+-+-+-+-+ 513 SID="1" 515 +-+-+-+-+ 516 SID="2" 518 +-+-+-+-+-+-+-+-+ 519 SID="3" 521 >>>>>>>>>> Time >>>>>>>>>>>>>>>>>>> Time >>>>>>>>>>>>>>>> Time >>>>> 523 3.7. Additional considerations 525 The value of the Modes field sent by the Server (in the Server 526 Greeting message) is the bit-wise OR of the mode values that it is 527 willing to support during this session. 529 With the publication of this feature, bit positions 0 through (Z=4) 530 of the Modes 32-bit field are used. A Control-Client MAY ignore bit 531 positions greater than 2 in the Modes Field, or it MAY support 532 OPTIONAL features that are communicated in bit positions 3 and 533 higher. (The unassigned bits are available for future protocol 534 extensions.) 535 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 537 4. TWAMP Test with Individual Session Control 539 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 540 protocol with the exception that the Session-Reflector transmits test 541 packets to the Session-Sender in response to each test packet it 542 receives. TWAMP [RFC5357] defines two different test packet formats, 543 one for packets transmitted by the Session-Sender and one for packets 544 transmitted by the Session-Reflector. As with OWAMP-Test protocol 545 there are three security modes: unauthenticated, authenticated, and 546 encrypted. Unauthenticated mode has one test packet format, while 547 authenticated and encrypted modes use another (common) format. 549 4.1. Sender Behavior 551 The individual session control feature requires that the sender MUST 552 manage test sessions according to their SID. Otherwise, the sender 553 behavior is as described in section 4.1 of [RFC5357]. 555 4.2. Reflector Behavior 557 The TWAMP Reflector follows the procedures and guidelines in section 558 4.2 of [RFC5357], with the following additional functions required by 559 this feature: 561 o The Session-Reflector MUST manage all test sessions accepted 562 according to their SID. 564 o Upon receipt of a TWAMP-Control Stop-N-Sessions command 565 referencing a specific session/SID, the Session-Reflector MUST 566 ignore TWAMP-Test packets (in the same session/SID) that arrive at 567 the current time plus the Timeout (in the Request-TW-Session 568 command and assuming subsequent acknowledgement). The Session- 569 Reflector MUST NOT generate a test packet to the Session-Sender 570 for packets that are ignored. (Note: The Request-TW-Session 571 command includes sender address + port and receiver address + 572 port, and this is usually sufficient to distinguish sessions.) 574 o If the REFWAIT timer is implemented, it SHOULD be enforced when 575 any test session is in-progress (started and not stopped). 577 5. Security Considerations 579 The security considerations that apply to any active measurement of 580 live networks are relevant here as well. See the security 581 considerations in[RFC4656] and [RFC5357]. 583 6. IANA Considerations 585 This memo requests assignment of one mode bit position/value to the 586 IANA registry for the TWAMP Mode field, and describes behavior when 587 the new mode is used. This field is a recognized extension mechanism 588 for TWAMP. 590 This memo also requests assignment of four command numbers in the 591 TWAMP-Control Command Number registry, and describes the use of the 592 new commands. The command number field is a recognized extension 593 mechanism for TWAMP. 595 6.1. Registry Specification 597 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 598 TWAMP-Modes are specified in TWAMP Server Greeting messages and 599 Set-up Response messages, as described in section 3.1 of [RFC5357], 600 consistent with section 3.1 of [RFC4656], and extended by this memo. 601 Modes are indicated by setting bits in the 32-bit Modes field that 602 correspond to values in the Modes registry. For the TWAMP-Modes 603 registry, we expect that new features will be assigned increasing 604 registry values that correspond to single bit positions, unless there 605 is a good reason to do otherwise (more complex encoding than single 606 bit positions may be used in the future, to access the 2^32 value 607 space). 609 IANA has also created a TWAMP-Control Command Number registry. 610 TWAMP-Control commands are specified by the first octet in TWAMP- 611 Control messages as specified in section 3.5 of [RFC5357], and 612 augmented by this memo. This registry may contain 256 possible 613 values. 615 6.2. Registry Management 617 Because the TWAMP-Control Command Number registry can contain only 618 256 values and TWAMP-Modes can only contain thirty-two values, and 619 because TWAMP is an IETF protocol, these registries must be updated 620 only by "IETF Consensus" as specified in [RFC5226] (an RFC 621 documenting registry use that is approved by the IESG). Management 622 of these registries is described in section 8.2 of [RFC5357] and 623 [RFC5618]. 625 This memo proposes assignment of values 7, 8, 9 and 10 in the Command 626 number Registry, and a Mode registry value (indicated by "zzz") 627 corresponding to the next available bit position (indicated by "Z") 628 in sections 3.1 and 3.7 above. Note that the "zzz" and "Z" strings 629 should be replaced by IANA or the RFC Editor when values are 630 assigned. 632 6.3. Experimental Numbers 634 One experimental value has been assigned in the TWAMP-Control Command 635 Number registry. 637 No additional experimental values are assigned in the TWAMP-Modes 638 registry. 640 6.4. Registry Contents 642 TWAMP-Control Command Number Registry 644 Value Description Semantics Definition 645 0 Reserved 646 1 Forbidden 647 2 Start-Sessions RFC4656, Section 3.7 648 3 Stop-Sessions RFC4656, Section 3.8 649 4 Reserved 650 5 Request-TW-Session RFC5357, Section 3.5 651 6 Experimentation RFC5357, Section 8.3 652 ------------------------------------------------------------------ 653 7 Start-N-Sessions this memo, Section 3.2 654 8 Start-N-Ack this memo, Section 3.3 655 9 Stop-N-Sessions this memo, Section 3.4 656 10 Stop-N-Ack this memo, Section 3.5 658 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 The next value corresponding to an unused bit is zzz=16, with Z=4. 674 7. Acknowledgements 676 The authors thank everyone who provided comments on this feature, 677 especially Lars Eggert, Adrian Farrel, and Alexey Melnikov. 679 8. References 681 8.1. Normative References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 687 Zekauskas, "A One-way Active Measurement Protocol 688 (OWAMP)", RFC 4656, September 2006. 690 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 691 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 692 May 2008. 694 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 695 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 696 RFC 5357, October 2008. 698 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 699 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 700 August 2009. 702 8.2. Informative References 704 [I-D.ietf-ippm-twamp-reflect-octets] 705 Morton, A. and L. Ciavattone, "TWAMP Reflect Octets and 706 Symmetrical Size Features", 707 draft-ietf-ippm-twamp-reflect-octets-04 (work in 708 progress), February 2010. 710 Authors' Addresses 712 Al Morton 713 AT&T Labs 714 200 Laurel Avenue South 715 Middletown,, NJ 07748 716 USA 718 Phone: +1 732 420 1571 719 Fax: +1 732 368 1192 720 Email: acmorton@att.com 721 URI: http://home.comcast.net/~acmacm/ 723 Murtaza Chiba 724 Cisco Systems 725 170 W. Tasman Drive 726 San Jose, 95134 727 USA 729 Phone: +1 800 553 NETS 730 Fax: +1 731 Email: mchiba@cisco.com 732 URI: