idnits 2.17.1 draft-ietf-ippm-twamp-06.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 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 977. 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 (December 2007) is 5977 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: '0-15' is mentioned on line 826, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-ippm-owdp-11 -- Duplicate reference: RFC2474, mentioned in 'RFC2434', was also mentioned in 'RFC2474'. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: June 2008 R. Krzanowski 5 Verizon 6 K. Yum 7 Juniper Networks 8 A. Morton 9 AT&T Labs 10 J. Babiarz 11 Nortel Networks 12 December 2007 14 A Two-way Active Measurement Protocol (TWAMP) 15 draft-ietf-ippm-twamp-06 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 IP Performance Metrics (IPPM) working group's One-way Active 47 Measurement Protocol [RFC4656] (OWAMP) provides a common protocol 48 for measuring one-way metrics between network devices. OWAMP can 49 be used bi-directionally to measure one-way metrics in both 50 directions between two network elements. However, it does not 51 accommodate round-trip or two-way measurements. This memo 52 specifies a Two-way Active Measurement Protocol (TWAMP), based on 53 the OWAMP, that adds two-way or round-trip measurement 54 capabilities. The TWAMP measurement architecture is usually 55 comprised of two hosts with specific roles, and this allows for 56 some protocol simplifications, making it an attractive alternative 57 in some circumstances. 59 Table of Contents 61 1. Introduction..................................................3 62 1.1 Relationship of Test and Control Protocols................3 63 1.2 Logical Model.............................................3 64 2. Protocol Overview.............................................5 65 3. TWAMP Control.................................................5 66 3.1 Connection Setup..........................................6 67 3.2 Integrity Protection......................................6 68 3.3 Value of the Accept Fields................................6 69 3.4 TWAMP Control Commands....................................6 70 3.5 Creating Test Sessions....................................6 71 3.6 Send Schedules............................................9 72 3.7 Starting Test Sessions....................................9 73 3.8 Stop-Sessions.............................................9 74 3.9 Fetch-Session.............................................9 75 4. TWAMP Test....................................................9 76 4.1 Sender Behavior..........................................10 77 4.2 Reflector Behavior.......................................10 78 5. Implementers Guide...........................................16 79 5.1 Complete TWAMP...........................................17 80 5.2 TWAMP Light..............................................17 81 6. Security Considerations......................................18 82 7. Acknowledgements.............................................18 83 8. IANA Considerations..........................................19 84 8.1 Registry Specification...................................19 85 8.2 Registry Management......................................19 86 8.3 Experimental Numbers.....................................20 87 8.4 Initial Registry Contents................................20 88 9. Internationalization Considerations..........................20 89 10. References..................................................21 90 10.1 Normative References....................................21 91 10.2 Informative References..................................21 93 1. Introduction 95 The IETF IP Performance Metrics (IPPM) working group has completed 96 a draft standard for the round-trip delay [RFC2681] metric. IPPM 97 has also completed a protocol for the control and collection of 98 one-way measurements, the One-way Active Measurement Protocol 99 (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip 100 or two-way measurements. 102 Two-way measurements are common in IP networks, primarily because 103 time accuracy is less demanding for round-trip delay, and 104 measurement support at the remote end may be limited to a simple 105 echo function. This memo specifies the Two-way Active Measurement 106 Protocol, or TWAMP. TWAMP uses the methodology and architecture of 107 OWAMP [RFC4656] to define an open protocol for measurement of 108 two-way or round-trip metrics (henceforth in this document the term 109 two-way also signifies round-trip). The TWAMP measurement 110 architecture is usually comprised of only two hosts with specific 111 roles, and this allows for some protocol simplifications, making it 112 an attractive alternative to OWAMP in some circumstances. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 115 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 RFC 2119 [RFC2119]. 119 1.1 Relationship of Test and Control Protocols 121 Similar to OWAMP [RFC4656], TWAMP consists of two inter-related 122 protocols: TWAMP-Control and TWAMP-Test. The relationship of these 123 protocols is as defined in section 1.1 of OWAMP [RFC4656]. 124 TWAMP-Control is used to initiate, start, and stop test sessions, 125 whereas TWAMP-Test is used to exchange test packets between two 126 TWAMP entities. 128 1.2 Logical Model 129 The role and definition of the logical entities are as defined in 130 section 1.2 of OWAMP [RFC4656] with the following exceptions: 132 - The Session-Receiver is called the Session-Reflector in the 133 TWAMP architecture. The Session-Reflector has the capability 134 to create and send a measurement packet when it receives a 135 measurement packet. Unlike the Session-Receiver, the 136 Session-Reflector does not collect any packet information. 138 - The Server is an end system that manages one or more TWAMP 139 sessions, and is capable of configuring per-session state in 140 the end-points. However, a Server associated with a 141 Session-Reflector would not have the capability to return the 142 results of a test session, and this is a difference from OWAMP. 144 - The Fetch-Client entity does not exist in the TWAMP 145 architecture, as the Session-Reflector does not collect any 146 packet information to be fetched. Consequently there is no 147 need for the Fetch-Client. 149 An example of possible relationship scenarios between these roles 150 are presented below. In this example different logical roles are 151 played on different hosts. Unlabeled links in the figure are 152 unspecified by this document and may be proprietary protocols. 154 +----------------+ +-------------------+ 155 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 156 +----------------+ +-------------------+ 157 ^ ^ 158 | | 159 | | 160 | | 161 | +----------------+<----------------+ 162 | | Server | 163 | +----------------+ 164 | ^ 165 | | 166 | TWAMP-Control 167 | | 168 v v 169 +----------------+ 170 | Control-Client | 171 +----------------+ 173 As in OWAMP [RFC4656], different logical roles can be played by the 174 same host. For example, in the figure above, there could be 175 actually two hosts: one playing the roles of Control-Client and 176 Session-Sender, and the other playing the roles of Server and 177 Session-Reflector. This example is shown below. 179 +-----------------+ +-------------------+ 180 | Control-Client |<--TWAMP Control-->| Server | 181 | | | | 182 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 183 +-----------------+ +-------------------+ 185 Additionally, following the guidelines of OWAMP [RFC4656], TWAMP 186 has been defined to allow for small test packets that would fit 187 inside the payload of a single ATM cell (only in unauthenticated 188 mode). 190 2. Protocol Overview 192 The Two-way Active Measurement Protocol is an open protocol for 193 measurement of two-way metrics. It is based on OWAMP [RFC4656] and 194 adheres to its overall architecture and design. The protocol 195 defined in this document extends and changes OWAMP [RFC4656] as 196 follows: 198 - Define a new logical entity, Session-Reflector, in place of the 199 Session-Receiver. 201 - Define the Session-Reflector behavior in place of the 202 Session-Receiver behavior of OWAMP [RFC4656]. 204 - Define a new test packet format for packets transmitted from the 205 Session-Reflector to Session-Sender. 207 - Fetch client does not exist in the TWAMP architecture. 209 All multi-octet quantities defined in this document are represented 210 as unsigned integers in network byte order unless specified 211 otherwise. 213 3. TWAMP Control 215 TWAMP-Control is a derivative of the OWAMP-Control for two-way 216 measurements. All TWAMP Control messages are similar in format and 217 follow similar guidelines to those defined in section 3 of OWAMP 218 [RFC4656] with the exceptions outlined in the following sections. 220 All OWAMP [RFC4656] Control messages except for the Fetch-Session 221 command apply to TWAMP. 223 3.1 Connection Setup 225 Connection establishment of TWAMP follows the same procedure 226 defined in section 3.1 of OWAMP [RFC4656]. The mode values are 227 identical to OWAMP. The only exception is the well-known port 228 number for TWAMP-control. A client opens a TCP connection to the 229 server on well-known port N (Refer to the IANA Considerations 230 section below for the TWAMP-control port number assignment). The 231 host that initiates the TCP connection takes the roles of 232 Control-Client and (in the two-host implementation) the 233 Session-Sender. The host that acknowledges the TCP connection 234 accepts the roles of Server and (in the two-host implementation) 235 the Session Reflector. 237 3.2 Integrity Protection 239 Integrity protection of TWAMP follows the same procedure defined in 240 section 3.2 of OWAMP [RFC4656]. 242 3.3 Value of the Accept Fields 244 Accept values used in TWAMP are the same as the values defined in 245 section 3.3 of OWAMP [RFC4656]. 247 3.4 TWAMP Control Commands 249 TWAMP control commands are as defined in section 3.4 of OWAMP 250 [RFC4656] except that the Fetch-Session command does not apply to 251 TWAMP. 253 3.5 Creating Test Sessions 255 Test sessions creation follows the same procedure as defined in 256 section 3.5 of OWAMP [RFC4656]. 258 In order to distinguish the session as a two-way versus a one-way 259 measurement session the first octet of the Request-Session command 260 MUST be set to 5. Value of 5 indicates that this is a 261 Request-Session for a two-way metrics measurement session. 263 In TWAMP, the first octet is referred to as the Command Number, and 264 the Command Number is a recognized extension mechanism. Readers are 265 encouraged to consult the TWAMP Command Number Registry to 266 determine if there have been additional values assigned. 268 If a TWAMP server receives an unexpected command number, it SHOULD 269 respond with the Accept field set to 3 (meaning "Some aspect of 270 request is not supported") in the Server-Start message. 272 In OWAMP, the Conf-Sender field is set to 1 when the 273 Request-Session message describes a task where the Server will 274 configure a one-way test packet sender. Likewise, the 275 Conf-Receiver field is set to 1 when the message describes the 276 configuration for a Session-Receiver. In TWAMP, both endpoints 277 perform in these roles, with the Session-Sender first sending and 278 then receiving test packets. The Session-Reflector first receives 279 the test packets, and returns each test packet to the 280 Session-Sender as fast as possible. 282 Both Conf-Sender field and Conf-Receiver field MUST be set to 0 283 since the Session-Reflector will both receive and send packets, and 284 the roles are established according to which host initiates the TCP 285 connection for control. The server MUST interpret any non-zero 286 value as zero. 288 The Session-Reflector in TWAMP does not process incoming test 289 packets for performance metrics and consequently does not need to 290 know the number of incoming packets and their timing schedule. 291 Consequently the Number of Scheduled Slots and Number of Packets 292 MUST be set to 0. 294 The Sender Port is the UDP port from which TWAMP-Test packets will 295 be sent and the port to which TWAMP-Test packets will be sent by 296 the Session-Reflector (Session-Sender will use the same UDP port to 297 send and receive packets). Receiver Port is the desired UDP port 298 to which TWAMP test packets will be sent by the Session-Sender (the 299 port where the Session-Reflector is asked to receive test packets). 300 Receiver Port is also the UDP port from which TWAMP test packets 301 will be sent by the Session-Reflector (Session-Reflector will use 302 the same UDP port to send and receive packets). 304 The Sender Address and Receiver Address fields contain, 305 respectively, the sender and receiver addresses of the endpoints of 306 the Internet path over which a TWAMP test session is requested. 308 They MAY be set to 0, in which case the IP addresses used for the 309 Session-Sender to Session-Reflector Control Message exchange MUST 310 be used in the test packets. 312 The Session Identifier (SID) is as defined in OWAMP [RFC4656]. 313 Since the SID is always generated by the receiving side, the 314 Session-Reflector determines the SID, and the SID in the 315 Request-Session message MUST be set to 0. 317 The Start Time is as as defined in OWAMP [RFC4656]. 319 The Timeout is interpreted differently from the definition in OWAMP 320 [RFC4656]. In TWAMP, Timeout is the interval that the 321 Session-Reflector MUST wait after receiving a Stop-Sessions 322 message. In case there are test packets still in transit, the 323 Session Reflector MUST reflect them if they arrive within the 324 timeout interval following the reception of the Stop-Sessions 325 message. The Session-Reflector MUST NOT reflect packets that are 326 received beyond the timeout. 328 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 329 capability of this field is to set the Differentiated Services Code 330 Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST 331 be used in test packets reflected by the Session-Reflector. 333 Since there are no Schedule Slot Descriptions, the Request-Session 334 Message is completed by MBZ (Must Be Zero) and HMAC (Hash Message 335 Authentication Code) fields. This completes one logical message, 336 referred to as the Request-Session Command. 338 The Session-Reflector MUST respond to each Request-Session Command 339 with an Accept-Message as defined in OWAMP [RFC4656]. When the 340 Accept Field = 0, the Port field confirms (repeats) the port to 341 which TWAMP test packets are sent by the Session-Sender toward the 342 Session-Reflector. In other words, the Port field indicates the 343 port number where the Session-Reflector expects to receive packets 344 from the Session-Sender. 346 When the requested Receiver Port is not available (e.g., port in 347 use), the Server at the Session-Reflector MAY suggest an alternate 348 and available port for this session in the Port Field. The 349 Session-Sender either accepts the alternate port, or composes a new 350 Session-Request message with suitable parameters. Otherwise, the 351 Server at the Session-Reflector uses the Accept Field to convey 352 other forms of session rejection or failure and MUST NOT suggest an 353 alternate port. In this case the Port Field MUST be set to zero. 355 3.6 Send Schedules 357 The Send Schedule for test packets defined in section 3.6 of OWAMP 358 [RFC4656] is not used in TWAMP. The Control-Client and 359 Session-Sender MAY autonomously decide the Send Schedule. The 360 Session-Reflector SHOULD return each test packet to the 361 Session-Sender as quickly as possible. 363 3.7 Starting Test Sessions 365 The procedure and guidelines for Starting test sessions is the same 366 as defined in section 3.7 of OWAMP [RFC4656]. 368 3.8 Stop-Sessions 370 The procedure and guidelines for Stopping test sessions is the same 371 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session 372 command can only be issued by the Session-Sender. The Next SeqNo 373 and Number of Skip Ranges MUST be set to 0 and the message MUST NOT 374 contain any session description records or skip ranges. The 375 message is terminated with a single block HMAC, to complete the 376 Stop-Sessions Command. 378 3.9 Fetch-Session 380 The purpose of TWAMP is measurement of two-way metrics. Two-way 381 measurements do not rely on packet level data collected by the 382 Session-Reflector such as sequence number, timestamp, and TTL. As 383 such the protocol does not require the retrieval of packet level 384 data from the Server and the Fetch-Session command is not defined 385 in TWAMP. 387 4. TWAMP Test 389 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 390 protocol with the exception that the Session-Reflector transmits 391 test packets to the Session-Sender in response to each test packet 392 it receives. TWAMP defines two different test packet formats, one 393 for packets transmitted by the Session-Sender and one for packets 394 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 395 protocol there are three modes: unauthenticated, authenticated, and 396 encrypted. 398 4.1 Sender Behavior 400 The sender behavior is determined by the configuration of the 401 Session-Sender and is not defined in this standard. Further, the 402 Session-Reflector does not need to know the Session-Sender 403 behaviour to the degree of detail as needed in OWAMP [RFC4656]. 404 Additionally the Session-Sender collects and records the necessary 405 information provided from the packets transmitted by the 406 Session-Reflector for measuring two-way metrics. The information 407 recording based on the received packet by the Session-Sender is 408 implementation dependent. 410 4.1.1 Packet Timings 412 Since the Send Schedule is not communicated to the 413 Session-Reflector, there is no need for a standardized computation 414 of packet timing. 416 Regardless of any scheduling delays, each packet that is actually 417 sent MUST have the best possible approximation of its real time of 418 departure as its timestamp (in the packet). 420 4.1.2 Packet Format and Content 422 The Session-Sender packet format and content follow the same 423 procedure and guidelines as defined in section 4.1.2 of OWAMP 424 [RFC4656] (with the exception of the reference to the Send 425 Schedule). 427 4.2 Reflector Behavior 429 TWAMP requires the Session-Reflector to transmit a packet to the 430 Session-Sender in response to each packet it receives. 432 As packets are received the Session-Reflector will, 433 - Timestamp the received packet. Each packet that is actually 434 received MUST have the best possible approximation of its real 435 time of arrival entered as its timestamp (in the packet). 437 - In authenticated or encrypted mode, decrypt the first block (16 438 octets) of the packet body. 440 - Copy the packet sequence number into the corresponding reflected 441 packet to the Session-Sender. 443 - Sender TTL value is extracted from the TTL/Hop Limit value of 444 received packets. Session-Reflector Implementations SHOULD 445 fetch the TTL/Hop Limit value from the IP header of the packet, 446 replacing the value of 255 set by the Session-Sender. If an 447 implementation does not fetch the actual TTL value (the only 448 good reason not to do so is an inability to access the TTL 449 field of arriving packets), it MUST set the Sender TTL value as 450 255. 452 - Transmit a test packet to the Session-Sender in response to 453 every received packet. The response MUST be generated as 454 immediately as possible. The format and content of the test 455 packet is defined in section 5.2.1. Prior to the transmission 456 of the test packet, the Session-Reflector MUST enter the best 457 possible approximation of its actual sending time of as its 458 Timestamp (in the packet). This permits the determination of 459 the elapsed time between the reception of the packet and its 460 transmission. 462 - Packets not received within the Timeout are ignored by the 463 Reflector. The Session-Reflector MUST NOT generate a test 464 packet to the Session-Sender for packets that are ignored. 466 4.2.1 TWAMP-Test Packet Format and Content 468 The Session-Reflector MUST transmit a packet to the Session-Sender 469 in response to each packet received. The Session-Reflector SHOULD 470 transmit the packets as immediately as possible. The 471 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 472 in the UDP packet to 255. 474 The test packet will have the necessary information for calculating 475 two-way metrics by the Session-Sender. The format of the test 476 packet depends on the mode being used. The various formats of the 477 packet are presented below. 479 For unauthenticated mode: 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 | Timestamp | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Error Estimate | MBZ | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Receive Timestamp | 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Sender Sequence Number | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Sender Timestamp | 497 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Sender Error Estimate | MBZ | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Sender TTL | | 502 +++++++++++++++++ | 503 | | 504 . . 505 . Packet Padding . 506 . . 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 For authenticated and encrypted modes: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Sequence Number | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | MBZ (12 octets) | 517 | | 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Timestamp | 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Error Estimate | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 525 | MBZ (6 octets) | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Receive Timestamp | 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | MBZ (8 octets) | 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 533 | Sender Sequence Number | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | MBZ (12 octets) | 536 | | 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Sender Timestamp | 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sender Error Estimate | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 544 | MBZ (6 octets) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Sender TTL | | 547 +++++++++++++++++ | 548 | | 549 | | 550 | MBZ (15 octets) | 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 552 | HMAC (16 octets) | 553 | | 554 | | 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 557 | | 558 . . 559 . Packet Padding . 560 . . 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Sequence Number is the sequence number of the test packet according 565 to its transmit order.It starts with zero and is incremented by one 566 for each subsequent packet. The Sequence Number generated by the 567 Session-Reflector is independent from the sequence number of the 568 arriving packets. 570 Timestamp and Error Estimate are the Session-Reflector's transmit 571 timestamp and error estimate for the reflected test packet, 572 respectively. The format of all timestamp and error estimate 573 fields follow the definition and formats defined by OWAMP[RFC4656]. 575 Sender Timestamp and Sender Error Estimate are exact copies of the 576 timestamp and error estimate from the Session-Sender test packet 577 that corresponds to this test packet. 579 Sender TTL is 255 when transmitted by the Session Sender. Sender 580 TTL is set to the Time To Live (or Hop Count) value of the received 581 packet from the IP packet header when transmitted by the Session 582 Reflector. 584 Receive Timestamp is the time the test packet was received by the 585 reflector. The difference between Timestamp and Receive Timestamp 586 is the amount of time the packet was in transition in the 587 Session-Reflector. The Error Estimate associated with the 588 Timestamp field also applies to the Receive Timestamp. 590 Sender Sequence Number is a copy of the Sequence Number of the 591 packet transmitted by the Session-Sender that caused the 592 Session-Reflector to generate and send this test packet. 594 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 595 authenticated and encrypted modes. The encryption operation of 596 Session-Sender packet follow the same rules of Session-Sender 597 packets as defined in OWAMP [RFC4656]. 599 The minimum data segment length is, therefore, 41 octets in 600 unauthenticated mode, and 104 octets in both authenticated mode and 601 encrypted modes (with the implication that the later two modes will 602 not fit in a single ATM cell). 604 The Session-Reflector TWAMP-Test packet layout is the same in 605 authenticated and encrypted modes. The encryption operations are, 606 however, different. The difference is that in encrypted mode both 607 the sequence numbers and timestamps are encrypted to provide 608 maximum data integrity protection while in authenticated mode the 609 sequence numbers are encrypted and the timestamps are sent in clear 610 text. Sending the timestamp in clear text in authenticated mode 611 allows one to reduce the time between when a timestamp is obtained 612 by a reflector and when the packet is reflected out. In encrypted 613 mode, both the sender and reflector have to fetch the timestamp, 614 encrypt it, and send it; in authenticated mode, the middle step is 615 removed, potentially improving accuracy (the sequence number can be 616 encrypted before the timestamp is fetched). 618 In authenticated mode, the first block (16 octets) of each packet 619 is encrypted using AES Electronic Cookbook (ECB) mode. 621 Obtaining the key, encryption method, and packet padding follows 622 the same procedure as OWAMP as described below. 623 Similarly to each TWAMP-Control session, each TWAMP-Test session 624 has two keys: an AES Session-key and an HMAC Session-key. However, 625 there is a difference in how the keys are obtained: in the case of 626 TWAMP-Control, the keys are generated by the client and 627 communicated (as part of the Token) during connection setup as part 628 of Set-Up-Response message; in the case of TWAMP-Test, described 629 here, the keys are derived from the TWAMP-Control keys and the SID. 631 The TWAMP-Test AES Session-key is obtained as follows: the 632 TWAMP-Control AES Session-key (the same AES Session-key as is used 633 for the corresponding TWAMP-Control session, where it is used in a 634 different chaining mode) is encrypted, using AES, with the 16-octet 635 session identifier (SID) as the key; this is a single-block ECB 636 encryption; its result is the TWAMP-Test AES Session-key to use in 637 encrypting (and decrypting) the packets of the particular 638 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 639 TWAMP-Control AES Session-key, and the SID are comprised of 16 640 octets. 642 The TWAMP-Test HMAC Session-key is obtained as follows: the 643 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 644 used for the corresponding TWAMP-Control session) is encrypted, 645 using AES, with the 16-octet session identifier (SID) as the key; 646 this is a two-block CBC encryption, always performed with IV=0; its 647 result is the TWAMP-Test HMAC Session-key to use in authenticating 648 the packets of the particular TWAMP-Test session. Note that all of 649 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 650 comprised of 32 octets, while the SID is 16 octets. 652 ECB mode used for encrypting the first block of TWAMP-Test packets 653 in authenticated mode does not involve any actual chaining; this 654 way, lost, duplicated, or reordered packets do not cause problems 655 with deciphering any packet in an TWAMP-Test session. 657 In encrypted mode, the first six blocks (96octets) are encrypted 658 using AES CBC mode. The AES Session-key to use is obtained in the 659 same way as the key for authenticated mode. Each TWAMP-Test packet 660 is encrypted as a separate stream, with just one chaining 661 operation; chaining does not span multiple packets so that lost, 662 duplicated, or reordered packets do not cause problems. The 663 initialization vector for the CBC encryption is a value with all 664 bits equal to zero. 666 Implementation note: Naturally, the key schedule for each 667 TWAMP-Test session MAY be set up only once per session, not once 668 per packet. 670 HMAC in TWAMP-Test only covers the part of the packet that is also 671 encrypted. So, in authenticated mode, HMAC covers the first block 672 (16 octets); in encrypted mode, HMAC covers two first blocks (32 673 octets). In TWAMP-Test HMAC is not encrypted (note that this is 674 different from TWAMP-Control, where encryption in stream mode is 675 used, so everything including the HMAC blocks ends up being 676 encrypted). 678 In unauthenticated mode, no encryption or authentication is 679 applied. 681 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 682 generated independently of any other pseudo-random numbers 683 mentioned in this document). However, implementations MUST provide 684 a configuration parameter, an option, or a different means of 685 making Packet Padding consist of all zeros. 687 5. Implementers Guide 689 This section serves as guidance to implementers of TWAMP. Two 690 architectures are presented in this section for implementations 691 where two hosts play the subsystem roles of TWAMP. Although only 692 two architectures are presented here the protocol does not require 693 their use. Similar to OWAMP [RFC4656] TWAMP is designed with 694 complete flexibility to allow different architectures that suite 695 multiple system requirements. 697 5.1 Complete TWAMP 699 In this example the roles of Control-Client and Session-Sender are 700 implemented in one host referred to as the controller and the roles 701 of Server and Session-Reflector are implemented in another host 702 referred to as the responder. 704 controller responder 705 +-----------------+ +-------------------+ 706 | Control-Client |<--TWAMP-Control-->| Server | 707 | | | | 708 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 709 +-----------------+ +-------------------+ 711 This example provides an architecture that supports the full TWAMP 712 standard. The controller establishes the test session with the 713 responder through the TWAMP-Control protocol. After the session is 714 established the controller transmits test packets to the responder. 715 The responder follows the Session-Reflctor behavior of TWAMP as 716 described in section 4.2. 718 5.2 TWAMP Light 720 In this example the roles of Control-Client, Server, and 721 Session-Sender are implemented in one host referred to as the 722 controller and the role of Session-Reflector is implemented in 723 another host referred to as the responder. 725 controller responder 726 +-----------------+ +-------------------+ 727 | Server |<----------------->| | 728 | Control-Client | | Session-Reflector | 729 | Session-Sender |<--TWAMP-Test----->| | 730 +-----------------+ +-------------------+ 732 This example provides a simple architecture for responders where 733 their role will be to simply act as light test points in the 734 network. The controller establishes the test session with the 735 Server through non-standard means. After the session is 736 established the controller transmits test packets to the responder. 737 The responder follows the Session-Reflector behavior of TWAMP as 738 described in section 4.2 with the following exceptions. 740 In the case of TWAMP Light, the Session-Reflector does not 741 necessarily have knowledge of the session state. IF the 742 Session-Reflector does not have knowledge of the session state, 743 THEN the Session-Reflector MUST copy the Sequence Number of the 744 received packet to the Sequence Number field of the reflected 745 packet. The controller receives the reflected test packets and 746 collects two-way metrics. This architecture allows for collection 747 of two-way metrics. 749 This example eliminates the need for the TWAMP-Control protocol and 750 assumes that the Session-Reflector is configured and communicates 751 its configuration with the Server through non-standard means. The 752 Session-Reflector simply reflects the incoming packets back to the 753 controller while copying the necessary information and generating 754 sequence number and timestamp values per section 4.2.1. 756 6. Security Considerations 758 Fundamentally TWAMP and OWAMP use the same protocol for 759 establishment of Control and Test procedures. The main difference 760 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 761 vs. the Session-Receiver behavior in OWAMP. This difference in 762 behavior does not introduce any known security vulnerabilities that 763 are not already addressed by the security features of OWAMP. The 764 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 766 The only area where TWAMP may introduce new security considerations 767 is the TWAMP Light version described above. The non-standard means 768 to control the responder and establish test sessions SHOULD offer 769 the features listed below. 771 The non-standard responder control protocol SHOULD have an 772 authenticated mode of operation. The responder SHOULD be 773 configurable to accept only authenticated control sessions. 775 The non-standard responder control protocol SHOULD have a means to 776 activate the authenticated and encrypted modes of the TWAMP-Test 777 protocol. 779 7. Acknowledgements 781 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 782 Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote 783 for their comments, suggestions, reviews, helpful discussion and 784 proof-reading. 786 8. IANA Considerations 788 IANA has allocated a well-known TCP port number (861) for the 789 OWAMP-Control part of the OWAMP [RFC4656] protocol. 790 ... 791 owamp-control 861/tcp OWAMP-Control 792 owamp-control 861/udp OWAMP-Control 793 # [RFC4656] 794 # 862-872 Unassigned 796 IANA is requested to allocate a well-known TCP/UDP port number for 797 the TWAMP-Control protocol. It would be ideal if the port number 798 assignment was adjacent to the OWAMP assignment. The recommended 799 Keyword for this entry is "twamp-control" and the Description is 800 "Two-way Active Measurement Protocol (TWAMP) Control". 802 During final editing, port N in section 3.1 should be replaced with 803 the assigned port number. 805 Since TWAMP adds an additional Control command to the OWAMP-Control 806 specification, and describes behavior when this control command is 807 used, this memo requests creation an IANA registry for the TWAMP 808 Command Number field. The field is not explicitly named in 809 [RFC4656] but is called out for each command. This field is a 810 recognized extension mechanism for TWAMP. 812 8.1 Registry Specification 814 IANA will create an TWAMP-Control Command registry. TWAMP-Control 815 commands are specified by the first octet in OWAMP-Control messages 816 as shown in section 3.4 of [RFC4656], and modified by this 817 document. Thus this registry may contain sixteen possible values. 819 8.2 Registry Management 821 Because the registry may only contain sixteen values, and because 822 OWAMP and TWAMP are IETF protocols, this registry must only be 823 updated by "IETF Consensus" as specified in [RFC2434] -- an RFC 824 documenting the use that is approved by the IESG. We expect that 825 new values will be assigned as monotonically increasing integers in 826 the range [0-15], unless there is a good reason to do otherwise. 828 8.3 Experimental Numbers 830 [RFC3692] recommends allocating an appropriate number of values for 831 experimentation and testing. It is not clear to the authors 832 exactly how many might be useful in this space, nor if it would be 833 useful that they were easily distinguishable or at the "high end" 834 of the number range. Two might be useful, say one for session 835 control, and one for session fetch. On the other hand, a single 836 number would allow for unlimited extension, because the format of 837 the rest of the message could be tailored, with allocation of other 838 numbers done once usefulness has been proven. Thus, this document 839 will allocate one number, the next sequential number 6, as 840 designated for experimentation and testing. 842 8.4 Initial Registry Contents 844 TWAMP-Control Command Registry 846 Value Description Semantics Definition 847 0 Reserved 848 1 Forbidden 849 2 Start-Sessions RFC4656, Section 3.7 850 3 Stop-Sessions RFC4656, Section 3.8 851 4 Fetch-Session RFC4656, Section 3.9 852 5 Request-TW-Session this document, Section 3.5 853 6 Experimentation undefined, see Section 8.3. 855 9. Internationalization Considerations 857 The protocol does not carry any information in a natural language, 858 with the possible exception of the KeyID in TWAMP-Control, which is 859 encoded in UTF-8. 861 10. References 863 10.1 Normative References 865 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 866 Zekauskas, M., "A One-way Active Measurement Protocol 867 (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. 869 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 870 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 871 September 1999. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, March 1997. 876 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 877 Definition of the Differentiated Services Field (DS 878 Field) in the IPv4 and IPv6 Headers", RFC 2474, 879 December 1998. 881 [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing 882 an IANA Considerations Section in RFCs, RFC 2474, 883 October 1998. 885 10.2 Informative References 887 [RFC3692] Narten, T., Assigning Experimental and Testing Numbers 888 Considered Useful, RFC 3692, January 2004. 890 Authors' Addresses 892 Kaynam Hedayat 893 Brix Networks 894 285 Mill Road 895 Chelmsford, MA 01824 896 USA 898 EMail: khedayat@brixnet.com 899 URI: http://www.brixnet.com/ 900 Roman M. Krzanowski, Ph.D. 901 Verizon 902 500 Westchester Ave. 903 White Plains, NY 904 USA 906 EMail: roman.krzanowski@verizon.com 907 URI: http://www.verizon.com/ 909 Al Morton 910 AT&T Labs 911 Room D3 - 3C06 912 200 Laurel Ave. South 913 Middletown, NJ 07748 914 USA 916 Phone +1 732 420 1571 917 EMail: acmorton@att.com 918 URI: http://home.comcast.net/~acmacm/ 920 Kiho Yum 921 Juniper Networks 922 1194 Mathilda Ave. 923 Sunnyvale, CA 924 USA 926 EMail: kyum@juniper.net 927 URI: http://www.juniper.com/ 929 Jozef Z. Babiarz 930 Nortel Networks 931 3500 Carling Avenue 932 Ottawa, Ont K2H 8E9 933 Canada 935 Email: babiarz@nortel.com 936 URI: http://www.nortel.com/ 938 Full Copyright Statement 940 Copyright (C) The IETF Trust (2007). 942 This document is subject to the rights, licenses and restrictions 943 contained in BCP 78, and except as set forth therein, the authors 944 retain all their rights. 946 This document and the information contained herein are provided on 947 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 948 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 949 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 950 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 951 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 952 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 953 FOR A PARTICULAR PURPOSE. 955 Intellectual Property 957 The IETF takes no position regarding the validity or scope of any 958 Intellectual Property Rights or other rights that might be claimed 959 to pertain to the implementation or use of the technology described 960 in this document or the extent to which any license under such 961 rights might or might not be available; nor does it represent that 962 it has made any independent effort to identify any such rights. 963 Information on the procedures with respect to rights in RFC 964 documents can be found in BCP 78 and BCP 79. 966 Copies of IPR disclosures made to the IETF Secretariat and any 967 assurances of licenses to be made available, or the result of an 968 attempt made to obtain a general license or permission for the use 969 of such proprietary rights by implementers or users of this 970 specification can be obtained from the IETF on-line IPR repository 971 at http://www.ietf.org/ipr. 973 The IETF invites any interested party to bring to its attention any 974 copyrights, patents or patent applications, or other proprietary 975 rights that may cover technology that may be required to implement 976 this standard. Please address the information to the IETF at 977 ietf-ipr@ietf.org. 979 Acknowledgement 981 Funding for the RFC Editor function is provided by the IETF 982 Administrative Support Activity (IASA).