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