idnits 2.17.1 draft-ietf-ippm-twamp-05.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 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. 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 (November 2007) is 5979 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 814, 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: May 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 November 2007 14 A Two-way Active Measurement Protocol (TWAMP) 15 draft-ietf-ippm-twamp-05 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.............................................9 73 3.9 Fetch-Session.............................................9 74 4. TWAMP Test....................................................9 75 4.1 Sender Behavior...........................................9 76 4.2 Reflector Behavior.......................................10 77 5. Implementers Guide...........................................16 78 5.1 Complete TWAMP...........................................17 79 5.2 TWAMP Light..............................................17 80 6. Security Considerations......................................18 81 7. Acknowledgements.............................................18 82 8. IANA Considerations..........................................19 83 9. Internationalization Considerations..........................20 84 10. References..................................................21 85 10.1 Normative References....................................21 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 All multi-octet quantities defined in this document are represented 202 as unsigned integers in network byte order unless specified 203 otherwise. 205 3. TWAMP Control 207 TWAMP-Control is a derivative of the OWAMP-Control for two-way 208 measurements. All TWAMP Control messages are similar in format and 209 follow similar guidelines to those defined in section 3 of OWAMP 210 [RFC4656] with the exceptions outlined in the following sections. 211 All OWAMP [RFC4656] Control messages except for the Fetch-Session 212 command apply to TWAMP. 214 3.1 Connection Setup 216 Connection establishment of TWAMP follows the same procedure 217 defined in section 3.1 of OWAMP [RFC4656]. The mode values are 218 identical to OWAMP. The only exception is the well-known port 219 number for TWAMP-control. A client opens a TCP connection to the 220 server on well-known port N (Refer to the IANA Considerations 221 section below for the TWAMP-control port number assignment). The 222 host that initiates the TCP connection takes the roles of Control- 223 Client and (in the two-host implementation) the Session-Sender. 224 The host that acknowledges the TCP connection accepts the roles of 225 Server and (in the two-host implementation) the Session Reflector. 227 3.2 Integrity Protection 229 Integrity protection of TWAMP follows the same procedure defined in 230 section 3.2 of OWAMP [RFC4656]. 232 3.3 Value of the Accept Fields 234 Accept values used in TWAMP are the same as the values defined in 235 section 3.3 of OWAMP [RFC4656]. 237 3.4 TWAMP Control Commands 239 TWAMP control commands are as defined in section 3.4 of OWAMP 240 [RFC4656] except that the Fetch-Session command does not apply to 241 TWAMP. 243 3.5 Creating Test Sessions 245 Test sessions creation follows the same procedure as defined in 246 section 3.5 of OWAMP [RFC4656]. 248 In order to distinguish the session as a two-way versus a one-way 249 measurement session the first octet of the Request-Session command 250 MUST be set to 5. Value of 5 indicates that this is a 251 Request-Session for a two-way metrics measurement session. 253 In TWAMP, the first octet is referred to as the Command Number, and 254 the Command Number is a recognized extension mechanism. Readers are 255 encouraged to consult the TWAMP Command Number Registry to 256 determine if there have been additional values assigned. 258 If a TWAMP server receives an unexpected command number, it MUST 259 respond with the Accept field set to 3 (meaning "Some aspect of 260 request is not supported") in the Server-Start message. 262 In OWAMP, the Conf-Sender field is set to 1 when the 263 Request-Session message describes a task where the Server will 264 configure a one-way test packet sender. Likewise, the 265 Conf-Receiver field is set to 1 when the message describes the 266 configuration for a Session-Receiver. In TWAMP, both endpoints 267 perform in these roles, with the Session-Sender first sending and 268 then receiving test packets. The Session-Reflector first receives 269 the test packets, and returns each test packet to the 270 Session-Sender as fast as possible. 272 Both Conf-Sender and Conf-Receiver MUST be set to 0 since the 273 Session-Reflector will both receive and send packets, and the roles 274 are established according to which host initiates the TCP 275 connection for control. The server MUST interpret any non-zero 276 value as zero. 278 The Session-Reflector in TWAMP does not process incoming test 279 packets for performance metrics and consequently does not need to 280 know the number of incoming packets and their timing schedule. 281 Consequently the Number of Scheduled Slots and Number of Packets 282 MUST be set to 0. 284 The Sender Port is the UDP port from which TWAMP-Test packets will 285 be sent and the port to which TWAMP-Test packets will be sent by 286 the Session-Reflector (Session-Sender will use the same UDP port to 287 send and receive packets). Receiver Port is the desired UDP port 288 to which TWAMP test packets will be sent by the Session-Sender (the 289 port where the Session-Reflector is asked to receive test packets). 290 Receiver Port is also the UDP port from which TWAMP test packets 291 will be sent by the Session-Reflector (Session-Reflector will use 292 the same UDP port to send and receive packets). 294 The Sender Address and Receiver Address fields contain, 295 respectively, the sender and receiver addresses of the endpoints of 296 the Internet path over which a TWAMP test session is requested. 297 They MAY be set to 0, in which case the IP addresses used for the 298 Session-Sender to Session-Reflector Control Message exchange MUST 299 be used in the test packets. 301 The SID is as defined in OWAMP [RFC4656]. Since the SID is always 302 generated by the receiving side, the Session-Reflector determines 303 the SID, and the SID in the Request-Session message MUST be set to 304 0. 306 The Start Time is as as defined in OWAMP [RFC4656]. 308 The Timeout is interpreted differently from the definition in OWAMP 309 [RFC4656]. In TWAMP, Timeout is the interval that the 310 Session-Reflector MUST wait after receiving a Stop-Sessions 311 message. In case there are test packets still in transit, the 312 Session Reflector MUST reflect them if they arrive within the 313 timeout interval following the reception of the Stop-Sessions 314 message. The Session-Reflector MUST NOT reflect packets that are 315 received beyond the timeout. 317 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 318 capability of this field is to set the Differentiated Services Code 319 Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST 320 be used in test packets reflected by the Session-Reflector. 322 Since there are no Schedule Slot Descriptions, the Request-Session 323 Message is completed by MBZ and HMAC fields. This completes one 324 logical message, referred to as the Request-Session Command. 326 The Session-Reflector MUST respond to each Request-Session Command 327 with an Accept-Message as defined in OWAMP [RFC4656]. When the 328 Accept Field = 0, the Port field confirms (repeats) the port to 329 which TWAMP test packets are sent by the Session-Sender toward the 330 Session-Reflector. In other words, the Port field indicates the 331 port number where the Session-Reflector expects to receive packets 332 from the Session-Sender. 334 When the requested Receiver Port is not available (e.g., port in 335 use), the Server at the Session-Reflector MAY suggest an alternate 336 and available port for this session in the Port Field. The 337 Session-Sender either accepts the alternate port, or composes a new 338 Session-Request message with suitable parameters. Otherwise, the 339 Server at the Session-Reflector uses the Accept Field to convey 340 other forms of session rejection or failure and MUST NOT suggest an 341 alternate port. In this case the Port Field MUST be set to zero. 343 3.6 Send Schedules 345 The Send Schedule for test packets defined in section 3.6 of OWAMP 346 [RFC4656] is not used in TWAMP. The Control-Client and 347 Session-Sender MAY autonomously decide the Send Schedule. The 348 Session-Reflector SHOULD return each test packet to the 349 Session-Sender as quickly as possible. 351 3.7 Starting Test Sessions 352 The procedure and guidelines for Starting test sessions is the same 353 as defined in section 3.7 of OWAMP [RFC4656]. 355 3.8 Stop-Sessions 357 The procedure and guidelines for Stopping test sessions is the same 358 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session 359 command can only be issued by the Session-Sender. The Next SeqNo 360 and Number of Skip Ranges MUST be set to 0 and the message MUST NOT 361 contain any session description records or skip ranges. The 362 message is terminated with a single block HMAC, to complete the 363 Stop-Sessions Command. 365 3.9 Fetch-Session 367 The purpose of TWAMP is measurement of two-way metrics. Two-way 368 measurements do not rely on packet level data collected by the 369 Session-Reflector such as sequence number, timestamp, and TTL. As 370 such the protocol does not require the retrieval of packet level 371 data from the Server and the Fetch-Session command is not defined 372 in TWAMP. 374 4. TWAMP Test 376 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 377 protocol with the exception that the Session-Reflector transmits 378 test packets to the Session-Sender in response to each test packet 379 it receives. TWAMP defines two different test packet formats, one 380 for packets transmitted by the Session-Sender and one for packets 381 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 382 protocol there are three modes: unauthenticated, authenticated, and 383 encrypted. 385 4.1 Sender Behavior 387 The sender behavior is determined by the configuration of the 388 Session-Sender and is not defined in this standard. Further, the 389 Session-Reflector does not need to know the Session-Sender 390 behaviour to the degree of detail as needed in OWAMP [RFC4656]. 391 Additionally the Session-Sender collects and records the necessary 392 information provided from the packets transmitted by the 393 Session-Reflector for measuring two-way metrics. The information 394 recording based on the received packet by the Session-Sender is 395 implementation dependent. 397 4.1.1 Packet Timings 399 Since the Send Schedule is not communicated to the 400 Session-Reflector, there is no need for a standardized computation 401 of packet timing. 403 Regardless of any scheduling delays, each packet that is actually 404 sent MUST have the best possible approximation of its real time of 405 departure as its timestamp (in the packet). 407 4.1.2 Packet Format and Content 409 The Session-Sender packet format and content follow the same 410 procedure and guidelines as defined in section 4.1.2 of OWAMP 411 [RFC4656] (with the exception of the reference to the Send 412 Schedule). 414 4.2 Reflector Behavior 416 TWAMP requires the Session-Reflector to transmit a packet to the 417 Session-Sender in response to each packet it receives. 419 As packets are received the Session-Reflector will, 421 - Timestamp the received packet. Each packet that is actually 422 received MUST have the best possible approximation of its real 423 time of arrival entered as its timestamp (in the packet). 425 - In authenticated or encrypted mode, decrypt the first block (16 426 octets) of the packet body. 428 - Copy the packet sequence number into the corresponding reflected 429 packet to the Session-Sender. 431 - Sender TTL value is extracted from the TTL/Hop Limit value of 432 received packets. Session-Reflector Implementations SHOULD 433 fetch the TTL/Hop Limit value from the IP header of the packet, 434 replacing the value of 255 set by the Session-Sender. If an 435 implementation does not fetch the actual TTL value (the only 436 good reason not to do so is an inability to access the TTL 437 field of arriving packets), it MUST set the Sender TTL value as 438 255. 440 - Transmit a test packet to the Session-Sender in response to 441 every received packet. The response MUST be generated as 442 immediately as possible. The format and content of the test 443 packet is defined in section 5.2.1. Prior to the transmission 444 of the test packet, the Session-Reflector MUST enter the best 445 possible approximation of its actual sending time of as its 446 Timestamp (in the packet). This permits the determination of 447 the elapsed time between the reception of the packet and its 448 transmission. 450 - Packets not received within the Timeout are ignored by the 451 Reflector. The Session-Reflector MUST NOT generate a test 452 packet to the Session-Sender for packets that are ignored. 454 4.2.1 TWAMP-Test Packet Format and Content 456 The Session-Reflector MUST transmit a packet to the Session-Sender 457 in response to each packet received. The Session-Reflector SHOULD 458 transmit the packets as immediately as possible. The 459 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 460 in the UDP packet to 255. 462 The test packet will have the necessary information for calculating 463 two-way metrics by the Session-Sender. The format of the test 464 packet depends on the mode being used. The various formats of the 465 packet are presented below. 467 For unauthenticated mode: 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Sequence Number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Timestamp | 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Error Estimate | MBZ | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Receive Timestamp | 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Sender Sequence Number | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Sender Timestamp | 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Sender Error Estimate | MBZ | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Sender TTL | | 490 +++++++++++++++++ | 491 | | 492 . . 493 . Packet Padding . 494 . . 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 For authenticated and encrypted modes: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Sequence Number | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | MBZ (12 octets) | 505 | | 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Timestamp | 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Error Estimate | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 513 | MBZ (6 octets) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Receive Timestamp | 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | MBZ (8 octets) | 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 521 | Sender Sequence Number | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | MBZ (12 octets) | 524 | | 525 | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Sender Timestamp | 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Sender Error Estimate | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 532 | MBZ (6 octets) | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Sender TTL | | 535 +++++++++++++++++ | 536 | | 537 | | 538 | MBZ (15 octets) | 539 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 540 | HMAC (16 octets) | 541 | | 542 | | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 545 | | 546 . . 547 . Packet Padding . 548 . . 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Sequence Number is the sequence number of the test packet according 553 to its transmit order.It starts with zero and is incremented by one 554 for each subsequent packet. The Sequence Number generated by the 555 Session-Reflector is independent from the sequence number of the 556 arriving packets. 558 Timestamp and Error Estimate are the Session-Reflector's transmit 559 timestamp and error estimate for the reflected test packet, 560 respectively. The format of all timestamp and error estimate 561 fields follow the definition and formats defined by OWAMP[RFC4656]. 563 Sender Timestamp and Sender Error Estimate are exact copies of the 564 timestamp and error estimate from the Session-Sender test packet 565 that corresponds to this test packet. 567 Sender TTL is 255 when transmitted by the Session Sender. Sender 568 TTL is set to the Time To Live (or Hop Count) value of the received 569 packet from the IP packet header when transmitted by the Session 570 Reflector. 572 Receive Timestamp is the time the test packet was received by the 573 reflector. The difference between Timestamp and Receive Timestamp 574 is the amount of time the packet was in transition in the 575 Session-Reflector. The Error Estimate associated with the 576 Timestamp field also applies to the Receive Timestamp. 578 Sender Sequence Number is a copy of the Sequence Number of the 579 packet transmitted by the Session-Sender that caused the 580 Session-Reflector to generate and send this test packet. 582 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 583 authenticated and encrypted modes. The encryption operation of 584 Session-Sender packet follow the same rules of Session-Sender 585 packets as defined in OWAMP [RFC4656]. 587 The minimum data segment length is, therefore, 41 octets in 588 unauthenticated mode, and 104 octets in both authenticated mode and 589 encrypted modes (with the implication that the later two modes will 590 not fit in a single ATM cell). 592 The Session-Reflector TWAMP-Test packet layout is the same in 593 authenticated and encrypted modes. The encryption operations are, 594 however, different. The difference is that in encrypted mode both 595 the sequence numbers and timestamps are encrypted to provide 596 maximum data integrity protection while in authenticated mode the 597 sequence numbers are encrypted and the timestamps are sent in clear 598 text. Sending the timestamp in clear text in authenticated mode 599 allows one to reduce the time between when a timestamp is obtained 600 by a reflector and when the packet is reflected out. In encrypted 601 mode, both the sender and reflector have to fetch the timestamp, 602 encrypt it, and send it; in authenticated mode, the middle step is 603 removed, potentially improving accuracy (the sequence number can be 604 encrypted before the timestamp is fetched). 606 In authenticated mode, the first block (16 octets) of each packet 607 is encrypted using AES Electronic Cookbook (ECB) mode. 609 Obtaining the key, encryption method, and packet padding follows 610 the same procedure as OWAMP as described below. 611 Similarly to each TWAMP-Control session, each TWAMP-Test session 612 has two keys: an AES Session-key and an HMAC Session-key. However, 613 there is a difference in how the keys are obtained: in the case of 614 TWAMP-Control, the keys are generated by the client and 615 communicated (as part of the Token) during connection setup as part 616 of Set-Up-Response message; in the case of TWAMP-Test, described 617 here, the keys are derived from the TWAMP-Control keys and the SID. 619 The TWAMP-Test AES Session-key is obtained as follows: the 620 TWAMP-Control AES Session-key (the same AES Session-key as is used 621 for the corresponding TWAMP-Control session, where it is used in a 622 different chaining mode) is encrypted, using AES, with the 16-octet 623 session identifier (SID) as the key; this is a single-block ECB 624 encryption; its result is the TWAMP-Test AES Session-key to use in 625 encrypting (and decrypting) the packets of the particular 626 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 627 TWAMP-Control AES Session-key, and the SID are comprised of 16 628 octets. 630 The TWAMP-Test HMAC Session-key is obtained as follows: the 631 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 632 used for the corresponding TWAMP-Control session) is encrypted, 633 using AES, with the 16-octet session identifier (SID) as the key; 634 this is a two-block CBC encryption, always performed with IV=0; its 635 result is the TWAMP-Test HMAC Session-key to use in authenticating 636 the packets of the particular TWAMP-Test session. Note that all of 637 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 638 comprised of 32 octets, while the SID is 16 octets. 640 ECB mode used for encrypting the first block of TWAMP-Test packets 641 in authenticated mode does not involve any actual chaining; this 642 way, lost, duplicated, or reordered packets do not cause problems 643 with deciphering any packet in an TWAMP-Test session. 645 In encrypted mode, the first six blocks (96octets) are encrypted 646 using AES CBC mode. The AES Session-key to use is obtained in the 647 same way as the key for authenticated mode. Each TWAMP-Test packet 648 is encrypted as a separate stream, with just one chaining 649 operation; chaining does not span multiple packets so that lost, 650 duplicated, or reordered packets do not cause problems. The 651 initialization vector for the CBC encryption is a value with all 652 bits equal to zero. 654 Implementation note: Naturally, the key schedule for each 655 TWAMP-Test session MAY be set up only once per session, not once 656 per packet. 658 HMAC in TWAMP-Test only covers the part of the packet that is also 659 encrypted. So, in authenticated mode, HMAC covers the first block 660 (16 octets); in encrypted mode, HMAC covers two first blocks (32 661 octets). In TWAMP-Test HMAC is not encrypted (note that this is 662 different from TWAMP-Control, where encryption in stream mode is 663 used, so everything including the HMAC blocks ends up being 664 encrypted). 666 In unauthenticated mode, no encryption or authentication is 667 applied. 669 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 670 generated independently of any other pseudo-random numbers 671 mentioned in this document). However, implementations MUST provide 672 a configuration parameter, an option, or a different means of 673 making Packet Padding consist of all zeros. 675 5. Implementers Guide 677 This section serves as guidance to implementers of TWAMP. Two 678 architectures are presented in this section for implementations 679 where two hosts play the subsystem roles of TWAMP. Although only 680 two architectures are presented here the protocol does not require 681 their use. Similar to OWAMP [RFC4656] TWAMP is designed with 682 complete flexibility to allow different architectures that suite 683 multiple system requirements. 685 5.1 Complete TWAMP 687 In this example the roles of Control-Client and Session-Sender are 688 implemented in one host referred to as the controller and the roles 689 of Server and Session-Reflector are implemented in another host 690 referred to as the responder. 692 controller responder 693 +-----------------+ +-------------------+ 694 | Control-Client |<--TWAMP-Control-->| Server | 695 | | | | 696 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 697 +-----------------+ +-------------------+ 699 This example provides an architecture that supports the full TWAMP 700 standard. The controller establishes the test session with the 701 responder through the TWAMP-Control protocol. After the session is 702 established the controller transmits test packets to the responder. 703 The responder follows the Session-Reflctor behavior of TWAMP as 704 described in section 4.2. 706 5.2 TWAMP Light 708 In this example the roles of Control-Client, Server, and 709 Session-Sender are implemented in one host referred to as the 710 controller and the role of Session-Reflector is implemented in 711 another host referred to as the responder. 713 controller responder 714 +-----------------+ +-------------------+ 715 | Server |<----------------->| | 716 | Control-Client | | Session-Reflector | 717 | Session-Sender |<--TWAMP-Test----->| | 718 +-----------------+ +-------------------+ 720 This example provides a simple architecture for responders where 721 their role will be to simply act as light test points in the 722 network. The controller establishes the test session with the 723 Server through non-standard means. After the session is 724 established the controller transmits test packets to the responder. 725 The responder follows the Session-Reflector behavior of TWAMP as 726 described in section 4.2 with the following exceptions. 728 In the case of TWAMP Light, the Session-Reflector does not 729 necessarily have knowledge of the session state. IF the 730 Session-Reflector does not have knowledge of the session state, 731 THEN the Session-Reflector MUST copy the Sequence Number of the 732 received packet to the Sequence Number field of the reflected 733 packet. The controller receives the reflected test packets and 734 collects two-way metrics. This architecture allows for collection 735 of two-way metrics. 737 This example eliminates the need for the TWAMP-Control protocol and 738 assumes that the Session-Reflector is configured and communicates 739 its configuration with the Server through non-standard means. The 740 Session-Reflector simply reflects the incoming packets back to the 741 controller while copying the necessary information and generating 742 sequence number and timestamp values per section 4.2.1. 744 6. Security Considerations 746 Fundamentally TWAMP and OWAMP use the same protocol for 747 establishment of Control and Test procedures. The main difference 748 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 749 vs. the Session-Receiver behavior in OWAMP. This difference in 750 behavior does not introduce any known security vulnerabilities that 751 are not already addressed by the security features of OWAMP. The 752 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 754 The only area where TWAMP may introduce new security considerations 755 is the TWAMP Light version described above. The non-standard means 756 to control the responder and establish test sessions SHOULD offer 757 the features listed below. 759 The non-standard responder control protocol SHOULD have an 760 authenticated mode of operation. The responder SHOULD be 761 configurable to accept only authenticated control sessions. 763 The non-standard responder control protocol SHOULD have a means to 764 activate the authenticated and encrypted modes of the TWAMP-Test 765 protocol. 767 7. Acknowledgements 769 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 770 Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote 771 for their comments, suggestions, reviews, helpful discussion and 772 proof-reading. 774 8. IANA Considerations 776 IANA has allocated a well-known TCP port number (861) for the 777 OWAMP-Control part of the OWAMP [RFC4656] protocol. 778 ... 779 owamp-control 861/tcp OWAMP-Control 780 owamp-control 861/udp OWAMP-Control 781 # [RFC4656] 782 # 862-872 Unassigned 784 IANA is requested to allocate a well-known TCP/UDP port number for 785 the TWAMP-Control protocol. It would be ideal if the port number 786 assignment was adjacent to the OWAMP assignment. The recommended 787 Keyword for this entry is "twamp-control" and the Description is 788 "Two-way Active Measurement Protocol (TWAMP) Control". 790 During final editing, port N in section 3.1 should be replaced with 791 the assigned port number. 793 Since TWAMP adds an additional Control command to the OWAMP-Control 794 specification, and describes behavior when this control command is 795 used, this memo requests creation an IANA registry for the TWAMP 796 Command Number field. The field is not explicitly named in 797 [RFC4656] but is called out for each command. This field is a 798 recognized extension mechanism for TWAMP. 800 8.1 Registry Specification 802 IANA will create an TWAMP-Control Command registry. TWAMP-Control 803 commands are specified by the first octet in OWAMP-Control messages 804 as shown in section 3.4 of [RFC4656], and modified by this 805 document. Thus this registry may contain sixteen possible values. 807 8.2 Registry Management 809 Because the registry may only contain sixteen values, and because 810 OWAMP and TWAMP are IETF protocols, this registry must only be 811 updated by "IETF Consensus" as specified in [RFC2434] -- an RFC 812 documenting the use that is approved by the IESG. We expect that 813 new values will be assigned as monotonically increasing integers in 814 the range [0-15], unless there is a good reason to do otherwise. 816 8.3 Experimental Numbers 818 [RFC3692] recommends allocating an appropriate number of values for 819 experimentation and testing. It is not clear to the authors 820 exactly how many might be useful in this space, nor if it would be 821 useful that they were easily distinguishable or at the "high end" 822 of the number range. Two might be useful, say one for session 823 control, and one for session fetch. On the other hand, a single 824 number would allow for unlimited extension, because the format of 825 the rest of the message could be tailored, with allocation of other 826 numbers done once usefulness has been proven. Thus, this document 827 will allocate one number, the next sequential number 6, as 828 designated for experimentation and testing. 830 8.4 Initial Registry Contents 832 TWAMP-Control Command Registry 834 Value Description Semantics Definition 835 0 Reserved 836 1 Forbidden 837 2 Start-Sessions RFC4656, Section 3.7 838 3 Stop-Sessions RFC4656, Section 3.8 839 4 Fetch-Session RFC4656, Section 3.9 840 5 Request-TW-Session this document, Section 3.5 841 6 Experimentation undefined, see Section 8.3. 843 9. Internationalization Considerations 845 The protocol does not carry any information in a natural language, 846 with the possible exception of the KeyID in TWAMP-Control, which is 847 encoded in UTF-8. 849 10. References 851 10.1 Normative References 853 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 854 Zekauskas, M., "A One-way Active Measurement Protocol 855 (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. 857 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 858 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 859 September 1999. 861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 862 Requirement Levels", BCP 14, RFC 2119, March 1997. 864 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 865 Definition of the Differentiated Services Field (DS 866 Field) in the IPv4 and IPv6 Headers", RFC 2474, 867 December 1998. 869 [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing 870 an IANA Considerations Section in RFCs, RFC 2474, 871 October 1998. 873 10.2 Informative References 875 [RFC3692] Narten, T., Assigning Experimental and Testing Numbers 876 Considered Useful, RFC 3692, January 2004. 878 Authors' Addresses 880 Kaynam Hedayat 881 Brix Networks 882 285 Mill Road 883 Chelmsford, MA 01824 884 USA 886 EMail: khedayat@brixnet.com 887 URI: http://www.brixnet.com/ 888 Roman M. Krzanowski, Ph.D. 889 Verizon 890 500 Westchester Ave. 891 White Plains, NY 892 USA 894 EMail: roman.krzanowski@verizon.com 895 URI: http://www.verizon.com/ 897 Al Morton 898 AT&T Labs 899 Room D3 - 3C06 900 200 Laurel Ave. South 901 Middletown, NJ 07748 902 USA 904 Phone +1 732 420 1571 905 EMail: acmorton@att.com 906 URI: http://home.comcast.net/~acmacm/ 908 Kiho Yum 909 Juniper Networks 910 1194 Mathilda Ave. 911 Sunnyvale, CA 912 USA 914 EMail: kyum@juniper.net 915 URI: http://www.juniper.com/ 917 Jozef Z. Babiarz 918 Nortel Networks 919 3500 Carling Avenue 920 Ottawa, Ont K2H 8E9 921 Canada 923 Email: babiarz@nortel.com 924 URI: http://www.nortel.com/ 926 Full Copyright Statement 928 Copyright (C) The IETF Trust (2007). 930 This document is subject to the rights, licenses and restrictions 931 contained in BCP 78, and except as set forth therein, the authors 932 retain all their rights. 934 This document and the information contained herein are provided on 935 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 936 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 937 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 938 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 939 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 940 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 941 FOR A PARTICULAR PURPOSE. 943 Intellectual Property 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed 947 to pertain to the implementation or use of the technology described 948 in this document or the extent to which any license under such 949 rights might or might not be available; nor does it represent that 950 it has made any independent effort to identify any such rights. 951 Information on the procedures with respect to rights in RFC 952 documents can be found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use 957 of such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository 959 at http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 Acknowledgement 969 Funding for the RFC Editor function is provided by the IETF 970 Administrative Support Activity (IASA).