idnits 2.17.1 draft-ietf-ippm-twamp-03.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 821. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4656]), 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 -- 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 (March 2007) is 6252 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) == Outdated reference: A later version (-16) exists of draft-ietf-ippm-owdp-11 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 K. Hedayat 3 Internet Draft Brix Networks 4 Expires: September 2007 R. Krzanowski 5 Verizon 6 K. Yum 7 Juniper Networks 8 A. Morton 9 AT&T Labs 10 J. Babiarz 11 Nortel Networks 12 March 2007 14 A Two-way Active Measurement Protocol (TWAMP) 15 draft-ietf-ippm-twamp-03 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP) 47 provides a common protocol for measuring one-way metrics between 48 network devices. OWAMP can be used bi-directionally to measure 49 one-way metrics in both directions between two network elements. 50 However, it does not accommodate round-trip or two-way 51 measurements. This memo specifies a Two-way Active Measurement 52 Protocol (TWAMP), based on the OWAMP, that adds two-way or 53 round-trip measurement capabilities. The TWAMP measurement 54 architecture is usually comprised of two hosts with specific roles, 55 and this allows for some protocol simplifications, making it an 56 attractive alternative in some circumstances. 58 Table of Contents 60 1. Introduction..................................................3 61 1.1 Relationship of Test and Control Protocols................3 62 1.2 Logical Model.............................................3 63 2. Protocol Overview.............................................5 64 3. TWAMP Control.................................................5 65 3.1 Connection Setup..........................................5 66 3.2 Integrity Protection......................................6 67 3.3 Value of the Accept Fields................................6 68 3.4 TWAMP Control Commands....................................6 69 3.5 Creating Test Sessions....................................6 70 3.6 Send Schedules............................................8 71 3.7 Starting Test Sessions....................................8 72 3.8 Stop-Sessions.............................................8 73 3.9 Fetch-Session.............................................8 74 4. TWAMP Test....................................................8 75 4.1 Sender Behavior...........................................9 76 4.2 Reflector Behavior........................................9 77 5. Implementers Guide...........................................15 78 5.1 Complete TWAMP...........................................15 79 5.2 TWAMP Light..............................................16 80 6. Security Considerations......................................17 81 7. Acknowledgements.............................................17 82 8. IANA Considerations..........................................17 83 9. Internationalization Considerations..........................17 84 10. References..................................................18 85 10.1 Normative References....................................18 87 1. Introduction 89 The IETF IP Performance Metrics (IPPM) working group has completed 90 a draft standard for the round-trip delay [RFC2681] metric. IPPM 91 has also completed a protocol for the control and collection of 92 one-way measurements, the One-way Active Measurement Protocol 93 (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip 94 or two-way measurements. 96 Two-way measurements are common in IP networks, primarily because 97 time accuracy is less demanding for round-trip delay, and 98 measurement support at the remote end may be limited to a simple 99 echo function. This memo specifies the Two-way Active Measurement 100 Protocol, or TWAMP. TWAMP uses the methodology and architecture of 101 OWAMP [RFC4656] to define an open protocol for measurement of 102 two-way or round-trip metrics (henceforth in this document the term 103 two-way also signifies round-trip). The TWAMP measurement 104 architecture is usually comprised of only two hosts with specific 105 roles, and this allows for some protocol simplifications, making it 106 an attractive alternative in some circumstances. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 109 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 RFC 2119 [RFC2119]. 113 1.1 Relationship of Test and Control Protocols 115 Similar to OWAMP [RFC4656], TWAMP consists of two inter-related 116 protocols: TWAMP-Control and TWAMP-Test. The relationship of these 117 protocols is as defined in section 1.1 of OWAMP [RFC4656]. 119 1.2 Logical Model 121 The role and definition of the logical entities are as defined in 122 section 1.2 of OWAMP [RFC4656] with the following exceptions: 124 - The Session-Receiver is called the Session-Reflector in the 125 TWAMP architecture. The Session-Reflector has the capability 126 to create and send a measurement packet when it receives a 127 measurement packet. Unlike the Session-Receiver, the 128 Session-Reflector does not collect any packet information. 130 - The Server is an end system that manages one or more TWAMP 131 sessions, and is capable of configuring per-session state in 132 the end-points. However, a Server associated with a 133 Session-Reflector would not have the capability to return the 134 results of a test session, and this is a difference from OWAMP. 136 - The Fetch-Client entity does not exist in the TWAMP 137 architecture, as the Session-Reflector does not collect any 138 packet information to be fetched. Consequently there is no 139 need for the Fetch-Client. 141 An example of possible relationship scenarios between these roles 142 are presented below. In this example different logical roles are 143 played on different hosts. Unlabeled links in the figure are 144 unspecified by this document and may be proprietary protocols. 146 +----------------+ +-------------------+ 147 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 148 +----------------+ +-------------------+ 149 ^ ^ 150 | | 151 | | 152 | | 153 | +----------------+<----------------+ 154 | | Server | 155 | +----------------+ 156 | ^ 157 | | 158 | TWAMP-Control 159 | | 160 v v 161 +----------------+ 162 | Control-Client | 163 +----------------+ 165 As in OWAMP [RFC4656], different logical roles can be played by the 166 same host. For example, in the figure above, there could be 167 actually two hosts: one playing the roles of Control-Client and 168 Session-Sender, and the other playing the roles of Server and 169 Session-Reflector. This example is shown below. 171 +-----------------+ +-------------------+ 172 | Control-Client |<--TWAMP Control-->| Server | 173 | | | | 174 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 175 +-----------------+ +-------------------+ 177 Additionally, following the guidelines of OWAMP [RFC4656], TWAMP 178 has been defined to allow for small test packets that would fit 179 inside the payload of a single ATM cell (only in unauthenticated 180 mode). 182 2. Protocol Overview 184 The Two-way Active Measurement Protocol is an open protocol for 185 measurement of two-way metrics. It is based on OWAMP [RFC4656] and 186 adheres to its overall architecture and design. The protocol 187 defined in this document extends and changes OWAMP [RFC4656] as 188 follows: 190 - Define a new logical entity, Session-Reflector, in place of the 191 Session-Receiver. 193 - Define the Session-Reflector behavior in place of the 194 Session-Receiver behavior of OWAMP [RFC4656]. 196 - Define a new test packet format for packets transmitted from the 197 Session-Reflector to Session-Sender. 199 - Fetch client does not exist in the TWAMP architecture. 201 3. TWAMP Control 203 All TWAMP Control messages are similar in format and follow similar 204 guidelines to those defined in section 3 of OWAMP [RFC4656] with 205 the exceptions outlined in the following sections. All OWAMP 206 [RFC4656] Control messages except for the Fetch-Session command 207 apply to TWAMP. 209 3.1 Connection Setup 211 Connection establishment of TWAMP follows the same procedure 212 defined in section 3.1 of OWAMP [RFC4656]. The host that initiates 213 the TCP connection takes the roles of Control-Client and (in the 214 two-host implementation) the Session-Sender. The host that 215 acknowledges the TCP connection accepts the roles of Server and (in 216 the two-host implementation) the Session Reflector. 218 3.2 Integrity Protection 220 Integrity protection of TWAMP follows the same procedure defined in 221 section 3.2 of OWAMP [RFC4656]. 223 3.3 Value of the Accept Fields 225 Accept values used in TWAMP are the same as the values defined in 226 section 3.3 of OWAMP [RFC4656]. 228 3.4 TWAMP Control Commands 230 TWAMP control commands are as defined in section 3.4 of OWAMP 231 [RFC4656] except that the Fetch-Session command does not apply to 232 TWAMP. 234 3.5 Creating Test Sessions 236 Test sessions creation follows the same procedure as defined in 237 section 3.5 of OWAMP [RFC4656]. 239 In order to distinguish the session as a two-way versus a one-way 240 measurement session the first octet of the Request-Session command 241 MUST be set to 5. Value of 5 indicates that this is a 242 Request-Session for a two-way metrics measurement session. 244 In OWAMP, the Conf-Sender field is set to 1 when the 245 Request-Session message describes a task where the Server will 246 configure a one-way test packet sender. Likewise, the 247 Conf-Receiver field is set to 1 when the message describes the 248 configuration for a Session-Receiver. In TWAMP, both endpoints 249 perform in these roles, with the Session-Sender first sending and 250 then receiving test packets. The Session-Reflector first receives 251 the test packets, and returns each test packet to the 252 Session-Sender as fast as possible. 254 Both Conf-Sender and Conf-Receiver MUST be set to 0 since the 255 Session-Reflector will both receive and send packets, and the roles 256 are established according to which host initiates the TCP 257 connection for control. The server MUST interpret any non-zero 258 value as zero. 260 The Session-Reflector in TWAMP does not process incoming test 261 packets for performance metrics and consequently does not need to 262 know the number of incoming packets and their timing schedule. 263 Consequently the Number of Scheduled Slots and Number of Packets 264 MUST be set to 0. 266 The Sender Port is the UDP port from which TWAMP-Test packets will 267 be sent. Receiver Port is the UDP port to which TWAMP test packets 268 are reflected by the Session-Reflector (the port where the 269 Session-Sender wants to receive test packets). 271 The Sender Address and Receiver Address fields contain, 272 respectively, the sender and receiver addresses of the endpoints of 273 the Internet path over which a TWAMP test session is requested. 274 They MAY be set to 0, in which case the IP addresses used for the 275 Session-Sender to Session-Reflector Control Message exchange MUST 276 be used in the test packets. 278 The SID is as defined in OWAMP [RFC4656]. Since the SID is always 279 generated by the receiving side, the Session-Reflector determines 280 the SID, and the SID in the Request-Session message MUST be set to 281 0. 283 The Start Time is as as defined in OWAMP [RFC4656]. 285 The Timeout is interpreted differently from the definition in OWAMP 286 [RFC4656]. In TWAMP, Timeout is the interval that the 287 Session-Reflector MUST wait after receiving a Stop-Sessions 288 message. In case there are test packets still in transit, the 289 Session Reflector MUST reflect them if they arrive within the 290 timeout interval following the reception of the Stop-Sessions 291 message. The Session-Reflector MUST NOT reflect packets that are 292 received beyond the timeout. 294 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 295 capability of this field is to set the Differentiated Services Code 296 Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST 297 be used in test packets reflected by the Session-Reflector. 299 Since there are no Schedule Slot Descriptions, the Request-Session 300 Message is completed by MBZ and HMAC fields. This completes one 301 logical message, referred to as the Request-Session Command. 303 The Session-Reflector MUST respond to each Request-Session Command 304 with an Accept-Message as defined in OWAMP [RFC4656]. The Port is 305 the port to which TWAMP test packets are sent by the Session-Sender 306 toward the Session-Reflector. In other words, the Port field 307 indicates the port number where the Session-Reflector expects to 308 receive packets from the Session-Sender. 310 3.6 Send Schedules 312 The Send Schedule for test packets defined in section 3.6 of OWAMP 313 [RFC4656] is not used in TWAMP. The Control-Client and 314 Session-Sender MAY autonomously decide the Send Schedule. The 315 Session-Reflector SHOULD return each test packet to the 316 Session-Sender as quickly as possible. 318 3.7 Starting Test Sessions 320 The procedure and guidelines for Starting test sessions is the same 321 as defined in section 3.7 of OWAMP [RFC4656]. 323 3.8 Stop-Sessions 325 The procedure and guidelines for Stopping test sessions is the same 326 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session 327 command can only be issued by the Session-Sender. The Next SeqNo 328 and Number of Skip Ranges MUST be set to 0 and the message MUST NOT 329 contain any session description records or skip ranges. The 330 message is terminated with a single block HMAC, to complete the 331 Stop-Sessions Command. 333 3.9 Fetch-Session 335 The purpose of TWAMP is measurement of two-way metrics. Two-way 336 measurements do not rely on packet level data collected by the 337 Session-Reflector such as sequence number, timestamp, and TTL. As 338 such the protocol does not require the retrieval of packet level 339 data from the Server and the Fetch-Session command is not defined 340 in TWAMP. 342 4. TWAMP Test 344 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 345 protocol with the exception that the Session-Reflector transmits 346 test packets to the Session-Sender in response to each test packet 347 it receives. TWAMP defines two different test packet formats, one 348 for packets transmitted by the Session-Sender and one for packets 349 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 350 protocol there are three modes: unauthenticated, authenticated, and 351 encrypted. 353 4.1 Sender Behavior 355 The sender behavior is determined by the configuration of the 356 Session-Sender and is not defined in this standard. Further, the 357 Session-Reflector does not need to know the Session-Sender 358 behaviour to the degree of detail as needed in OWAMP [RFC4656]. 359 Additionally the Session-Sender collects and records the necessary 360 information provided from the packets transmitted by the 361 Session-Reflector for measuring two-way metrics. The information 362 recording based on the received packet by the Session-Sender is 363 implementation dependent. 365 4.1.1 Packet Timings 367 Since the Send Schedule is not communicated to the 368 Session-Reflector, there is no need for a standardized computation 369 of packet timing. 371 Regardless of any scheduling delays, each packet that is actually 372 sent MUST have the best possible approximation of its real time of 373 departure as its timestamp (in the packet). 375 4.1.2 Packet Format and Content 377 The Session-Sender packet format and content follow the same 378 procedure and guidelines as defined in section 4.1.2 of OWAMP 379 [RFC4656] (with the exception of the reference to the Send 380 Schedule). 382 4.2 Reflector Behavior 384 TWAMP requires the Session-Reflector to transmit a packet to the 385 Session-Sender in response to each packet it receives. 387 As packets are received the Session-Reflector will, 389 - Timestamp the received packet. Each packet that is actually 390 received MUST have the best possible approximation of its real 391 time of arrival entered as its timestamp (in the packet). 393 - In authenticated or encrypted mode, decrypt the first block (16 394 octets) of the packet body. 396 - Copy the packet sequence number into the corresponding reflected 397 packet to the Session-Sender. 399 - Transmit a test packet to the Session-Sender in response to 400 every received packet. The response MUST be generated as 401 immediately as possible. The format and content of the test 402 packet is defined in section 5.2.1. Prior to the transmission 403 of the test packet, the Session-Reflector MUST enter the best 404 possible approximation of its actual sending time of as its 405 Timestamp (in the packet). This permits the determination of the 406 elapsed time between the reception of the packet and its 407 transmission. 409 - Packets not received within the Timeout are ignored by the 410 Reflector. The Session-Reflector MUST NOT generate a test 411 packet to the Session-Sender for packets that are ignored. 413 4.2.1 TWAMP-Test Packet Format and Content 415 The Session-Reflector MUST transmit a packet to the Session-Sender 416 in response to each packet received. The Session-Reflector SHOULD 417 transmit the packets as immediately as possible. The 418 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 419 in the UDP packet to 255. 421 The test packet will have the necessary information for calculating 422 two-way metrics by the Session-Sender. The format of the test 423 packet depends on the mode being used. The various formats of the 424 packet are presented below. 426 For unauthenticated mode: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Sequence Number | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Timestamp | 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Error Estimate | MBZ | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Receive Timestamp | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Sender Sequence Number | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Sender Timestamp | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Sender Error Estimate | MBZ | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 . . 450 . Packet Padding . 451 . . 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 For authenticated and encrypted modes: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Sequence Number | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | MBZ (12 octets) | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Timestamp | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Error Estimate | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 469 | MBZ (6 octets) | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Receive Timestamp | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | MBZ (8 octets) | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 478 | Sender Sequence Number | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | MBZ (12 octets) | 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Sender Timestamp | 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Sender Error Estimate | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 488 | MBZ (6 octets) | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | HMAC (16 octets) | 492 | | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 496 | | 497 . . 498 . Packet Padding . 499 . . 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Sequence Number is the sequence number of the test packet according 503 to its arrival at the Session-Reflector. It starts with zero and 504 is incremented by one for each subsequent packet. The Sequence 505 Number generated by the Session-Reflector is independent from the 506 sequence number of the arriving packets. 508 Timestamp and Error Estimate are the Session-Reflector's transmit 509 timestamp and error estimate for the reflected test packet, 510 respectively. The format of all timestamp and error estimate 511 fields follow the definition and formats defined by OWAMP[RFC4656]. 513 Sender Timestamp and Sender Error Estimate are exact copies of the 514 timestamp and error estimate from the Session-Sender test packet 515 that corresponds to this test packet. 517 Receive Timestamp is the time the test packet was received by the 518 reflector. The difference between Timestamp and Receive Timestamp 519 is the amount of time the packet was in transition in the 520 Session-Reflector. The Error Estimate associated with the 521 Timestamp field also applies to the Receive Timestamp. 523 Sender Sequence Number is a copy of the Sequence Number of the 524 packet transmitted by the Session-Sender that caused the 525 Session-Reflector to generate and send this test packet. 527 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 528 authenticated and encrypted modes. The encryption operation of 529 Session-Sender packet follow the same rules of Session-Sender 530 packets as defined in OWAMP [RFC4656]. 532 The minimum data segment length is, therefore, 40 octets in 533 unauthenticated mode, and 80 octets in both authenticated mode and 534 encrypted modes (with the implication that the later two modes will 535 not fit in a single ATM cell). 537 The Session-Reflector TWAMP-Test packet layout is the same in 538 authenticated and encrypted modes. The encryption operations are, 539 however, different. The difference is that in encrypted mode both 540 the sequence numbers and timestamps are encrypted to provide 541 maximum data integrity protection while in authenticated mode the 542 sequence numbers are encrypted and the timestamps are sent in clear 543 text. Sending the timestamp in clear text in authenticated mode 544 allows one to reduce the time between when a timestamp is obtained 545 by a reflector and when the packet is reflected out. In encrypted 546 mode, both the sender and reflector have to fetch the timestamp, 547 encrypt it, and send it; in authenticated mode, the middle step is 548 removed, potentially improving accuracy (the sequence number can be 549 encrypted before the timestamp is fetched). 551 In authenticated mode, the first block (16 octets) of each packet 552 is encrypted using AES Electronic Cookbook (ECB) mode. 554 Obtaining the key, encryption method, and packet padding follows 555 the same procedure as OWAMP as described below. 556 Similarly to each TWAMP-Control session, each TWAMP-Test session 557 has two keys: an AES Session-key and an HMAC Session-key. However, 558 there is a difference in how the keys are obtained: in the case of 559 TWAMP-Control, the keys are generated by the client and 560 communicated (as part of the Token) during connection setup as part 561 of Set-Up-Response message; in the case of TWAMP-Test, described 562 here, the keys are derived from the TWAMP-Control keys and the SID. 564 The TWAMP-Test AES Session-key is obtained as follows: the 565 TWAMP-Control AES Session-key (the same AES Session-key as is used 566 for the corresponding TWAMP-Control session, where it is used in a 567 different chaining mode) is encrypted, using AES, with the 16-octet 568 session identifier (SID) as the key; this is a single-block ECB 569 encryption; its result is the TWAMP-Test AES Session-key to use in 570 encrypting (and decrypting) the packets of the particular 571 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 572 TWAMP-Control AES Session-key, and the SID are comprised of 16 573 octets. 575 The TWAMP-Test HMAC Session-key is obtained as follows: the 576 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 577 used for the corresponding TWAMP-Control session) is encrypted, 578 using AES, with the 16-octet session identifier (SID) as the key; 579 this is a two-block CBC encryption, always performed with IV=0; its 580 result is the TWAMP-Test HMAC Session-key to use in authenticating 581 the packets of the particular TWAMP-Test session. Note that all of 582 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 583 comprised of 32 octets, while the SID is 16 octets. 585 ECB mode used for encrypting the first block of TWAMP-Test packets 586 in authenticated mode does not involve any actual chaining; this 587 way, lost, duplicated, or reordered packets do not cause problems 588 with deciphering any packet in an TWAMP-Test session. 590 In encrypted mode, the first two blocks (32 octets) are encrypted 591 using AES CBC mode. The AES Session-key to use is obtained in the 592 same way as the key for authenticated mode. Each TWAMP-Test packet 593 is encrypted as a separate stream, with just one chaining 594 operation; chaining does not span multiple packets so that lost, 595 duplicated, or reordered packets do not cause problems. The 596 initialization vector for the CBC encryption is a value with all 597 bits equal to zero. 599 Implementation note: Naturally, the key schedule for each 600 TWAMP-Test session MAY be set up only once per session, not once 601 per packet. 603 HMAC in TWAMP-Test only covers the part of the packet that is also 604 encrypted. So, in authenticated mode, HMAC covers the first block 605 (16 octets); in encrypted mode, HMAC covers two first blocks (32 606 octets). In TWAMP-Test HMAC is not encrypted (note that this is 607 different from TWAMP-Control, where encryption in stream mode is 608 used, so everything including the HMAC blocks ends up being 609 encrypted). 611 In unauthenticated mode, no encryption or authentication is 612 applied. 614 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 615 generated independently of any other pseudo-random numbers 616 mentioned in this document). However, implementations MUST provide 617 a configuration parameter, an option, or a different means of 618 making Packet Padding consist of all zeros. 620 5. Implementers Guide 622 This section serves as guidance to implementers of TWAMP. Two 623 architectures are presented in this section for implementations 624 where two hosts play the subsystem roles of TWAMP. Although only 625 two architectures are presented here the protocol does not require 626 their use. Similar to OWAMP [RFC4656] TWAMP is designed with 627 complete flexibility to allow different architectures that suite 628 multiple system requirements. 630 5.1 Complete TWAMP 632 In this example the roles of Control-Client and Session-Sender are 633 implemented in one host referred to as the controller and the roles 634 of Server and Session-Reflector are implemented in another host 635 referred to as the responder. 637 controller responder 638 +-----------------+ +-------------------+ 639 | Control-Client |<--TWAMP-Control-->| Server | 640 | | | | 641 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 642 +-----------------+ +-------------------+ 644 This example provides an architecture that supports the full TWAMP 645 standard. The controller establishes the test session with the 646 responder through the TWAMP-Control protocol. After the session is 647 established the controller transmits test packets to the responder. 648 The responder follows the Session-Reflctor behavior of TWAMP as 649 described in section 4.2. 651 5.2 TWAMP Light 653 In this example the roles of Control-Client, Server, and 654 Session-Sender are implemented in one host referred to as the 655 controller and the role of Session-Reflector is implemented in 656 another host referred to as the responder. 658 controller responder 659 +-----------------+ +-------------------+ 660 | Server |<----------------->| | 661 | Control-Client | | Session-Reflector | 662 | Session-Sender |<--TWAMP-Test----->| | 663 +-----------------+ +-------------------+ 665 This example provides a simple architecture for responders where 666 their role will be to simply act as light test points in the 667 network. The controller establishes the test session with the 668 Server through non-standard means. After the session is 669 established the controller transmits test packets to the responder. 670 The responder follows the Session-Reflector behavior of TWAMP as 671 described in section 4.2 with the following exceptions. The 672 Session-Reflector SHOULD copy the sequence number of the received 673 packet to the Sequence Number field of the reflected packet. This 674 is necessary since in case of TWAMP Light the Session-Reflector 675 does not have knowledge of the session state. The controller 676 receives the reflected test packets and collects two-way metrics. 677 This architecture allows for collection of two-way metrics. 679 This example eliminates the need for the TWAMP-Control protocol and 680 assumes that the Session-Reflector is configured and communicates 681 its configuration with the Server through non-standard means. The 682 Session-Reflector simply reflects the incoming packets back to the 683 controller while copying the necessary information and generating 684 sequence number and timestamp values per section 5.2.1. 686 6. Security Considerations 688 Fundamentally TWAMP and OWAMP use the same protocol for 689 establishment of Control and Test procedures. The main difference 690 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 691 vs. the Session-Receiver behavior in OWAMP. This difference in 692 behavior does not introduce any known security vulnerabilities that 693 are not already addressed by the security features of OWAMP. The 694 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 696 7. Acknowledgements 698 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 699 and Stanislav Shalunov for their comments, suggestions, reviews, 700 helpful discussion and proof-reading. 702 8. IANA Considerations 704 IANA has allocated a well-known TCP port number (861) for the 705 OWAMP-Control part of the OWAMP [RFC4656] protocol which also 706 applies to the TWAMP-Control part of the TWAMP protocol. 708 9. Internationalization Considerations 710 The protocol does not carry any information in a natural language, 711 with the possible exception of the KeyID in TWAMP-Control, which is 712 encoded in UTF-8. 714 10. References 716 10.1 Normative References 718 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 719 Zekauskas, M., "A One-way Active Measurement Protocol 720 (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. 722 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 723 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 724 September 1999. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 730 Definition of the Differentiated Services Field (DS 731 Field) in the IPv4 and IPv6 Headers", RFC 2474, 732 December 1998. 734 Authors' Addresses 736 Kaynam Hedayat 737 Brix Networks 738 285 Mill Road 739 Chelmsford, MA 01824 740 USA 742 EMail: khedayat@brixnet.com 743 URI: http://www.brixnet.com/ 745 Roman M. Krzanowski, Ph.D. 746 Verizon 747 500 Westchester Ave. 748 White Plains, NY 749 USA 751 EMail: roman.krzanowski@verizon.com 752 URI: http://www.verizon.com/ 753 Al Morton 754 AT&T Labs 755 Room D3 - 3C06 756 200 Laurel Ave. South 757 Middletown, NJ 07748 758 USA 760 Phone +1 732 420 1571 761 EMail: acmorton@att.com 762 URI: http://home.comcast.net/~acmacm/ 764 Kiho Yum 765 Juniper Networks 766 1194 Mathilda Ave. 767 Sunnyvale, CA 768 USA 770 EMail: kyum@juniper.net 771 URI: http://www.juniper.com/ 773 Jozef Z. Babiarz 774 Nortel Networks 775 3500 Carling Avenue 776 Ottawa, Ont K2H 8E9 777 Canada 779 Email: babiarz@nortel.com 780 URI: http://www.nortel.com/ 782 Full Copyright Statement 784 Copyright (C) The IETF Trust (2007). 786 This document is subject to the rights, licenses and restrictions 787 contained in BCP 78, and except as set forth therein, the authors 788 retain all their rights. 790 This document and the information contained herein are provided on 791 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 792 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 793 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 794 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 795 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 796 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 797 FOR A PARTICULAR PURPOSE. 799 Intellectual Property 801 The IETF takes no position regarding the validity or scope of any 802 Intellectual Property Rights or other rights that might be claimed 803 to pertain to the implementation or use of the technology described 804 in this document or the extent to which any license under such 805 rights might or might not be available; nor does it represent that 806 it has made any independent effort to identify any such rights. 807 Information on the procedures with respect to rights in RFC 808 documents can be found in BCP 78 and BCP 79. 810 Copies of IPR disclosures made to the IETF Secretariat and any 811 assurances of licenses to be made available, or the result of an 812 attempt made to obtain a general license or permission for the use 813 of such proprietary rights by implementers or users of this 814 specification can be obtained from the IETF on-line IPR repository 815 at http://www.ietf.org/ipr. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights that may cover technology that may be required to implement 820 this standard. Please address the information to the IETF at 821 ietf-ipr@ietf.org. 823 Acknowledgement 825 Funding for the RFC Editor function is provided by the IETF 826 Administrative Support Activity (IASA).