idnits 2.17.1 draft-ietf-ippm-twamp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1179. 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 document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' an IANA Considerations Section in RFCs, RFC 2434,' ) ** The abstract seems to contain references ([RFC2119], [RFC2434], [RFC2681], [RFC3629], [RFC3692], [0-15], [RFC4656], [RFC3629,RFC5198], [RFC2474], [RFC5198]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 818 has weird spacing: '...mestamp accur...' == Line 863 has weird spacing: '...nce per sessi...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The shared secret is a passphrase. To maximize passphrase interoperability, the passphrase character set MUST be encoded using Appendix B of [RFC 5198] (the ASCII Network Virtual Terminal Definition) It MUST not contain newlines (any combination of Carriage-Return (CR) and/or Line-Feed (LF) characters), and control characters SHOULD be avoided. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2008) is 5747 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC4656' on line 1065 looks like a reference -- Missing reference section? 'RFC2681' on line 1069 looks like a reference -- Missing reference section? 'RFC2119' on line 1073 looks like a reference -- Missing reference section? 'RFC 5198' on line 295 looks like a reference -- Missing reference section? 'RFC2474' on line 1076 looks like a reference -- Missing reference section? 'RFC2434' on line 1081 looks like a reference -- Missing reference section? '0-15' on line 971 looks like a reference -- Missing reference section? 'RFC3692' on line 1093 looks like a reference -- Missing reference section? 'RFC3629' on line 1085 looks like a reference -- Missing reference section? 'RFC5198' on line 1088 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Hedayat 2 Internet Draft Brix Networks 3 Expires: Jan 2009 R. Krzanowski 4 Intended Status:Standards Track Verizon 5 A. Morton 6 AT&T Labs 7 K. Yum 8 Juniper Networks 9 J. Babiarz 10 Nortel Networks 11 July 30, 2008 13 A Two-way Active Measurement Protocol (TWAMP) 14 draft-ietf-ippm-twamp-09 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides 46 a common protocol for measuring one-way metrics between network 47 devices. OWAMP can be used bi-directionally to measure one-way 48 metrics in both directions between two network elements. However, 49 it does not accommodate round-trip or two-way measurements. This 50 memo specifies a Two-way Active Measurement Protocol (TWAMP), based 51 on the OWAMP, that adds two-way or round-trip measurement 52 capabilities. The TWAMP measurement architecture is usually 53 comprised of two hosts with specific roles, and this allows for 54 some protocol simplifications, making it an attractive alternative 55 in some circumstances. 57 Table of Contents 59 1. Introduction..................................................3 60 1.1 Relationship of Test and Control Protocols................3 61 1.2 Logical Model.............................................4 62 1.3 Pronunciation Guide.......................................5 63 2. Protocol Overview.............................................5 64 3. TWAMP Control.................................................6 65 3.1 Connection Setup..........................................6 66 3.2 Integrity Protection......................................7 67 3.3 Value of the Accept Fields................................8 68 3.4 TWAMP Control Commands....................................8 69 3.5 Creating Test Sessions....................................8 70 3.6 Send Schedules...........................................10 71 3.7 Starting Test Sessions...................................11 72 3.8 Stop-Sessions............................................11 73 3.9 Fetch-Session............................................12 74 4. TWAMP Test...................................................12 75 4.1 Sender Behavior..........................................13 76 4.2 Reflector Behavior.......................................13 77 5. Implementers Guide...........................................21 78 6. Security Considerations......................................21 79 7. Acknowledgements.............................................22 80 8. IANA Considerations..........................................22 81 8.1 Registry Specification...................................23 82 8.2 Registry Management......................................23 83 8.3 Experimental Numbers.....................................23 84 8.4 Initial Registry Contents................................23 85 9. Internationalization Considerations..........................24 86 10. APPENDIX I - TWAMP Light (Informative)......................24 87 11. References..................................................25 88 11.1 Normative References....................................25 89 11.2 Informative References..................................26 91 1. Introduction 93 The Internet Engineering Task Force (IETF) has completed a Proposed 94 standard for the round-trip delay [RFC2681] metric. IETF has also 95 completed a protocol for the control and collection of one-way 96 measurements, the One-way Active Measurement Protocol (OWAMP) 97 [RFC4656]. However, OWAMP does not accommodate round-trip or two- 98 way measurements. 100 Two-way measurements are common in IP networks, primarily because 101 synchronization between local and remote clocks is unnecessary for 102 round-trip delay, and measurement support at the remote end may be 103 limited to a simple echo function. However, the most common 104 facility for round-trip measurements is the ICMP Echo Request/Reply 105 (used by the ping tool), and issues with this method are documented 106 in section 2.6 of [RFC2681]. This memo specifies the Two-way Active 107 Measurement Protocol, or TWAMP. TWAMP uses the methodology and 108 architecture of OWAMP [RFC4656] to define an open protocol for 109 measurement of two-way or round-trip metrics (henceforth in this 110 document the term two-way also signifies round-trip), in addition 111 to the one-way metrics of OWAMP. TWAMP employs time stamps applied 112 at the echo destination (reflector) to enable greater accuracy 113 (processing delays can be accounted for). The TWAMP measurement 114 architecture is usually comprised of only two hosts with specific 115 roles, and this allows for some protocol simplifications, making it 116 an attractive alternative to OWAMP in some circumstances. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 119 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 RFC 2119 [RFC2119]. 123 1.1 Relationship of Test and Control Protocols 125 Similar to OWAMP [RFC4656], TWAMP consists of two inter-related 126 protocols: TWAMP-Control and TWAMP-Test. The relationship of these 127 protocols is as defined in section 1.1 of OWAMP [RFC4656]. 128 TWAMP-Control is used to initiate, start, and stop test sessions, 129 whereas TWAMP-Test is used to exchange test packets between two 130 TWAMP entities. 132 1.2 Logical Model 134 The role and definition of the logical entities are as defined in 135 section 1.2 of OWAMP [RFC4656] with the following exceptions: 137 - The Session-Receiver is called the Session-Reflector in the 138 TWAMP architecture. The Session-Reflector has the capability 139 to create and send a measurement packet when it receives a 140 measurement packet. Unlike the Session-Receiver, the 141 Session-Reflector does not collect any packet information. 143 - The Server is an end system that manages one or more TWAMP 144 sessions, and is capable of configuring per-session state in 145 the end-points. However, a Server associated with a 146 Session-Reflector would not have the capability to return the 147 results of a test session, and this is a difference from OWAMP. 149 - The Fetch-Client entity does not exist in the TWAMP 150 architecture, as the Session-Reflector does not collect any 151 packet information to be fetched. Consequently there is no 152 need for the Fetch-Client. 154 An example of possible relationship scenarios between these roles 155 are presented below. In this example different logical roles are 156 played on different hosts. Unlabeled links in the figure are 157 unspecified by this document and may be proprietary protocols. 159 +----------------+ +-------------------+ 160 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 161 +----------------+ +-------------------+ 162 ^ ^ 163 | | 164 | | 165 | | 166 | +----------------+<----------------+ 167 | | Server | 168 | +----------------+ 169 | ^ 170 | | 171 | TWAMP-Control 172 | | 173 v v 174 +----------------+ 175 | Control-Client | 176 +----------------+ 178 As in OWAMP [RFC4656], different logical roles can be played by the 179 same host. For example, in the figure above, there could be 180 actually two hosts: one playing the roles of Control-Client and 181 Session-Sender, and the other playing the roles of Server and 182 Session-Reflector. This example is shown below. 184 +-----------------+ +-------------------+ 185 | Control-Client |<--TWAMP Control-->| Server | 186 | | | | 187 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 188 +-----------------+ +-------------------+ 190 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be 191 set to zero by senders and MUST be ignored by receivers. 193 1.3 Pronunciation Guide 195 The acronym OWAMP is usually pronounced in two syllables, Oh-wamp. 197 The acronym TWAMP is also pronounced in two syllables, Tee-wamp. 199 2. Protocol Overview 201 The Two-way Active Measurement Protocol is an open protocol for 202 measurement of two-way metrics. It is based on OWAMP [RFC4656] and 203 adheres to its overall architecture and design. The TWAMP-control 204 and TWAMP-Test protocols accomplish their testing tasks as outlined 205 below: 207 - The Control-Client initiates a TCP connection on TWAMP's well- 208 known port, and the Server (its role now established) responds 209 with its greeting message indicating the security/integrity 210 mode(s) it is willing to support. 212 - The Control-Client responds with the chosen mode of 213 communication and information supporting integrity protection 214 and encryption, if the mode requires them. The Server responds 215 to accept the mode and start time. This completes the control 216 connection setup. 218 - The Control-Client requests (and describes) a test session with 219 a unique TWAMP-Control message. The Server responds with its 220 acceptance and supporting information. More than one test 221 session may be requested with additional messages. 223 - The Control-Client initiates all requested testing with a start 224 sessions message, and the Server acknowledges. 226 - The Session-Sender and the Session-Reflector exchange test 227 packets according to the TWAMP-Test protocol for each active 228 session. 230 - When appropriate, the Control-Client sends a message to stop all 231 test sessions. 233 There are two recognized extension mechanisms in the TWAMP 234 Protocol. The Modes field is used to establish the communication 235 options during TWAMP-Control Connection Setup. The TWAMP-Control 236 Command Number is another intended extension mechanism, allowing 237 additional commands to be defined in the future. TWAMP-Control 238 protocol addresses different levels of support between Control- 239 Client and Server. 241 All multi-octet quantities defined in this document are represented 242 as unsigned integers in network byte order unless specified 243 otherwise. 245 3. TWAMP Control 247 TWAMP-Control is a derivative of the OWAMP-Control for two-way 248 measurements. All TWAMP Control messages are similar in format and 249 follow similar guidelines to those defined in section 3 of OWAMP 250 [RFC4656] with the exceptions outlined in the following sections. 251 One such exception is the Fetch Session command, which is not used 252 in TWAMP. 254 3.1 Connection Setup 256 Connection establishment of TWAMP follows the same procedure 257 defined in section 3.1 of OWAMP [RFC4656]. The Modes field is a 258 recognized extension mechanism in TWAMP, and the current mode 259 values are identical to those used in OWAMP. The only exception is 260 the well-known port number for TWAMP-control. A client opens a TCP 261 connection to the server on well-known port N (Refer to the IANA 262 Considerations section below for the TWAMP-control port number 263 assignment). The host that initiates the TCP connection takes the 264 roles of Control-Client and (in the two-host implementation) the 265 Session-Sender. The host that acknowledges the TCP connection 266 accepts the roles of Server and (in the two-host implementation) 267 the Session Reflector. 269 The Control-Client MAY set a desired code-point in the Diffserv 270 Code Point (DSCP) field in the IP header for ALL packets of a 271 specific control connection. The Server SHOULD use the DSCP of the 272 Control-Client's TCP SYN in ALL subsequent packets on that 273 connection (avoiding any ambiguity in case of re-marking). 275 The possibility exists for Control-Client failure after TWAMP- 276 Control connection establishment, or the path between the Control- 277 Client and Server may fail while a connection is in-progress. The 278 Server MAY discontinue any established control connection when no 279 packet associated with that connection has been received within 280 SERVWAIT seconds. The Server SHALL suspend monitoring control 281 connection activity after receiving a Start-Sessions command, and 282 SHALL resume after receiving a Stop-Sessions command (IF the 283 SERVWAIT option is supported). Note that the REFWAIT time-out 284 (described below) covers failures during test sessions. The default 285 value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY 286 be configurable. This time-out allows a Server to free-up resources 287 in case of failure. 289 Both the server and the client use the same mappings from KeyIDs to 290 shared secrets. The server, being prepared to conduct sessions 291 with more than one client, uses KeyIDs to choose the appropriate 292 secret key; a client would typically have different secret keys for 293 different servers. The shared secret is a passphrase. To maximize 294 passphrase interoperability, the passphrase character set MUST be 295 encoded using Appendix B of [RFC 5198] (the ASCII Network Virtual 296 Terminal Definition) It MUST not contain newlines (any combination 297 of Carriage-Return (CR) and/or Line-Feed (LF) characters), and 298 control characters SHOULD be avoided. 300 3.2 Integrity Protection 302 Integrity protection of TWAMP follows the same procedure defined in 303 section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers 304 everything sent in a given direction between the previous HMAC (but 305 not including it) and up to the beginning of the new HMAC. This 306 way, once encryption is set up, each bit of the TWAMP-Control 307 connection is authenticated by an HMAC exactly once. 309 Note that the Server-Start message (sent by a Server during the 310 initial control connection exchanges) does not terminate with an 311 HMAC field. Therefore, the HMAC in the first Accept-Session message 312 also covers the Server-Start message and includes the Start-Time 313 field in the HMAC calculation. 315 Also, in authenticated and encrypted modes, the HMAC in TWAMP- 316 Control packets is encrypted. 318 3.3 Value of the Accept Fields 320 Accept values used in TWAMP are the same as the values defined in 321 section 3.3 of OWAMP [RFC4656]. 323 3.4 TWAMP Control Commands 325 TWAMP control commands conform to the rules defined in section 3.4 326 of OWAMP [RFC4656] 328 The following commands are available for the Control-client: 329 Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server 330 can send specific messages in response to the commands it receives 331 (as described in the sections that follow). 333 Note that the OWAMP Request-Session command is replaced by the 334 TWAMP Request-TW-Session command, and the Fetch-Session command 335 does not appear in TWAMP. 337 3.5 Creating Test Sessions 339 Test session creation follows the same procedure as defined in 340 section 3.5 of OWAMP [RFC4656]. The Request-TW-Session command is 341 based on the OWAMP Request-Session command, and uses the message 342 format as described in OWAMP secition 3.5, but without the schedule 343 slot description field(s) and uses one HMAC. The description of the 344 Request-TW-Session format follows. 346 In TWAMP, the first octet is referred to as the Command Number, and 347 the Command Number is a recognized extension mechanism. Readers are 348 encouraged to consult the TWAMP-Control Command Number Registry to 349 determine if there have been additional values assigned. 351 The Command Number value of 5 indicates a Request-TW-Session 352 Command, and the Server MUST interpret this command as a request 353 for a two-way test session using the TWAMP-Test protocol. 355 If a TWAMP Server receives an unexpected command number, it MUST 356 respond with the Accept field set to 3 (meaning "Some aspect of 357 request is not supported") in the Accept-Session message. Command 358 numbers that are Forbidden (and possibly numbers that are Reserved) 359 are unexpected. 361 In OWAMP, the Conf-Sender field is set to 1 when the 362 Request-Session message describes a task where the Server will 363 configure a one-way test packet sender. Likewise, the 364 Conf-Receiver field is set to 1 when the message describes the 365 configuration for a Session-Receiver. In TWAMP, both endpoints 366 perform in these roles, with the Session-Sender first sending and 367 then receiving test packets. The Session-Reflector first receives 368 the test packets, and returns each test packet to the 369 Session-Sender as fast as possible. 371 Both Conf-Sender field and Conf-Receiver field MUST be set to 0 372 since the Session-Reflector will both receive and send packets, and 373 the roles are established according to which host initiates the TCP 374 connection for control. The server MUST interpret any non-zero 375 value as an improperly formatted command, and MUST respond with the 376 Accept field set to 3 (meaning "Some aspect of request is not 377 supported") in the Accept-Session message. 379 The Session-Reflector in TWAMP does not process incoming test 380 packets for performance metrics and consequently does not need to 381 know the number of incoming packets and their timing schedule. 382 Consequently the Number of Scheduled Slots and Number of Packets 383 MUST be set to 0. 385 The Sender Port is the UDP port from which TWAMP-Test packets will 386 be sent and the port to which TWAMP-Test packets will be sent by 387 the Session-Reflector (Session-Sender will use the same UDP port to 388 send and receive packets). Receiver Port is the desired UDP port 389 to which TWAMP test packets will be sent by the Session-Sender (the 390 port where the Session-Reflector is asked to receive test packets). 391 Receiver Port is also the UDP port from which TWAMP test packets 392 will be sent by the Session-Reflector (Session-Reflector will use 393 the same UDP port to send and receive packets). 395 The Sender Address and Receiver Address fields contain, 396 respectively, the sender and receiver addresses of the endpoints of 397 the Internet path over which a TWAMP test session is requested. 398 They MAY be set to 0, in which case the IP addresses used for the 399 Control-Client to Server TWAMP-Control Message exchange MUST be 400 used in the test packets. 402 The Session Identifier (SID) is as defined in OWAMP [RFC4656]. 403 Since the SID is always generated by the receiving side, the Server 404 determines the SID, and the SID in the Request-TW-Session message 405 MUST be set to 0. 407 The Start Time is as defined in OWAMP [RFC4656]. 409 The Timeout is interpreted differently from the definition in OWAMP 410 [RFC4656]. In TWAMP, Timeout is the interval that the 411 Session-Reflector MUST wait after receiving a Stop-Sessions 412 message. In case there are test packets still in transit, the 413 Session Reflector MUST reflect them if they arrive within the 414 timeout interval following the reception of the Stop-Sessions 415 message. The Session-Reflector MUST NOT reflect packets that are 416 received beyond the timeout. 418 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 419 capability of this field is to set the Differentiated Services Code 420 Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST 421 be used in test packets reflected by the Session-Reflector. 423 Since there are no Schedule Slot Descriptions, the Request-TW- 424 Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash 425 Message Authentication Code) fields. This completes one logical 426 message, referred to as the Request-TW-Session Command. 428 The Session-Reflector MUST respond to each Request-TW-Session 429 Command with an Accept-Message as defined in OWAMP [RFC4656]. When 430 the Accept Field = 0, the Port field confirms (repeats) the port to 431 which TWAMP test packets are sent by the Session-Sender toward the 432 Session-Reflector. In other words, the Port field indicates the 433 port number where the Session-Reflector expects to receive packets 434 from the Session-Sender. 436 When the requested Receiver Port is not available (e.g., port in 437 use), the Server at the Session-Reflector MAY suggest an alternate 438 and available port for this session in the Port Field. The 439 Session-Sender either accepts the alternate port, or composes a new 440 Session-Request message with suitable parameters. Otherwise, the 441 Server at the Session-Reflector uses the Accept Field to convey 442 other forms of session rejection or failure and MUST NOT suggest an 443 alternate port. In this case the Port Field MUST be set to zero. 445 3.6 Send Schedules 447 The Send Schedule for test packets defined in section 3.6 of OWAMP 448 [RFC4656] is not used in TWAMP. The Control-Client and 449 Session-Sender MAY autonomously decide the Send Schedule. The 450 Session-Reflector SHOULD return each test packet to the 451 Session-Sender as quickly as possible. 453 3.7 Starting Test Sessions 455 The procedure and guidelines for Starting test sessions is the same 456 as defined in section 3.7 of OWAMP [RFC4656]. 458 3.8 Stop-Sessions 460 The procedure and guidelines for Stopping test sessions is the same 461 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions 462 command can only be issued by the Control-Client. The message MUST 463 NOT contain any session description records or skip ranges. The 464 message is terminated with a single block HMAC, to complete the 465 Stop-Sessions Command. Since the TWAMP Stop-Sessions command does 466 not convey SIDs, it applies to all sessions previously requested 467 and started with a Start-Sessions command. 469 Thus, the TWAMP Stop-Sessions command is constructed as follows: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | 3 | Accept | MBZ | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Number of Sessions | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | MBZ (8 octets) | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 | HMAC (16 octets) | 483 | | 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Above, the Command Number in the first octet (3) indicates that 488 this is the Stop-Sessions command. 490 Non-zero Accept values indicate a failure of some sort. Zero 491 values indicate normal (but possibly premature) completion. The 492 full list of available Accept values is described in Section 3.3 of 493 [RFC4656], "Values of the Accept Field". 495 If Accept had a non-zero value, results of all TWAMP-Test sessions 496 spawned by this TWAMP-Control session SHOULD be considered invalid. 497 If the Accept message was not transmitted at all (for whatever 498 reason, including failure of the TCP connection used for TWAMP- 499 Control), the results of all TWAMP-Test sessions spawned by this 500 TWAMP-control session MAY be considered invalid. 502 Number of Sessions indicates the number of sessions that the 503 Control-Client intends to stop. 505 Number of Sessions MUST contain the number of send sessions started 506 by the Control-Client that have not been previously terminated by a 507 Stop-Sessions command (i.e., the Control-Client MUST account for 508 each accepted Request-Session). If the Stop-Sessions message does 509 not account for exactly the number of sessions in-progress, then it 510 is to be considered invalid and the TWAMP-Control connection SHOULD 511 be closed and any results obtained considered invalid. 513 Upon receipt of a TWAMP-Control Stop-Sessions command, the Session- 514 Reflector MUST discard any TWAMP-Test packets that arrive at the 515 current time plus the Timeout (in the Request-TW-Session command). 517 3.9 Fetch-Session 519 One purpose of TWAMP is measurement of two-way metrics. Two-way 520 measurement methods do not require packet level data to be 521 collected by the Session-Reflector (such as sequence number, 522 timestamp, and TTL) because this data is communicated in the 523 "reflected" test packets. As such the protocol does not require 524 the retrieval of packet level data from the Server and the OWAMP 525 Fetch-Session command is not used in TWAMP. 527 4. TWAMP Test 529 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 530 protocol with the exception that the Session-Reflector transmits 531 test packets to the Session-Sender in response to each test packet 532 it receives. TWAMP defines two different test packet formats, one 533 for packets transmitted by the Session-Sender and one for packets 534 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 535 protocol there are three modes: unauthenticated, authenticated, and 536 encrypted. 538 4.1 Sender Behavior 540 The sender behavior is determined by the configuration of the 541 Session-Sender and is not defined in this standard. Further, the 542 Session-Reflector does not need to know the Session-Sender behavior 543 to the degree of detail as needed in OWAMP [RFC4656]. 544 Additionally the Session-Sender collects and records the necessary 545 information provided from the packets transmitted by the 546 Session-Reflector for measuring two-way metrics. The information 547 recording based on the received packet by the Session-Sender is 548 implementation dependent. 550 4.1.1 Packet Timings 552 Since the Send Schedule is not communicated to the 553 Session-Reflector, there is no need for a standardized computation 554 of packet timing. 556 Regardless of any scheduling delays, each packet that is actually 557 sent MUST have the best possible approximation of its real time of 558 departure as its timestamp (in the packet). 560 4.1.2 Packet Format and Content 562 The Session-Sender packet format and content follow the same 563 procedure and guidelines as defined in section 4.1.2 of OWAMP 564 [RFC4656] (with the exception of the reference to the Send 565 Schedule). 567 Note that the Reflector test packet formats are larger than the 568 Sender's formats. The Session-Sender MAY append sufficient Packet 569 Padding to allow the same IP packet payload lengths to be used in 570 each direction of transmission (this is usually desirable). To 571 compensate for the Reflector's larger test packet format, the 572 Sender appends at least 27 octets of padding in unauthenticated 573 mode, and at least 56 octets in authenticated and encrypted modes. 575 4.2 Reflector Behavior 577 TWAMP requires the Session-Reflector to transmit a packet to the 578 Session-Sender in response to each packet it receives. 580 As packets are received the Session-Reflector will, 582 - Timestamp the received packet. Each packet that is actually 583 received MUST have the best possible approximation of its real 584 time of arrival entered as its timestamp (in the packet). 586 - In authenticated or encrypted mode, decrypt the appropriate 587 sections of the packet body (first block (16 octets) for 588 authenticated, 96 octets for encrypted), and then check 589 integrity of sections covered by the HMAC. 591 - Copy the packet sequence number into the corresponding reflected 592 packet to the Session-Sender. 594 - Sender TTL value is extracted from the TTL/Hop Limit value of 595 received packets. Session-Reflector Implementations SHOULD 596 fetch the TTL/Hop Limit value from the IP header of the packet, 597 replacing the value of 255 set by the Session-Sender. If an 598 implementation does not fetch the actual TTL value (the only 599 good reason not to do so is an inability to access the TTL 600 field of arriving packets), it MUST set the Sender TTL value as 601 255. 603 - In authenticated and encrypted modes, the HMAC MUST be 604 calculated first, then the appropriate portion of the packet 605 body is encrypted. 607 - Transmit a test packet to the Session-Sender in response to 608 every received packet. The response MUST be generated as 609 immediately as possible. The format and content of the test 610 packet is defined in section 4.2.1. Prior to the transmission 611 of the test packet, the Session-Reflector MUST enter the best 612 possible approximation of its actual sending time of as its 613 Timestamp (in the packet). This permits the determination of 614 the elapsed time between the reception of the packet and its 615 transmission. 617 - Packets not received within the Timeout (following the Stop- 618 Session command) MUST be ignored by the Reflector. The 619 Session-Reflector MUST NOT generate a test packet to the 620 Session-Sender for packets that are ignored. 622 The possibility exists for Session-Sender failure during a session, 623 or the path between the Session-Sender and Session-Reflector may 624 fail while a test session is in-progress. The Session-Reflector MAY 625 discontinue any session which has been Started when no packet 626 associated with that session has been received for REFWAIT seconds. 627 The default value of REFWAIT SHALL be 900 seconds, and this waiting 628 time MAY be configurable. This time-out allows a Session-Reflector 629 to free-up resources in case of failure. 631 4.2.1 TWAMP-Test Packet Format and Content 633 The Session-Reflector MUST transmit a packet to the Session-Sender 634 in response to each packet received. The Session-Reflector SHOULD 635 transmit the packets as immediately as possible. The 636 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 637 in the UDP packet to 255. 639 The test packet will have the necessary information for calculating 640 two-way metrics by the Session-Sender. The format of the test 641 packet depends on the mode being used. The two formats are 642 presented below. 644 For unauthenticated mode: 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Sequence Number | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Timestamp | 652 | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Error Estimate | MBZ | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Receive Timestamp | 657 | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Sender Sequence Number | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Sender Timestamp | 662 | | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Sender Error Estimate | MBZ | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Sender TTL | | 667 +-+-+-+-+-+-+-+-+ + 668 | | 669 . . 670 . Packet Padding . 671 . . 672 | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 For authenticated and encrypted modes: 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sequence Number | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | MBZ (12 octets) | 682 | | 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Timestamp | 686 | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Error Estimate | | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 690 | MBZ (6 octets) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Receive Timestamp | 693 | | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | MBZ (8 octets) | 696 | | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Sender Sequence Number | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | MBZ (12 octets) | 701 | | 702 | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Sender Timestamp | 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Sender Error Estimate | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 709 | MBZ (6 octets) | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Sender TTL | | 712 +-+-+-+-+-+-+-+-+ + 713 | | 714 | | 715 | MBZ (15 octets) | 716 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 717 | HMAC (16 octets) | 718 | | 719 | | 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 722 | | 723 . . 724 . Packet Padding . 725 . . 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Note that all Timestamps have the same format as OWAMP [RFC4656] as 730 follows: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Integer part of seconds | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Fractional part of seconds | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Sequence Number is the sequence number of the test packet according 741 to its transmit order. It starts with zero and is incremented by 742 one for each subsequent packet. The Sequence Number generated by 743 the Session-Reflector is independent from the sequence number of 744 the arriving packets. 746 Timestamp and Error Estimate are the Session-Reflector's transmit 747 timestamp and error estimate for the reflected test packet, 748 respectively. The format of all timestamp and error estimate 749 fields follow the definition and formats defined by OWAMP section 750 4.1.2, in [RFC4656]. 752 Sender Timestamp and Sender Error Estimate are exact copies of the 753 timestamp and error estimate from the Session-Sender test packet 754 that corresponds to this test packet. 756 Sender TTL is 255 when transmitted by the Session Sender. Sender 757 TTL is set to the Time To Live (or Hop Count) value of the received 758 packet from the IP packet header when transmitted by the Session 759 Reflector. 761 Receive Timestamp is the time the test packet was received by the 762 reflector. The difference between Timestamp and Receive Timestamp 763 is the amount of time the packet was in transition in the 764 Session-Reflector. The Error Estimate associated with the 765 Timestamp field also applies to the Receive Timestamp. 767 Sender Sequence Number is a copy of the Sequence Number of the 768 packet transmitted by the Session-Sender that caused the 769 Session-Reflector to generate and send this test packet. 771 The HMAC field in TWAMP-Test packets covers the same fields as the 772 AES encryption. Thus, in authenticated mode, HMAC covers the first 773 block (16 octets). In encrypted mode, HMAC covers the first six 774 blocks (96 octets). In TWAMP-Test, the HMAC field MUST NOT be 775 encrypted. 777 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 778 generated independently of any other pseudo-random numbers 779 mentioned in this document). However, implementations MUST provide 780 a configuration parameter, an option, or a different means of 781 making Packet Padding consist of all zeros. Packet Padding MUST NOT 782 be covered by the HMAC and MUST NOT be encrypted. 784 The minimum data segment length of TWAMP-Test packets in 785 unauthenticated mode is 41 octets, and 104 octets in both 786 authenticated mode and encrypted modes. 788 Note that the Session-Reflector Test Packet Formats are larger than 789 the Sender's formats. The Session-Reflector SHOULD reduce the 790 length of the Sender's Packet Padding to achieve equal IP packet 791 payload lengths in each direction of transmission, when sufficient 792 padding is present. The Session-Reflector MAY re-use the Sender's 793 Packet Padding (since the requirements for padding generation are 794 the same for each), and in this case the Session-Reflector SHOULD 795 truncate the padding such that the highest number octets are 796 discarded. 798 In unauthenticated mode, encryption or authentication MUST NOT be 799 applied. 801 The TWAMP-Test packet layout is identical in authenticated and 802 encrypted modes. The encryption operation for a Session-Sender 803 packet follows the same rules of Session-Sender packets as defined 804 in OWAMP section 4.1.2 of [RFC4656]. 806 The main difference between authenticated mode and encrypted mode 807 is the portions of the test packets that are covered by HMAC and 808 encrypted. Authenticated mode permits the timestamp to be fetched 809 after a portion of the packet is encrypted, but in encrypted mode 810 all the sequence numbers and timestamps are fetched before 811 encryption to provide maximum data integrity protection. 813 In authenticated mode, only the sequence number in the first block 814 is encrypted and the subsequent timestamps and sequence numbers are 815 sent in clear text. Sending the timestamp in clear text allows one 816 to reduce the time between when a timestamp is obtained by a 817 Session-Reflector and when that packet is sent out. This 818 potentially improves the timestamp accuracy, because the sequence 819 number can be encrypted before the timestamp is fetched. 821 In encrypted mode, the reflector MUST fetch the timestamps, 822 generate the HMAC and encrypt the packet, then send it. 824 Obtaining the keys and encryption methods follow the same procedure 825 as OWAMP as described below. Each TWAMP-Test session has two keys 826 an AES Session-key and an HMAC Session-key, and the keys are 827 derived from the TWAMP-Control keys and the SID. 829 The TWAMP-Test AES Session-key is obtained as follows: the 830 TWAMP-Control AES Session-key (the same AES Session-key as used for 831 the corresponding TWAMP-Control session) is encrypted with the 16- 832 octet session identifier (SID) as the key, using a single-block 833 AES-ECB encryption. The result is the TWAMP-Test AES Session-key to 834 use in encrypting (and decrypting) the packets of the particular 835 TWAMP-Test session. Note that the TWAMP-Test AES Session-key, 836 TWAMP-Control AES Session-key, and the SID are all comprised of 16 837 octets. 839 The TWAMP-Test HMAC Session-key is obtained as follows: the 840 TWAMP-Control HMAC Session-key (the same HMAC Session-key as used 841 for the corresponding TWAMP-Control session) is encrypted using 842 AES-CBC with the 16-octet session identifier (SID) as the key. This 843 is a two-block CBC encryption always performed with IV=0. Note that 844 the TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key 845 are comprised of 32 octets, while the SID is 16 octets. 847 In authenticated mode, the first block (16 octets) of each TWAMP- 848 Test packet is encrypted using AES Electronic Codebook (ECB) mode. 849 This mode does not involve any chaining, and lost, duplicated, or 850 reordered packets do not cause problems with deciphering any packet 851 in a TWAMP-Test session. 853 In encrypted mode, the first six blocks (96octets) are encrypted 854 using AES CBC mode. The AES Session-key to use is obtained in the 855 same way as the key for authenticated mode. Each TWAMP-Test packet 856 is encrypted as a separate stream, with just one chaining 857 operation; chaining does not span multiple packets so that lost, 858 duplicated, or reordered packets do not cause problems. The 859 initialization vector for the CBC encryption is a value with all 860 bits equal to zero. 862 Implementation note: Naturally, the key schedule for each 863 TWAMP-Test session MUST be set up at most once per session, not 864 once per packet. 866 5. Implementers Guide 868 This section serves as guidance to implementers of TWAMP. The 869 example architecture presented here is not a requirement. Similar 870 to OWAMP [RFC4656], TWAMP is designed with enough flexibility to 871 allow different architectures that suit multiple system 872 requirements. 874 In this example the roles of Control-Client and Session-Sender are 875 implemented in one host referred to as the controller and the roles 876 of Server and Session-Reflector are implemented in another host 877 referred to as the responder. 879 controller responder 880 +-----------------+ +-------------------+ 881 | Control-Client |<--TWAMP-Control-->| Server | 882 | | | | 883 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 884 +-----------------+ +-------------------+ 886 This example provides an architecture that supports the full TWAMP 887 standard. The controller establishes the test session with the 888 responder through the TWAMP-Control protocol. After the session is 889 established the controller transmits test packets to the responder. 890 The responder follows the Session-Reflector behavior of TWAMP as 891 described in section 4.2. 893 Appendix I provides an example for purely informational purposes. 894 It suggests an incremental path to adopting TWAMP, by implementing 895 the TWAMP-Test protocol first. 897 6. Security Considerations 899 Fundamentally TWAMP and OWAMP use the same protocol for 900 establishment of Control and Test procedures. The main difference 901 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 902 vs. the Session-Receiver behavior in OWAMP. This difference in 903 behavior does not introduce any known security vulnerabilities that 904 are not already addressed by the security features of OWAMP. The 905 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 907 The Server Greeting message (defined in OWAMP, section 3.1 908 [RFC4656]) includes a "Count" field to specify the iteration 909 counter used in PKCS #5 to generate keys from shared secrets. OWAMP 910 recommends a lower limit of 1024 iterations, but no upper limit. 911 The Count field provides an opportunity for a DOS attack because it 912 is 32 bits long. If an attacking system set the maximum value in 913 Count (2**32), it could stall a system attempting to generate keys 914 for a significant period of time. Therefore, TWAMP-compliant 915 systems SHOULD have a configuration control to limit the maximum 916 Count value. The default maximum Count value SHOULD be 32768. As 917 suggested in OWAMP, this value MAY be increased when greater 918 computing power becomes common. If a Control-Client receives a 919 Server Greeting Message with Count greater that its maximum 920 configured value, it SHOULD close the control connection. 922 7. Acknowledgements 924 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 925 Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and 926 Murtaza Chiba for their comments, suggestions, reviews, helpful 927 discussion and proof-reading. Lars Eggert, Sam Hartman, and Tim 928 Polk contributed very useful AD-level reviews, and the authors 929 thank them for their contributions to the memo. 931 8. IANA Considerations 933 IANA has allocated a well-known TCP port number (861) for the 934 OWAMP-Control part of the OWAMP [RFC4656] protocol. 935 ... 936 owamp-control 861/tcp OWAMP-Control 937 owamp-control 861/udp OWAMP-Control 938 # [RFC4656] 939 # 862-872 Unassigned 941 IANA is requested to allocate a well-known TCP/UDP port number for 942 the TWAMP-Control protocol. It would be ideal if the port number 943 assignment was adjacent to the OWAMP assignment. The recommended 944 Keyword for this entry is "twamp-control" and the Description is 945 "Two-way Active Measurement Protocol (TWAMP) Control". 947 During final editing, port N in section 3.1 should be replaced with 948 the assigned port number. 950 Since TWAMP adds an additional Control command to the OWAMP-Control 951 specification, and describes behavior when this control command is 952 used, this memo requests creation an IANA registry for the TWAMP 953 Command Number field. The field is not explicitly named in 954 [RFC4656] but is called out for each command. This field is a 955 recognized extension mechanism for TWAMP. 957 8.1 Registry Specification 959 IANA will create an TWAMP-Control Command Number registry. TWAMP- 960 Control commands are specified by the first octet in OWAMP-Control 961 messages as shown in section 3.5 of [RFC4656], and modified by this 962 document. Thus this registry may contain sixteen possible values. 964 8.2 Registry Management 966 Because the registry may only contain sixteen values, and because 967 OWAMP and TWAMP are IETF protocols, this registry must only be 968 updated by "IETF Consensus" as specified in [RFC2434] -- an RFC 969 documenting the use that is approved by the IESG. We expect that 970 new values will be assigned as monotonically increasing integers in 971 the range [0-15], unless there is a good reason to do otherwise. 973 8.3 Experimental Numbers 975 [RFC3692] recommends allocating an appropriate number of values for 976 experimentation and testing. It is not clear to the authors 977 exactly how many numbers might be useful in this space, nor if it 978 would be useful that they were easily distinguishable or at the 979 "high end" of the number range. Two might be useful, say one for 980 session control, and one for session fetch. On the other hand, a 981 single number would allow for unlimited extension, because the 982 format of the rest of the message could be tailored, with 983 allocation of other numbers done once usefulness has been proven. 984 Thus, this document will allocate one number, the next sequential 985 number 6, as designated for experimentation and testing. 987 8.4 Initial Registry Contents 989 TWAMP-Control Command Number Registry 991 Value Description Semantics Definition 992 0 Reserved 993 1 Forbidden 994 2 Start-Sessions RFC4656, Section 3.7 995 3 Stop-Sessions RFC4656, Section 3.8 996 4 Reserved 997 5 Request-TW-Session this document, Section 3.5 998 6 Experimentation undefined, see Section 8.3. 1000 9. Internationalization Considerations 1002 The protocol does not carry any information in a natural language, 1003 with the possible exception of the KeyID in TWAMP-Control, which is 1004 encoded in UTF-8 [RFC3629, RFC5198]. 1006 10. APPENDIX I - TWAMP Light (Informative) 1008 In this example the roles of Control-Client, Server, and 1009 Session-Sender are implemented in one host referred to as the 1010 controller and the role of Session-Reflector is implemented in 1011 another host referred to as the responder. 1013 controller responder 1014 +-----------------+ +-------------------+ 1015 | Server |<----------------->| | 1016 | Control-Client | | Session-Reflector | 1017 | Session-Sender |<--TWAMP-Test----->| | 1018 +-----------------+ +-------------------+ 1020 This example provides a simple architecture for responders where 1021 their role will be to simply act as light test points in the 1022 network. The controller establishes the test session with the 1023 Server through non-standard means. After the session is 1024 established the controller transmits test packets to the responder. 1025 The responder follows the Session-Reflector behavior of TWAMP as 1026 described in section 4.2 with the following exceptions. 1028 In the case of TWAMP Light, the Session-Reflector does not 1029 necessarily have knowledge of the session state. IF the 1030 Session-Reflector does not have knowledge of the session state, 1031 THEN the Session-Reflector MUST copy the Sequence Number of the 1032 received packet to the Sequence Number field of the reflected 1033 packet. The controller receives the reflected test packets and 1034 collects two-way metrics. This architecture allows for collection 1035 of two-way metrics. 1037 This example eliminates the need for the TWAMP-Control protocol and 1038 assumes that the Session-Reflector is configured and communicates 1039 its configuration with the Server through non-standard means. The 1040 Session-Reflector simply reflects the incoming packets back to the 1041 controller while copying the necessary information and generating 1042 sequence number and timestamp values per section 4.2.1. 1043 TWAMP Light introduces some additional security considerations. The 1044 non-standard means to control the responder and establish test 1045 sessions SHOULD offer the features listed below. 1047 The non-standard responder control protocol SHOULD have an 1048 authenticated mode of operation. The responder SHOULD be 1049 configurable to accept only authenticated control sessions. 1051 The non-standard responder control protocol SHOULD have a means to 1052 activate the authenticated and encrypted modes of the TWAMP-Test 1053 protocol. 1055 When the TWAMP Light test sessions operate in authenticated or 1056 encrypted mode, the Session-Reflector MUST have some mechanism for 1057 generating keys (because the TWAMP-Control protocol normally plays 1058 a role in this process, but is not present here). The specification 1059 of the key generation mechanism is beyond the scope of this memo. 1061 11. References 1063 11.1 Normative References 1065 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 1066 Zekauskas, M., "A One-way Active Measurement Protocol 1067 (OWAMP)", RFC 4656, October 2004. 1069 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 1070 Round-Trip Delay Metric for IPPM". RFC 2681, 1071 September 1999. 1073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1074 Requirement Levels", BCP 14, RFC 2119, March 1997. 1076 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1077 Definition of the Differentiated Services Field (DS 1078 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1079 December 1998. 1081 [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing 1082 an IANA Considerations Section in RFCs, RFC 2434, 1083 October 1998. 1085 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1086 10646", STD 63, RFC 3629, November 2003. 1088 [RFC5198] Klensin, J., Padlipsky, M., "Unicode Format for 1089 Network Interchange", RFC 5198, March 2008. 1091 11.2 Informative References 1093 [RFC3692] Narten, T., Assigning Experimental and Testing Numbers 1094 Considered Useful, RFC 3692, January 2004. 1096 Authors' Addresses 1098 Kaynam Hedayat 1099 Brix Networks 1100 285 Mill Road 1101 Chelmsford, MA 01824 1102 USA 1103 EMail: khedayat@brixnet.com 1104 URI: http://www.brixnet.com/ 1106 Roman M. Krzanowski, Ph.D. 1107 Verizon 1108 500 Westchester Ave. 1109 White Plains, NY 1110 USA 1111 EMail: roman.krzanowski@verizon.com 1112 URI: http://www.verizon.com/ 1114 Al Morton 1115 AT&T Labs 1116 Room D3 - 3C06 1117 200 Laurel Ave. South 1118 Middletown, NJ 07748 1119 USA 1120 Phone +1 732 420 1571 1121 EMail: acmorton@att.com 1122 URI: http://home.comcast.net/~acmacm/ 1124 Kiho Yum 1125 Juniper Networks 1126 1194 Mathilda Ave. 1127 Sunnyvale, CA 1128 USA 1129 EMail: kyum@juniper.net 1130 URI: http://www.juniper.com/ 1132 Jozef Z. Babiarz 1133 Nortel Networks 1134 3500 Carling Avenue 1135 Ottawa, Ont K2H 8E9 1136 Canada 1137 Email: babiarz@nortel.com 1138 URI: http://www.nortel.com/ 1140 Full Copyright Statement 1142 Copyright (C) The IETF Trust (2008). 1144 This document is subject to the rights, licenses and restrictions 1145 contained in BCP 78, and except as set forth therein, the authors 1146 retain all their rights. 1148 This document and the information contained herein are provided on 1149 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1150 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1151 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1152 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1153 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1154 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1155 FOR A PARTICULAR PURPOSE. 1157 Intellectual Property 1159 The IETF takes no position regarding the validity or scope of any 1160 Intellectual Property Rights or other rights that might be claimed 1161 to pertain to the implementation or use of the technology described 1162 in this document or the extent to which any license under such 1163 rights might or might not be available; nor does it represent that 1164 it has made any independent effort to identify any such rights. 1165 Information on the procedures with respect to rights in RFC 1166 documents can be found in BCP 78 and BCP 79. 1168 Copies of IPR disclosures made to the IETF Secretariat and any 1169 assurances of licenses to be made available, or the result of an 1170 attempt made to obtain a general license or permission for the use 1171 of such proprietary rights by implementers or users of this 1172 specification can be obtained from the IETF on-line IPR repository 1173 at http://www.ietf.org/ipr. 1175 The IETF invites any interested party to bring to its attention any 1176 copyrights, patents or patent applications, or other proprietary 1177 rights that may cover technology that may be required to implement 1178 this standard. Please address the information to the IETF at 1179 ietf-ipr@ietf.org. 1181 Acknowledgement 1183 Funding for the RFC Editor function is provided by the IETF 1184 Administrative Support Activity (IASA).