idnits 2.17.1 draft-ietf-ippm-twamp-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** 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 ([OWAMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 222: '...-Session command MUST be set to 5. Va...' RFC 2119 keyword, line 251: '... case the Server MAY support the Fetch...' RFC 2119 keyword, line 255: '...ed data. In this case the server MUST...' RFC 2119 keyword, line 324: '...ession-Reflector MUST determine the el...' RFC 2119 keyword, line 330: '...ession-Reflector MUST transmit a packe...' (3 more instances...) 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 (June 2006) is 6515 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Babiarz 3 Internet Draft Nortel Networks 4 Expires: December 2006 K. Hedayat 5 Brix Networks 6 R. Krzanowski 7 Verizon 8 Kiho Yum 9 Juniper Networks 10 June 2006 12 A Two-way Active Measurement Protocol (TWAMP) 13 draft-ietf-ippm-twamp-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 43 The IPPM One-way Active Measurement Protocol [OWAMP] provides a 44 common protocol for measuring one-way metrics between network 45 devices. OWAMP [OWAMP] can be used in both directions 46 independently to measure one-way metrics in both directions between 47 two network elements. However, it does not accommodate round-trip 48 or two-way measurements. This draft proposes a Two-way Active 49 Measurement Protocol, based on the One-way Active Measurement 50 Protocol [OWAMP], that will accommodate two-way or round-trip 51 measurements. 53 Table of Contents 55 1. Introduction..................................................2 56 2. Terminology...................................................3 57 3. Protocol Overview.............................................3 58 3.1 Relationship of Test and Control Protocols................3 59 3.2 Logical Model.............................................3 60 4. TWAMP Control.................................................5 61 4.1 Connection Setup..........................................6 62 4.2 TWAMP Control Commands....................................6 63 4.3 Creating Test Sessions....................................6 64 4.4 Send Schedules............................................6 65 4.5 Starting Test Sessions....................................6 66 4.6 Stop-Sessions.............................................6 67 4.7 Fetch-Session.............................................6 68 5. TWAMP Test....................................................7 69 5.1 Sender Behavior...........................................7 70 5.2 Reflector Behavior........................................8 71 6. Implementers Guide...........................................12 72 6.1 Complete TWAMP...........................................12 73 6.2 TWAMP Light..............................................12 74 7. Security Considerations......................................13 75 8. IANA Considerations..........................................13 76 9. References.................................................1413 77 9.1 Normative References.....................................14 79 1. Introduction 81 The IETF IP Performance Metrics (IPPM) working group has proposed 82 the draft standard for round-trip delay [RFC2681] metric. IPPM has 83 also proposed a new protocol for establishment of sessions for 84 measurement of one-way metrics [OWAMP]. Two-way Active Measurement 85 Protocol uses the methodology and architecture of OWAMP [OWAMP] to 86 define an open protocol for measurement of two-way or round-trip 87 metrics. Henceforth in this document the term two-way also 88 signifies round-trip. 90 2. Terminology 92 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 93 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 94 and "OPTIONAL" are to be interpreted as described in RFC 2119 95 [RFC2681] and indicate requirement levels for compliant 96 implementations. 98 3. Protocol Overview 100 The Two-way Active Measurement Protocol is an open protocol for 101 measurement of two-way metrics. It is based on OWAMP [OWAMP] and 102 adheres to its overall architecture and design. The protocol 103 defined in this document defines extensions and changes to OWAMP 104 [OWAMP] as follows: 106 - Define a new logical entity, Session-Reflector, in place of the 107 Session-Receiver. 109 - Define the Session-Reflector behavior in place of the 110 Session-Receiver behavior of OWAMP [OWAMP]. 112 - Define a new test packet format for packets transmitted from the 113 Session-Reflector to Session-Sender. 115 - Presence of the Fetch client in the system and the support of 116 the Fetch command by the Server are optional. 118 3.1 Relationship of Test and Control Protocols 120 Similar to OWAMP [OWAMP], TWAMP consists of two inter-related 121 protocols: TWAMP-Control and TWAMP-Test. The relationship of these 122 protocols is as defined in section 1.1 of OWAMP [OWAMP]. 124 3.2 Logical Model 125 The role and definition of the logical entities are as defined in 126 section 1.2 of OWAMP [OWAMP] with the following exceptions: 128 - Session-Receiver is called the Session-Reflector in the TWAMP 129 architecture. 131 - The presence of the Fetch-Client is optional since two-way 132 measurements do not require data retrieval from the 133 Session-Reflector. Consequently the support for the Fetch 134 command is optional by the Server. However, the Server may 135 choose to implement the Fetch-Client and support the 136 Fetch-Command to enable both one-way and two-way measurements 137 in the same session. This is explained in more detail in 138 section 4.7. 140 Several examples of possible relationship scenarios between these 141 roles are presented below. In the first example different logical 142 roles are played on different hosts. 144 +----------------+ +-------------------+ 145 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 146 +----------------+ +-------------------+ 147 ^ ^ 148 | | 149 | | 150 | | 151 | +----------------+<----------------+ 152 | | Server |<-------+ 153 | +----------------+ | 154 | ^ | 155 | | | 156 | TWAMP-Control TWAMP-Control 157 | | | 158 v v v 159 +----------------+ +-----------------+ 160 | Control-Client | | Fetch-Client | 161 +----------------+ +-----------------+ 163 Second example is similar to the first example without the 164 Fetch-Client. In this example only two-way metrics are collected. 166 +----------------+ +-------------------+ 167 | Session-Sender |<--TWAMP-Test-->| Session-Reflector | 168 +----------------+ +-------------------+ 169 ^ ^ 170 | | 171 | | 172 | | 173 | +----------------+ | 174 | | Server |<-----------------+ 175 | +----------------+ 176 | ^ 177 | | 178 | TWAMP-Control 179 | | 180 v V 181 +----------------+ 182 | Control-Client | 183 +----------------+ 185 Similar to OWAMP [OWAMP] different logical roles can be played by 186 the same host. For example, in the figure above, there could be 187 actually two hosts: one playing the role of Control-Client, 188 Fetch-Client, Session-Sender, and Server, and the other playing the 189 role of Session-Reflector. This is the third example shown below. 191 +-----------------+ +-------------------+ 192 | Server |<------------------| | 193 | Control-Client | | Session-Reflector | 194 | Session-Sender |<--TWAMP-Test----->| | 195 +-----------------+ +-------------------+ 197 Additionally, following the guidelines of OWAMP [OWAMP], TWAMP has 198 been defined to allow for small test packets that would fit inside 199 the payload of a single ATM cell (only in unauthenticated mode). 201 4. TWAMP Control 203 All TWAMP Control messages are similar in format to and follow the 204 same guidelines defined in section 3 of OWAMP [OWAMP]. 206 4.1 Connection Setup 208 Connection establishment of TWAMP follows the same procedure 209 defined in section 3.1 of OWAMP [OWAMP]. 211 4.2 TWAMP Control Commands 213 TWAMP control commands are as defined in section 3.3 of OWAMP 214 [OWAMP] except for the optional requirement of the Fetch-Session 215 command. 217 4.3 Creating Test Sessions 219 Test sessions creation follows the same procedure as defined in 220 section 3.4 of OWAMP [OWAMP]. In order to distinguish the session 221 as a two-way versus a one-way measurement session the first octet 222 of the Request-Session command MUST be set to 5. Value of 5 223 indicates that this is a Request-Session for a two-way metrics 224 measurement session. 226 4.4 Send Schedules 228 Send schedule of test packets follow the same procedure and 229 guidelines as defined in section 3.5 of OWAMP [OWAMP]. 231 4.5 Starting Test Sessions 233 Starting test sessions follow the same procedure and guidelines as 234 defined in section 3.6 of OWAMP [OWAMP]. 236 4.6 Stop-Sessions 238 Stopping test sessions follow the same procedure and guidelines as 239 defined in section 3.7 of OWAMP [OWAMP]. 241 4.7 Fetch-Session 242 The purpose of TWAMP is measurement of two-way metrics. Two-way 243 measurements do not rely on packet level data collected by the 244 Session-Reflector such as sequence number, timestamp, and TTL. As 245 such the protocol does not require the retrieval of packet level 246 data from the Server and the Fetch-Session command is optionally 247 supported by the Server. 249 However, TWAMP can be used as an extension to OWAMP [OWAMP] where 250 both one-way and two-way measurements are measured in the same 251 session. In this case the Server MAY support the Fetch-Session 252 command as defined in section 3.8 of OWAMP[OWAMP]. The 253 Session-Reflector will reject the Fetch-Session request if either 254 it does not support the Fetch-Session command or Session-Reflector 255 cannot provide the required data. In this case the server MUST 256 respond with a Fetch-Ack message with Accept value of 3. 258 5. TWAMP Test 260 The TWAMP test protocol is similar to the OWAMP [OWAMP] test 261 protocol with the exception that the Session-Reflector transmits 262 test packets to the Session-Sender in response to each test packet 263 it receives. TWAMP defines two different test packet formats, one 264 for packets transmitted by the Session-Sender and one for packets 265 transmitted by the Session-Reflector. As with OWAMP [OWAMP] test 266 protocol there are three modes: unauthenticated, authenticated, and 267 encrypted. 269 5.1 Sender Behavior 271 The sender behavior is as defined in section 4.1 of OWAMP [OWAMP] 272 for both packet timing and packet format. Additionally the 273 Session-Sender records the necessary information provided by the 274 packets transmitted by the Session-Reflector for measuring two-way 275 metrics. The information recording based on the received packet by 276 the Session-Sender is implementation dependent. 278 5.1.1 Packet Timings 280 Packet timings follow the same procedure and guidelines as defined 281 in section 4.1.1 of OWAMP [OWAMP]. 283 5.1.2 Packet Format and Content 285 Session-Sender packet format and content follow the same procedure 286 and guidelines as defined in section 4.1.2 of OWAMP [OWAMP]. 288 5.2 Reflector Behavior 290 When receiving packets the reflector behavior is same as 291 Session-Receiver behavior defined in section 4.2 of OWAMP [OWAMP] 292 with the exception of optional packet information recording. If 293 the Session-Reflector chooses not to collect packet information for 294 packets received from the Session-Sender, the Server will not 295 support the Fetch-Session command. Additionally, TWAMP requires 296 the Session-Reflector to transmit a packet to the Session-Sender in 297 response to each packet it receives. 299 As packets are received the Session-Reflector will, 301 - Timestamp the received packet. 303 - In authenticated or encrypted mode, decrypt the first block (16 304 octets) of the packet body. 306 - Copy the packet sequence number into the corresponding reflected 307 packet to the Session-Sender. 309 - Optionally store the packet sequence number, send time, receive 310 time, and the TTL for IPv4 (or Hop Limit for IPv6) from the 311 packet IP header for the results to be transferred. 313 - Packets not received within the Timeout are considered lost. 314 They are optionally recorded with their true sequence number, 315 presumed send time, receive time consisting of a string of zero 316 bits, and TTL (or Hop Limit) of 255. The Session-Reflector 317 will not generate a test packet to the Session-Sender for 318 packets that are considered lost. 320 - Transmit a test packet to the Session-Sender in response to 321 every received packet. The response must be generated as 322 immediately as possible. The format and content of the test 323 packet is defined in section 5.2.1. Prior to the transmission 324 of the test packet Session-Reflector MUST determine the elapsed 325 time since the reception of the packet for incorporating the 326 value in the reflected test packet. 328 5.2.1 Packet Format and Content 330 The Session-Reflector MUST transmit a packet to the Session-Sender 331 in response to each packet received. The Session-Reflector SHOULD 332 transmit the packets as immediately as possible. The 333 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 334 in the UDP packet to 255. 336 The test packet will have the necessary information for calculating 337 two-way metrics by the Session-Sender. The format of the test 338 packet depends on the mode being used. The format of the packet is 339 presented below. 341 For unauthenticated mode: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Sequence Number | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Timestamp | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Error Estimate | MBZ | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Receive Timestamp | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sender Sequence Number | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Sender Timestamp | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Sender Error Estimate | MBZ | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . . 365 . Packet Padding . 366 . . 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 For authenticated and encrypted modes: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Sequence Number | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | IZP (12 octets) | 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Timestamp | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Error Estimate | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 384 | IZP (6 octets) | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Receive Timestamp | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | IZP (8 octets) | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 393 | Sender Sequence Number | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | IZP (12 octets) | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Sender Timestamp | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Sender Error Estimate | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 403 | IZP (6 octets) | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 . . 408 . Packet Padding . 409 . . 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Sequence Number is the sequence number of the test packet and 414 starts with zero and is incremented by one for each subsequent 415 packet. The generated sequence number by the Session-Reflector, 416 Sequence Number, is independent from the sequence number of the 417 received packets. 419 Timestamp and Error Estimate are the transmit timestamp and error 420 estimate of the test packet respectively. Sender Timestamp and 421 Sender Error Estimate are exact copies of the timestamp and error 422 estimate from the Session-Sender test packet that corresponds to 423 this test packet. The format of all timestamp and error estimate 424 fields follow the definition and formats defined by OWAMP[OWAMP]. 426 Receive Timestamp is the time the test packet was received by the 427 reflector. The difference between Timestamp and Receive Timestamp 428 is the amount of time the packet was in transition in the 429 Session-Reflector. The Error Estimate of Timestamp also applies to 430 Receive Timestamp. 432 Sender Sequence Number is the Sequence Number of the packet 433 transmitted by the Session-Sender that corresponds to this test 434 packet. 436 Similar to OWAMP [OWAMP] the TWAMP packet layout is the same in 437 authenticated and encrypted modes. The encryption operation of 438 Session-Receiver packet follow the same rules of Session-Sender 439 packets as defined in OWAMP [OWAMP]. 441 The minimum data segment length is, therefore, 40 octets in 442 unauthenticated mode, and 80 octets in both authenticated mode and 443 encrypted modes. 445 The Session-Reflector TWAMP-Test packet layout is the same in 446 authenticated and encrypted modes. The encryption operations are, 447 however, different. The difference is that in encrypted mode both 448 the sequence numbers and timestamps are encrypted to provide 449 maximum data integrity protection while in authenticated mode the 450 sequence numbers are encrypted and the timestamps are sent in clear 451 text. Sending the timestamp in clear text in authenticated mode 452 allows one to reduce the time between when a timestamp is obtained 453 by a reflector and when the packet is reflected out. In encrypted 454 mode, both the sender and reflector have to fetch the timestamp, 455 encrypt it, and send it; in authenticated mode, the middle step is 456 removed, potentially improving accuracy (the sequence number can be 457 encrypted before the timestamp is fetched). 459 In authenticated mode, the first block (32 octets) of each packet 460 is encrypted using AES Electronic Cookbook (ECB) mode. 462 Obtaining the key, encryption method, and packet padding is as 463 defined in section 4.1.2 of OWAMP [OWAMP]. In unauthenticated 464 mode, no encryption is applied. 466 6. Implementers Guide 468 This section serves as guidance to implementers of TWAMP. Two 469 architectures are presented in this section for implementations 470 where two hosts play the subsystem roles of TWAMP. Although only 471 two architectures are presented here the protocol does not require 472 their use. Similar to OWAMP [OWAMP] TWAMP is designed with 473 complete flexibility to allow different architectures that suite 474 multiple system requirements. 476 6.1 Complete TWAMP 478 In this example the roles of Control-Client, Fetch-Client, and 479 Session-Sender are implemented in one host referred to as the 480 controller and the roles of Server and Session-Receiver are 481 implemented in another host referred to as the responder. 483 controller responder 484 +-----------------+ +-------------------+ 485 | Control-Client |<--TWAMP-Control-->| Server | 486 | Fetch-Client | | | 487 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 488 +-----------------+ +-------------------+ 490 This example provides an architecture that supports the full TWAMP 491 standard. The controller establishes the test session with the 492 responder through the TWAMP-Control protocol. After the session is 493 established the controller transmits test packets to the responder. 494 The responder follows the Session-Receiver behavior of both OWAMP 495 [OWAMP] and TWAMP as described in section 5.2. In this 496 architecture the responder supports the Fetch-Session command. 497 After the transmission of test packets the controller fetches the 498 responder's information through its Fetch-Client. This 499 architecture allows for collection of both one-way and two-way 500 metrics. 502 6.2 TWAMP Light 504 In this example the roles of Control-Client, Server, and 505 Session-Sender are implemented in one host referred to as the 506 controller and the role of Session-Receiver is implemented in 507 another host referred to as the responder. 509 controller responder 510 +-----------------+ +-------------------+ 511 | Server |<----------------->| | 512 | Control-Client | | Session-Reflector | 513 | Session-Sender |<--TWAMP-Test----->| | 514 +-----------------+ +-------------------+ 516 This example provides a simple architecture for responders where 517 their role will be to simply act as light test points in the 518 network. The controller establishes the test session with the 519 Server through non-standard means. After the session is 520 established the controller transmits test packets to the responder. 521 The responder follows the Session-Receiver behavior of TWAMP as 522 described in section 5.2.1 with the following exceptions. The 523 Session-Reflector SHOULD copy the sequence number of the received 524 packet to the Sequence Number field of the reflected packet. This 525 is necessary since in case of TWAMP Light the Session-Reflector 526 does not have knowledge of the session state. The controller 527 receives the reflected test packets and collects two-way metrics. 528 This architecture allows for collection of two-way metrics. 530 This example eliminates the need for the TWAMP-Control protocol and 531 assumes that the Session-Reflector is configured and communicates 532 its configuration with the Server through non-standard means. 533 Furthermore, the Server does not support the Fetch-Session command 534 and the responder does not collect the received packet information. 535 The Session-Reflector simply reflects the incoming packets back to 536 the controller while copying the necessary information and 537 generating sequence number and timestamp values per section 5.2.1. 539 7. Security Considerations 541 The security considerations of OWAMP [OWAMP] apply. 543 8. IANA Considerations 545 There are no IANA considerations associated with this 546 specification. 548 9. Acknowledgements 550 The authors wish to thank Sharee McNab and Nick Kinraid for their 551 comments and suggestions. 553 10. References 555 10.1 Normative References 557 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 558 Zekauskas, M., "A One-way Active Measurement Protocol 559 (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. 561 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 562 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 563 September 1999. 565 Authors' Addresses 567 Kaynam Hedayat 568 Brix Networks 569 285 Mill Road 570 Chelmsford, MA 01824 571 US 573 Phone: +1 978 367 5611 574 EMail: khedayat@brixnet.com 575 URI: http://www.brixnet.com/ 577 Roman M. Krzanowski, Ph.D. 578 Verizon 579 500 Westchester Ave. 580 White Plains, NY 581 US 583 Phone: +1 914 644 2395 584 EMail: roman.krzanowski@verizon.com 585 URI: http://www.verizon.com/ 586 Kiho Yum 587 Juniper Networks 588 1194 Mathilda Ave. 589 Sunnyvale, CA 590 US 592 Phone: +1 408 936 2272 593 EMail: kyum@juniper.net 594 URI: http://www.juniper.com/ 596 IPR Disclosure Acknowledgement 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed 600 to pertain to the implementation or use of the technology described 601 in this document or the extent to which any license under such 602 rights might or might not be available; nor does it represent that 603 it has made any independent effort to identify any such rights. 604 Information on the procedures with respect to rights in RFC 605 documents can be found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use 610 of such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository 612 at http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 This document and the information contained herein are provided on 623 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 624 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 625 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 626 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 627 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 628 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 629 PARTICULAR PURPOSE. 631 Copyright Notice 633 Copyright (C) The Internet Society (2006). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.