idnits 2.17.00 (12 Aug 2021) /tmp/idnits27348/draft-ietf-ippm-twamp-04.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 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 870. 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 (May 2007) is 5484 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: draft-ietf-ippm-owdp has been published as RFC 4656 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: November 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 May 2007 14 A Two-way Active Measurement Protocol (TWAMP) 15 draft-ietf-ippm-twamp-04 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....................................................9 75 4.1 Sender Behavior...........................................9 76 4.2 Reflector Behavior.......................................10 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..........................18 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 and the port to which TWAMP-Test packets will be sent by 268 the Session-Reflector (Session-Sender will use the same UDP port to 269 send and receive packets). Receiver Port is the desired UDP port 270 to which TWAMP test packets will be sent by the Session-Sender (the 271 port where the Session-Reflector is asked to receive test packets). 272 Receiver Port is also the UDP port from which TWAMP test packets 273 will be sent by the Session-Reflector (Session-Reflector will use 274 the same UDP port to send and receive packets). 276 The Sender Address and Receiver Address fields contain, 277 respectively, the sender and receiver addresses of the endpoints of 278 the Internet path over which a TWAMP test session is requested. 279 They MAY be set to 0, in which case the IP addresses used for the 280 Session-Sender to Session-Reflector Control Message exchange MUST 281 be used in the test packets. 283 The SID is as defined in OWAMP [RFC4656]. Since the SID is always 284 generated by the receiving side, the Session-Reflector determines 285 the SID, and the SID in the Request-Session message MUST be set to 286 0. 288 The Start Time is as as defined in OWAMP [RFC4656]. 290 The Timeout is interpreted differently from the definition in OWAMP 291 [RFC4656]. In TWAMP, Timeout is the interval that the 292 Session-Reflector MUST wait after receiving a Stop-Sessions 293 message. In case there are test packets still in transit, the 294 Session Reflector MUST reflect them if they arrive within the 295 timeout interval following the reception of the Stop-Sessions 296 message. The Session-Reflector MUST NOT reflect packets that are 297 received beyond the timeout. 299 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 300 capability of this field is to set the Differentiated Services Code 301 Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST 302 be used in test packets reflected by the Session-Reflector. 304 Since there are no Schedule Slot Descriptions, the Request-Session 305 Message is completed by MBZ and HMAC fields. This completes one 306 logical message, referred to as the Request-Session Command. 308 The Session-Reflector MUST respond to each Request-Session Command 309 with an Accept-Message as defined in OWAMP [RFC4656]. When the 310 Accept Field = 0, the Port field confirms (repeats) the port to 311 which TWAMP test packets are sent by the Session-Sender toward the 312 Session-Reflector. In other words, the Port field indicates the 313 port number where the Session-Reflector expects to receive packets 314 from the Session-Sender. 316 When the requested Receiver Port is not available (e.g., port in 317 use), the Server at the Session-Reflector MAY suggest an alternate 318 and available port for this session in the Port Field. The 319 Session-Sender either accepts the alternate port, or composes a new 320 Session-Request message with suitable parameters. Otherwise, the 321 Server at the Session-Reflector uses the Accept Field to convey 322 other forms of session rejection or failure and MUST NOT suggest an 323 alternate port. In this case the Port Field MUST be set to zero. 325 3.6 Send Schedules 327 The Send Schedule for test packets defined in section 3.6 of OWAMP 328 [RFC4656] is not used in TWAMP. The Control-Client and 329 Session-Sender MAY autonomously decide the Send Schedule. The 330 Session-Reflector SHOULD return each test packet to the 331 Session-Sender as quickly as possible. 333 3.7 Starting Test Sessions 335 The procedure and guidelines for Starting test sessions is the same 336 as defined in section 3.7 of OWAMP [RFC4656]. 338 3.8 Stop-Sessions 340 The procedure and guidelines for Stopping test sessions is the same 341 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session 342 command can only be issued by the Session-Sender. The Next SeqNo 343 and Number of Skip Ranges MUST be set to 0 and the message MUST NOT 344 contain any session description records or skip ranges. The 345 message is terminated with a single block HMAC, to complete the 346 Stop-Sessions Command. 348 3.9 Fetch-Session 349 The purpose of TWAMP is measurement of two-way metrics. Two-way 350 measurements do not rely on packet level data collected by the 351 Session-Reflector such as sequence number, timestamp, and TTL. As 352 such the protocol does not require the retrieval of packet level 353 data from the Server and the Fetch-Session command is not defined 354 in TWAMP. 356 4. TWAMP Test 358 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 359 protocol with the exception that the Session-Reflector transmits 360 test packets to the Session-Sender in response to each test packet 361 it receives. TWAMP defines two different test packet formats, one 362 for packets transmitted by the Session-Sender and one for packets 363 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 364 protocol there are three modes: unauthenticated, authenticated, and 365 encrypted. 367 4.1 Sender Behavior 369 The sender behavior is determined by the configuration of the 370 Session-Sender and is not defined in this standard. Further, the 371 Session-Reflector does not need to know the Session-Sender 372 behaviour to the degree of detail as needed in OWAMP [RFC4656]. 373 Additionally the Session-Sender collects and records the necessary 374 information provided from the packets transmitted by the 375 Session-Reflector for measuring two-way metrics. The information 376 recording based on the received packet by the Session-Sender is 377 implementation dependent. 379 4.1.1 Packet Timings 381 Since the Send Schedule is not communicated to the 382 Session-Reflector, there is no need for a standardized computation 383 of packet timing. 385 Regardless of any scheduling delays, each packet that is actually 386 sent MUST have the best possible approximation of its real time of 387 departure as its timestamp (in the packet). 389 4.1.2 Packet Format and Content 391 The Session-Sender packet format and content follow the same 392 procedure and guidelines as defined in section 4.1.2 of OWAMP 393 [RFC4656] (with the exception of the reference to the Send 394 Schedule). 396 4.2 Reflector Behavior 398 TWAMP requires the Session-Reflector to transmit a packet to the 399 Session-Sender in response to each packet it receives. 401 As packets are received the Session-Reflector will, 403 - Timestamp the received packet. Each packet that is actually 404 received MUST have the best possible approximation of its real 405 time of arrival entered as its timestamp (in the packet). 407 - In authenticated or encrypted mode, decrypt the first block (16 408 octets) of the packet body. 410 - Copy the packet sequence number into the corresponding reflected 411 packet to the Session-Sender. 413 - Sender TTL value is extracted from the TTL/Hop Limit value of 414 received packets. Session-Reflector Implementations SHOULD 415 fetch the TTL/Hop Limit value from the IP header of the packet, 416 replacing the value of 255 set by the Session-Sender. If an 417 implementation does not fetch the actual TTL value (the only 418 good reason not to do so is an inability to access the TTL 419 field of arriving packets), it MUST set the Sender TTL value as 420 255. 422 - Transmit a test packet to the Session-Sender in response to 423 every received packet. The response MUST be generated as 424 immediately as possible. The format and content of the test 425 packet is defined in section 5.2.1. Prior to the transmission 426 of the test packet, the Session-Reflector MUST enter the best 427 possible approximation of its actual sending time of as its 428 Timestamp (in the packet). This permits the determination of 429 the elapsed time between the reception of the packet and its 430 transmission. 432 - Packets not received within the Timeout are ignored by the 433 Reflector. The Session-Reflector MUST NOT generate a test 434 packet to the Session-Sender for packets that are ignored. 436 4.2.1 TWAMP-Test Packet Format and Content 438 The Session-Reflector MUST transmit a packet to the Session-Sender 439 in response to each packet received. The Session-Reflector SHOULD 440 transmit the packets as immediately as possible. The 441 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 442 in the UDP packet to 255. 444 The test packet will have the necessary information for calculating 445 two-way metrics by the Session-Sender. The format of the test 446 packet depends on the mode being used. The various formats of the 447 packet are presented below. 449 For unauthenticated mode: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Sequence Number | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Timestamp | 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Error Estimate | MBZ | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Receive Timestamp | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Sender Sequence Number | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Sender Timestamp | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Sender Error Estimate | MBZ | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Sender TTL | | 472 +++++++++++++++++ | 473 | | 474 . . 475 . Packet Padding . 476 . . 477 | | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 For authenticated and encrypted modes: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Sequence Number | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | MBZ (12 octets) | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Timestamp | 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Error Estimate | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 494 | MBZ (6 octets) | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Receive Timestamp | 498 | | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | MBZ (8 octets) | 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 503 | Sender Sequence Number | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | MBZ (12 octets) | 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sender Timestamp | 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Sender Error Estimate | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 513 | MBZ (6 octets) | 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Sender TTL | | 517 +++++++++++++++++ | 518 | MBZ (7 octets) | 519 | | 520 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 521 | HMAC (16 octets) | 522 | | 523 | | 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 526 | | 527 . . 528 . Packet Padding . 529 . . 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Sequence Number is the sequence number of the test packet according 534 to its arrival at the Session-Reflector. It starts with zero and 535 is incremented by one for each subsequent packet. The Sequence 536 Number generated by the Session-Reflector is independent from the 537 sequence number of the arriving packets. 539 Timestamp and Error Estimate are the Session-Reflector's transmit 540 timestamp and error estimate for the reflected test packet, 541 respectively. The format of all timestamp and error estimate 542 fields follow the definition and formats defined by OWAMP[RFC4656]. 544 Sender Timestamp and Sender Error Estimate are exact copies of the 545 timestamp and error estimate from the Session-Sender test packet 546 that corresponds to this test packet. 548 Sender TTL is 255 when transmitted by the Session Sender. Sender 549 TTL is set to the Time To Live (or Hop Count) value of the received 550 packet from the IP packet header when transmitted by the Session 551 Reflector. 553 Receive Timestamp is the time the test packet was received by the 554 reflector. The difference between Timestamp and Receive Timestamp 555 is the amount of time the packet was in transition in the 556 Session-Reflector. The Error Estimate associated with the 557 Timestamp field also applies to the Receive Timestamp. 559 Sender Sequence Number is a copy of the Sequence Number of the 560 packet transmitted by the Session-Sender that caused the 561 Session-Reflector to generate and send this test packet. 563 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 564 authenticated and encrypted modes. The encryption operation of 565 Session-Sender packet follow the same rules of Session-Sender 566 packets as defined in OWAMP [RFC4656]. 568 The minimum data segment length is, therefore, 40 octets in 569 unauthenticated mode, and 80 octets in both authenticated mode and 570 encrypted modes (with the implication that the later two modes will 571 not fit in a single ATM cell). 573 The Session-Reflector TWAMP-Test packet layout is the same in 574 authenticated and encrypted modes. The encryption operations are, 575 however, different. The difference is that in encrypted mode both 576 the sequence numbers and timestamps are encrypted to provide 577 maximum data integrity protection while in authenticated mode the 578 sequence numbers are encrypted and the timestamps are sent in clear 579 text. Sending the timestamp in clear text in authenticated mode 580 allows one to reduce the time between when a timestamp is obtained 581 by a reflector and when the packet is reflected out. In encrypted 582 mode, both the sender and reflector have to fetch the timestamp, 583 encrypt it, and send it; in authenticated mode, the middle step is 584 removed, potentially improving accuracy (the sequence number can be 585 encrypted before the timestamp is fetched). 587 In authenticated mode, the first block (16 octets) of each packet 588 is encrypted using AES Electronic Cookbook (ECB) mode. 590 Obtaining the key, encryption method, and packet padding follows 591 the same procedure as OWAMP as described below. 592 Similarly to each TWAMP-Control session, each TWAMP-Test session 593 has two keys: an AES Session-key and an HMAC Session-key. However, 594 there is a difference in how the keys are obtained: in the case of 595 TWAMP-Control, the keys are generated by the client and 596 communicated (as part of the Token) during connection setup as part 597 of Set-Up-Response message; in the case of TWAMP-Test, described 598 here, the keys are derived from the TWAMP-Control keys and the SID. 600 The TWAMP-Test AES Session-key is obtained as follows: the 601 TWAMP-Control AES Session-key (the same AES Session-key as is used 602 for the corresponding TWAMP-Control session, where it is used in a 603 different chaining mode) is encrypted, using AES, with the 16-octet 604 session identifier (SID) as the key; this is a single-block ECB 605 encryption; its result is the TWAMP-Test AES Session-key to use in 606 encrypting (and decrypting) the packets of the particular 607 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 608 TWAMP-Control AES Session-key, and the SID are comprised of 16 609 octets. 611 The TWAMP-Test HMAC Session-key is obtained as follows: the 612 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 613 used for the corresponding TWAMP-Control session) is encrypted, 614 using AES, with the 16-octet session identifier (SID) as the key; 615 this is a two-block CBC encryption, always performed with IV=0; its 616 result is the TWAMP-Test HMAC Session-key to use in authenticating 617 the packets of the particular TWAMP-Test session. Note that all of 618 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 619 comprised of 32 octets, while the SID is 16 octets. 621 ECB mode used for encrypting the first block of TWAMP-Test packets 622 in authenticated mode does not involve any actual chaining; this 623 way, lost, duplicated, or reordered packets do not cause problems 624 with deciphering any packet in an TWAMP-Test session. 626 In encrypted mode, the first two blocks (32 octets) are encrypted 627 using AES CBC mode. The AES Session-key to use is obtained in the 628 same way as the key for authenticated mode. Each TWAMP-Test packet 629 is encrypted as a separate stream, with just one chaining 630 operation; chaining does not span multiple packets so that lost, 631 duplicated, or reordered packets do not cause problems. The 632 initialization vector for the CBC encryption is a value with all 633 bits equal to zero. 635 Implementation note: Naturally, the key schedule for each 636 TWAMP-Test session MAY be set up only once per session, not once 637 per packet. 639 HMAC in TWAMP-Test only covers the part of the packet that is also 640 encrypted. So, in authenticated mode, HMAC covers the first block 641 (16 octets); in encrypted mode, HMAC covers two first blocks (32 642 octets). In TWAMP-Test HMAC is not encrypted (note that this is 643 different from TWAMP-Control, where encryption in stream mode is 644 used, so everything including the HMAC blocks ends up being 645 encrypted). 647 In unauthenticated mode, no encryption or authentication is 648 applied. 650 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 651 generated independently of any other pseudo-random numbers 652 mentioned in this document). However, implementations MUST provide 653 a configuration parameter, an option, or a different means of 654 making Packet Padding consist of all zeros. 656 5. Implementers Guide 658 This section serves as guidance to implementers of TWAMP. Two 659 architectures are presented in this section for implementations 660 where two hosts play the subsystem roles of TWAMP. Although only 661 two architectures are presented here the protocol does not require 662 their use. Similar to OWAMP [RFC4656] TWAMP is designed with 663 complete flexibility to allow different architectures that suite 664 multiple system requirements. 666 5.1 Complete TWAMP 667 In this example the roles of Control-Client and Session-Sender are 668 implemented in one host referred to as the controller and the roles 669 of Server and Session-Reflector are implemented in another host 670 referred to as the responder. 672 controller responder 673 +-----------------+ +-------------------+ 674 | Control-Client |<--TWAMP-Control-->| Server | 675 | | | | 676 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 677 +-----------------+ +-------------------+ 679 This example provides an architecture that supports the full TWAMP 680 standard. The controller establishes the test session with the 681 responder through the TWAMP-Control protocol. After the session is 682 established the controller transmits test packets to the responder. 683 The responder follows the Session-Reflctor behavior of TWAMP as 684 described in section 4.2. 686 5.2 TWAMP Light 688 In this example the roles of Control-Client, Server, and 689 Session-Sender are implemented in one host referred to as the 690 controller and the role of Session-Reflector is implemented in 691 another host referred to as the responder. 693 controller responder 694 +-----------------+ +-------------------+ 695 | Server |<----------------->| | 696 | Control-Client | | Session-Reflector | 697 | Session-Sender |<--TWAMP-Test----->| | 698 +-----------------+ +-------------------+ 700 This example provides a simple architecture for responders where 701 their role will be to simply act as light test points in the 702 network. The controller establishes the test session with the 703 Server through non-standard means. After the session is 704 established the controller transmits test packets to the responder. 705 The responder follows the Session-Reflector behavior of TWAMP as 706 described in section 4.2 with the following exceptions. The 707 Session-Reflector SHOULD copy the sequence number of the received 708 packet to the Sequence Number field of the reflected packet. This 709 is necessary since in case of TWAMP Light the Session-Reflector 710 does not necessarily have knowledge of the session state. The 711 controller receives the reflected test packets and collects two-way 712 metrics. This architecture allows for collection of two-way 713 metrics. 715 This example eliminates the need for the TWAMP-Control protocol and 716 assumes that the Session-Reflector is configured and communicates 717 its configuration with the Server through non-standard means. The 718 Session-Reflector simply reflects the incoming packets back to the 719 controller while copying the necessary information and generating 720 sequence number and timestamp values per section 5.2.1. 722 6. Security Considerations 724 Fundamentally TWAMP and OWAMP use the same protocol for 725 establishment of Control and Test procedures. The main difference 726 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 727 vs. the Session-Receiver behavior in OWAMP. This difference in 728 behavior does not introduce any known security vulnerabilities that 729 are not already addressed by the security features of OWAMP. The 730 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 732 The only area where TWAMP may introduce new security considerations 733 is the TWAMP Light version described above. The non-standard means 734 to control the responder and establish test sessions SHOULD offer 735 the features listed below. 737 The non-standard responder control protocol SHOULD have an 738 authenticated mode of operation. The responder SHOULD be 739 configurable to accept only authenticated control sessions. 741 The non-standard responder control protocol SHOULD have a means to 742 activate the authenticated and encrypted modes of the TWAMP-Test 743 protocol. 745 7. Acknowledgements 747 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 748 and Stanislav Shalunov for their comments, suggestions, reviews, 749 helpful discussion and proof-reading. 751 8. IANA Considerations 752 IANA has allocated a well-known TCP port number (861) for the 753 OWAMP-Control part of the OWAMP [RFC4656] protocol which also 754 applies to the TWAMP-Control part of the TWAMP protocol. 756 9. Internationalization Considerations 758 The protocol does not carry any information in a natural language, 759 with the possible exception of the KeyID in TWAMP-Control, which is 760 encoded in UTF-8. 762 10. References 764 10.1 Normative References 766 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 767 Zekauskas, M., "A One-way Active Measurement Protocol 768 (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. 770 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 771 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 772 September 1999. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 778 Definition of the Differentiated Services Field (DS 779 Field) in the IPv4 and IPv6 Headers", RFC 2474, 780 December 1998. 782 Authors' Addresses 784 Kaynam Hedayat 785 Brix Networks 786 285 Mill Road 787 Chelmsford, MA 01824 788 USA 790 EMail: khedayat@brixnet.com 791 URI: http://www.brixnet.com/ 793 Roman M. Krzanowski, Ph.D. 794 Verizon 795 500 Westchester Ave. 796 White Plains, NY 797 USA 799 EMail: roman.krzanowski@verizon.com 800 URI: http://www.verizon.com/ 802 Al Morton 803 AT&T Labs 804 Room D3 - 3C06 805 200 Laurel Ave. South 806 Middletown, NJ 07748 807 USA 809 Phone +1 732 420 1571 810 EMail: acmorton@att.com 811 URI: http://home.comcast.net/~acmacm/ 813 Kiho Yum 814 Juniper Networks 815 1194 Mathilda Ave. 816 Sunnyvale, CA 817 USA 819 EMail: kyum@juniper.net 820 URI: http://www.juniper.com/ 822 Jozef Z. Babiarz 823 Nortel Networks 824 3500 Carling Avenue 825 Ottawa, Ont K2H 8E9 826 Canada 828 Email: babiarz@nortel.com 829 URI: http://www.nortel.com/ 831 Full Copyright Statement 833 Copyright (C) The IETF Trust (2007). 835 This document is subject to the rights, licenses and restrictions 836 contained in BCP 78, and except as set forth therein, the authors 837 retain all their rights. 839 This document and the information contained herein are provided on 840 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 841 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 842 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 843 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 844 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 845 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 846 FOR A PARTICULAR PURPOSE. 848 Intellectual Property 850 The IETF takes no position regarding the validity or scope of any 851 Intellectual Property Rights or other rights that might be claimed 852 to pertain to the implementation or use of the technology described 853 in this document or the extent to which any license under such 854 rights might or might not be available; nor does it represent that 855 it has made any independent effort to identify any such rights. 856 Information on the procedures with respect to rights in RFC 857 documents can be found in BCP 78 and BCP 79. 859 Copies of IPR disclosures made to the IETF Secretariat and any 860 assurances of licenses to be made available, or the result of an 861 attempt made to obtain a general license or permission for the use 862 of such proprietary rights by implementers or users of this 863 specification can be obtained from the IETF on-line IPR repository 864 at http://www.ietf.org/ipr. 866 The IETF invites any interested party to bring to its attention any 867 copyrights, patents or patent applications, or other proprietary 868 rights that may cover technology that may be required to implement 869 this standard. Please address the information to the IETF at 870 ietf-ipr@ietf.org. 872 Acknowledgement 874 Funding for the RFC Editor function is provided by the IETF 875 Administrative Support Activity (IASA).