idnits 2.17.1 draft-ietf-ippm-twamp-08.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' an IANA Considerations Section in RFCs, RFC 2434,' ) ** The abstract seems to contain references ([RFC2119], [RFC2434], [RFC2681], [RFC3692], [0-15], [RFC4656], [RFC2474]), 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 == Line 781 has weird spacing: '...nce per sessi...' -- 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 6, 2008) is 5803 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 section? 'RFC4656' on line 977 looks like a reference -- Missing reference section? 'RFC2681' on line 981 looks like a reference -- Missing reference section? 'RFC2119' on line 985 looks like a reference -- Missing reference section? 'RFC2474' on line 988 looks like a reference -- Missing reference section? 'RFC2434' on line 993 looks like a reference -- Missing reference section? '0-15' on line 889 looks like a reference -- Missing reference section? 'RFC3692' on line 999 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Hedayat 2 Internet Draft Brix Networks 3 Expires: Dec 2008 R. Krzanowski 4 Intended Status:Standards Track Verizon 5 A. Morton 6 AT&T Labs 7 K. Yum 8 Juniper Networks 9 J. Babiarz 10 Nortel Networks 11 June 6, 2008 13 A Two-way Active Measurement Protocol (TWAMP) 14 draft-ietf-ippm-twamp-08 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides 46 a common protocol for measuring one-way metrics between network 47 devices. OWAMP can be used bi-directionally to measure one-way 48 metrics in both directions between two network elements. However, 49 it does not accommodate round-trip or two-way measurements. This 50 memo specifies a Two-way Active Measurement Protocol (TWAMP), based 51 on the OWAMP, that adds two-way or round-trip measurement 52 capabilities. The TWAMP measurement architecture is usually 53 comprised of two hosts with specific roles, and this allows for 54 some protocol simplifications, making it an attractive alternative 55 in some circumstances. 57 Table of Contents 59 1. Introduction..................................................3 60 1.1 Relationship of Test and Control Protocols................3 61 1.2 Logical Model.............................................3 62 1.3 Pronunciation Guide.......................................5 63 2. Protocol Overview.............................................5 64 3. TWAMP Control.................................................6 65 3.1 Connection Setup..........................................6 66 3.2 Integrity Protection......................................7 67 3.3 Value of the Accept Fields................................7 68 3.4 TWAMP Control Commands....................................7 69 3.5 Creating Test Sessions....................................8 70 3.6 Send Schedules...........................................10 71 3.7 Starting Test Sessions...................................10 72 3.8 Stop-Sessions............................................10 73 3.9 Fetch-Session............................................11 74 4. TWAMP Test...................................................11 75 4.1 Sender Behavior..........................................12 76 4.2 Reflector Behavior.......................................12 77 5. Implementers Guide...........................................19 78 6. Security Considerations......................................19 79 7. Acknowledgements.............................................20 80 8. IANA Considerations..........................................20 81 8.1 Registry Specification...................................20 82 8.2 Registry Management......................................21 83 8.3 Experimental Numbers.....................................21 84 8.4 Initial Registry Contents................................21 85 9. Internationalization Considerations..........................21 86 10. APPENDIX I - TWAMP Light (Informative)......................22 87 11. References..................................................23 88 11.1 Normative References....................................23 89 11.2 Informative References..................................23 91 1. Introduction 93 The Internet Engineering Task Force (IETF) has completed a Proposed 94 standard for the round-trip delay [RFC2681] metric. IETF has also 95 completed a protocol for the control and collection of one-way 96 measurements, the One-way Active Measurement Protocol (OWAMP) 97 [RFC4656]. However, OWAMP does not accommodate round-trip or two- 98 way measurements. 100 Two-way measurements are common in IP networks, primarily because 101 synchronization between local and remote clocks is unnecessary for 102 round-trip delay, and measurement support at the remote end may be 103 limited to a simple echo function. This memo specifies the Two-way 104 Active Measurement Protocol, or TWAMP. TWAMP uses the methodology 105 and architecture of OWAMP [RFC4656] to define an open protocol for 106 measurement of two-way or round-trip metrics (henceforth in this 107 document the term two-way also signifies round-trip). The TWAMP 108 measurement architecture is usually comprised of only two hosts 109 with specific roles, and this allows for some protocol 110 simplifications, making it an attractive alternative to OWAMP in 111 some circumstances. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 RFC 2119 [RFC2119]. 118 1.1 Relationship of Test and Control Protocols 120 Similar to OWAMP [RFC4656], 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 [RFC4656]. 123 TWAMP-Control is used to initiate, start, and stop test sessions, 124 whereas TWAMP-Test is used to exchange test packets between two 125 TWAMP entities. 127 1.2 Logical Model 128 The role and definition of the logical entities are as defined in 129 section 1.2 of OWAMP [RFC4656] with the following exceptions: 131 - The Session-Receiver is called the Session-Reflector in the 132 TWAMP architecture. The Session-Reflector has the capability 133 to create and send a measurement packet when it receives a 134 measurement packet. Unlike the Session-Receiver, the 135 Session-Reflector does not collect any packet information. 137 - The Server is an end system that manages one or more TWAMP 138 sessions, and is capable of configuring per-session state in 139 the end-points. However, a Server associated with a 140 Session-Reflector would not have the capability to return the 141 results of a test session, and this is a difference from OWAMP. 143 - The Fetch-Client entity does not exist in the TWAMP 144 architecture, as the Session-Reflector does not collect any 145 packet information to be fetched. Consequently there is no 146 need for the Fetch-Client. 148 An example of possible relationship scenarios between these roles 149 are presented below. In this example different logical roles are 150 played on different hosts. Unlabeled links in the figure are 151 unspecified by this document and may be proprietary protocols. 153 +----------------+ +-------------------+ 154 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 155 +----------------+ +-------------------+ 156 ^ ^ 157 | | 158 | | 159 | | 160 | +----------------+<----------------+ 161 | | Server | 162 | +----------------+ 163 | ^ 164 | | 165 | TWAMP-Control 166 | | 167 v v 168 +----------------+ 169 | Control-Client | 170 +----------------+ 172 As in OWAMP [RFC4656], different logical roles can be played by the 173 same host. For example, in the figure above, there could be 174 actually two hosts: one playing the roles of Control-Client and 175 Session-Sender, and the other playing the roles of Server and 176 Session-Reflector. This example is shown below. 178 +-----------------+ +-------------------+ 179 | Control-Client |<--TWAMP Control-->| Server | 180 | | | | 181 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 182 +-----------------+ +-------------------+ 184 Additionally, following the guidelines of OWAMP [RFC4656], TWAMP 185 has been defined to allow for small test packets that would fit 186 inside the payload of a single ATM cell (only in unauthenticated 187 mode). 189 1.3 Pronunciation Guide 191 The acronym OWAMP is usually pronounced in two syllables, Oh-wamp. 193 The acronym TWAMP is also pronounced in two syllables, Tee-wamp. 195 2. Protocol Overview 197 The Two-way Active Measurement Protocol is an open protocol for 198 measurement of two-way metrics. It is based on OWAMP [RFC4656] and 199 adheres to its overall architecture and design. The TWAMP-control 200 and TWAMP-Test protocols accomplish their testing tasks as outlined 201 below: 203 - The Control-Client initiates a TCP connection on TWAMP's well- 204 known port, and the Server (its role now established) responds 205 with its greeting message indicating the security/integrity 206 mode(s) it is willing to support. 208 - The Control-Client responds with the chosen mode of 209 communication and information supporting integrity protection 210 and encryption, if the mode requires them. The Server responds 211 to accept the mode and start time. This completes the control 212 connection setup. 214 - The Control-Client requests (and describes) a test session with 215 a unique TWAMP-Control message. The Server responds with its 216 acceptance and supporting information. More than one test 217 session may be requested with additional messages. 219 - The Control-Client initiates all requested testing with a start 220 sessions message, and the Server acknowledges. 222 - The Session-Sender and the Session-Reflector exchange test 223 packets according to the TWAMP-Test protocol for each active 224 session. 226 - When appropriate, the Control-Client sends a message to stop all 227 test sessions. 229 There are two recognized extension mechanisms in the TWAMP 230 Protocol. The Modes field is used to establish the communication 231 options during TWAMP-Control Connection Setup. The TWAMP-Control 232 Command Number is another intended extension mechanism, allowing 233 additional commands to be defined in the future. TWAMP-Control 234 protocol addresses different levels of support between Control- 235 Client and Server. 237 All multi-octet quantities defined in this document are represented 238 as unsigned integers in network byte order unless specified 239 otherwise. 241 3. TWAMP Control 243 TWAMP-Control is a derivative of the OWAMP-Control for two-way 244 measurements. All TWAMP Control messages are similar in format and 245 follow similar guidelines to those defined in section 3 of OWAMP 246 [RFC4656] with the exceptions outlined in the following sections. 247 One such exception is the Fetch Session command, which is not used 248 in TWAMP. 250 3.1 Connection Setup 252 Connection establishment of TWAMP follows the same procedure 253 defined in section 3.1 of OWAMP [RFC4656]. The Modes field is a 254 recognized extension mechanism in TWAMP, and the current mode 255 values are identical to those used in OWAMP. The only exception is 256 the well-known port number for TWAMP-control. A client opens a TCP 257 connection to the server on well-known port N (Refer to the IANA 258 Considerations section below for the TWAMP-control port number 259 assignment). The host that initiates the TCP connection takes the 260 roles of Control-Client and (in the two-host implementation) the 261 Session-Sender. The host that acknowledges the TCP connection 262 accepts the roles of Server and (in the two-host implementation) 263 the Session Reflector. 265 The possibility exists for Control-Client failure after TWAMP- 266 Control connection establishment, or the path between the Control- 267 Client and Server may fail while a connection is in-progress. The 268 Server MAY discontinue any established control connection when no 269 packet associated with that connection has been received within 270 SERVWAIT seconds. The Server SHALL suspend monitoring control 271 connection activity after receiving a Start-Sessions command, and 272 SHALL resume after receiving a Stop-Sessions command (IF the 273 SERVWAIT option is supported). Note that the REFWAIT time-out 274 (described below) covers failures during test sessions. The default 275 value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY 276 be configurable. This time-out allows a Server to free-up resources 277 in case of failure. 279 3.2 Integrity Protection 281 Integrity protection of TWAMP follows the same procedure defined in 282 section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers 283 everything sent in a given direction between the previous HMAC (but 284 not including it) and up to the beginning of the new HMAC. This 285 way, once encryption is set up, each bit of the TWAMP-Control 286 connection is authenticated by an HMAC exactly once. 288 Note that the Server-Start message (sent by a Server during the 289 initial control connection exchanges) does not terminate with an 290 HMAC field. Therefore, the HMAC in the first Accept-Session message 291 also covers the Server-Start message and includes the Start-Time 292 field in the HMAC calculation. 294 3.3 Value of the Accept Fields 296 Accept values used in TWAMP are the same as the values defined in 297 section 3.3 of OWAMP [RFC4656]. 299 3.4 TWAMP Control Commands 301 TWAMP control commands conform to the rules defined in section 3.4 302 of OWAMP [RFC4656] 304 The following commands are available for the Control-client: 305 Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server 306 can send specific messages in response to the commands it receives 307 (as described in the sections that follow). 309 Note that the OWAMP Request-Session command is replaced by the 310 TWAMP Request-TW-Session command, and the Fetch-Session command 311 does not appear in TWAMP. 313 3.5 Creating Test Sessions 315 Test session creation follows the same procedure as defined in 316 section 3.5 of OWAMP [RFC4656]. 318 In TWAMP, the first octet is referred to as the Command Number, and 319 the Command Number is a recognized extension mechanism. Readers are 320 encouraged to consult the TWAMP-Control Command Number Registry to 321 determine if there have been additional values assigned. 323 The Command Number value of 5 indicates a Request-TW-Session 324 Command, and the Server MUST interpret this command as a request 325 for a two-way test session using the TWAMP-Test protocol. 327 If a TWAMP Server receives an unexpected command number, it MUST 328 respond with the Accept field set to 3 (meaning "Some aspect of 329 request is not supported") in the Accept-Session message. Command 330 numbers that are Forbidden (and possibly numbers that are Reserved) 331 are unexpected. 333 In OWAMP, the Conf-Sender field is set to 1 when the 334 Request-Session message describes a task where the Server will 335 configure a one-way test packet sender. Likewise, the 336 Conf-Receiver field is set to 1 when the message describes the 337 configuration for a Session-Receiver. In TWAMP, both endpoints 338 perform in these roles, with the Session-Sender first sending and 339 then receiving test packets. The Session-Reflector first receives 340 the test packets, and returns each test packet to the 341 Session-Sender as fast as possible. 343 Both Conf-Sender field and Conf-Receiver field MUST be set to 0 344 since the Session-Reflector will both receive and send packets, and 345 the roles are established according to which host initiates the TCP 346 connection for control. The server MUST interpret any non-zero 347 value as an improperly formatted command, and MUST respond with the 348 Accept field set to 3 (meaning "Some aspect of request is not 349 supported") in the Accept-Session message. 351 The Session-Reflector in TWAMP does not process incoming test 352 packets for performance metrics and consequently does not need to 353 know the number of incoming packets and their timing schedule. 354 Consequently the Number of Scheduled Slots and Number of Packets 355 MUST be set to 0. 357 The Sender Port is the UDP port from which TWAMP-Test packets will 358 be sent and the port to which TWAMP-Test packets will be sent by 359 the Session-Reflector (Session-Sender will use the same UDP port to 360 send and receive packets). Receiver Port is the desired UDP port 361 to which TWAMP test packets will be sent by the Session-Sender (the 362 port where the Session-Reflector is asked to receive test packets). 363 Receiver Port is also the UDP port from which TWAMP test packets 364 will be sent by the Session-Reflector (Session-Reflector will use 365 the same UDP port to send and receive packets). 367 The Sender Address and Receiver Address fields contain, 368 respectively, the sender and receiver addresses of the endpoints of 369 the Internet path over which a TWAMP test session is requested. 370 They MAY be set to 0, in which case the IP addresses used for the 371 Control-Client to Server TWAMP-Control Message exchange MUST be 372 used in the test packets. 374 The Session Identifier (SID) is as defined in OWAMP [RFC4656]. 375 Since the SID is always generated by the receiving side, the Server 376 determines the SID, and the SID in the Request-TW-Session message 377 MUST be set to 0. 379 The Start Time is as defined in OWAMP [RFC4656]. 381 The Timeout is interpreted differently from the definition in OWAMP 382 [RFC4656]. In TWAMP, Timeout is the interval that the 383 Session-Reflector MUST wait after receiving a Stop-Sessions 384 message. In case there are test packets still in transit, the 385 Session Reflector MUST reflect them if they arrive within the 386 timeout interval following the reception of the Stop-Sessions 387 message. The Session-Reflector MUST NOT reflect packets that are 388 received beyond the timeout. 390 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 391 capability of this field is to set the Differentiated Services Code 392 Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST 393 be used in test packets reflected by the Session-Reflector. 395 Since there are no Schedule Slot Descriptions, the Request-TW- 396 Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash 397 Message Authentication Code) fields. This completes one logical 398 message, referred to as the Request-TW-Session Command. 400 The Session-Reflector MUST respond to each Request-TW-Session 401 Command with an Accept-Message as defined in OWAMP [RFC4656]. When 402 the Accept Field = 0, the Port field confirms (repeats) the port to 403 which TWAMP test packets are sent by the Session-Sender toward the 404 Session-Reflector. In other words, the Port field indicates the 405 port number where the Session-Reflector expects to receive packets 406 from the Session-Sender. 408 When the requested Receiver Port is not available (e.g., port in 409 use), the Server at the Session-Reflector MAY suggest an alternate 410 and available port for this session in the Port Field. The 411 Session-Sender either accepts the alternate port, or composes a new 412 Session-Request message with suitable parameters. Otherwise, the 413 Server at the Session-Reflector uses the Accept Field to convey 414 other forms of session rejection or failure and MUST NOT suggest an 415 alternate port. In this case the Port Field MUST be set to zero. 417 3.6 Send Schedules 419 The Send Schedule for test packets defined in section 3.6 of OWAMP 420 [RFC4656] is not used in TWAMP. The Control-Client and 421 Session-Sender MAY autonomously decide the Send Schedule. The 422 Session-Reflector SHOULD return each test packet to the 423 Session-Sender as quickly as possible. 425 3.7 Starting Test Sessions 427 The procedure and guidelines for Starting test sessions is the same 428 as defined in section 3.7 of OWAMP [RFC4656]. 430 3.8 Stop-Sessions 432 The procedure and guidelines for Stopping test sessions is the same 433 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions 434 command can only be issued by the Control-Client. The message MUST 435 NOT contain any session description records or skip ranges. The 436 message is terminated with a single block HMAC, to complete the 437 Stop-Sessions Command. Since the TWAMP Stop-Sessions command does 438 not convey SIDs, it applies to all sessions previously requested 439 and started with a Start-Sessions command. 441 Thus, the TWAMP Stop-Sessions command is constructed as follows: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | 3 | Accept | MBZ | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Number of Sessions | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | MBZ (8 octets) | 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 | HMAC (16 octets) | 455 | | 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 3.9 Fetch-Session 461 The purpose of TWAMP is measurement of two-way metrics. Two-way 462 measurement methods do not require packet level data to be 463 collected by the Session-Reflector (such as sequence number, 464 timestamp, and TTL) because this data is communicated in the 465 "reflected" test packets. As such the protocol does not require 466 the retrieval of packet level data from the Server and the OWAMP 467 Fetch-Session command is not used in TWAMP. 469 4. TWAMP Test 471 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 472 protocol with the exception that the Session-Reflector transmits 473 test packets to the Session-Sender in response to each test packet 474 it receives. TWAMP defines two different test packet formats, one 475 for packets transmitted by the Session-Sender and one for packets 476 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 477 protocol there are three modes: unauthenticated, authenticated, and 478 encrypted. 480 4.1 Sender Behavior 482 The sender behavior is determined by the configuration of the 483 Session-Sender and is not defined in this standard. Further, the 484 Session-Reflector does not need to know the Session-Sender behavior 485 to the degree of detail as needed in OWAMP [RFC4656]. 486 Additionally the Session-Sender collects and records the necessary 487 information provided from the packets transmitted by the 488 Session-Reflector for measuring two-way metrics. The information 489 recording based on the received packet by the Session-Sender is 490 implementation dependent. 492 4.1.1 Packet Timings 494 Since the Send Schedule is not communicated to the 495 Session-Reflector, there is no need for a standardized computation 496 of packet timing. 498 Regardless of any scheduling delays, each packet that is actually 499 sent MUST have the best possible approximation of its real time of 500 departure as its timestamp (in the packet). 502 4.1.2 Packet Format and Content 504 The Session-Sender packet format and content follow the same 505 procedure and guidelines as defined in section 4.1.2 of OWAMP 506 [RFC4656] (with the exception of the reference to the Send 507 Schedule). 509 4.2 Reflector Behavior 511 TWAMP requires the Session-Reflector to transmit a packet to the 512 Session-Sender in response to each packet it receives. 514 As packets are received the Session-Reflector will, 516 - Timestamp the received packet. Each packet that is actually 517 received MUST have the best possible approximation of its real 518 time of arrival entered as its timestamp (in the packet). 520 - In authenticated or encrypted mode, decrypt the appropriate 521 sections of the packet body (first block (16 octets) for 522 authenticated, 96 octets for encrypted), and then check 523 integrity of sections covered by the HMAC. 525 - Copy the packet sequence number into the corresponding reflected 526 packet to the Session-Sender. 528 - Sender TTL value is extracted from the TTL/Hop Limit value of 529 received packets. Session-Reflector Implementations SHOULD 530 fetch the TTL/Hop Limit value from the IP header of the packet, 531 replacing the value of 255 set by the Session-Sender. If an 532 implementation does not fetch the actual TTL value (the only 533 good reason not to do so is an inability to access the TTL 534 field of arriving packets), it MUST set the Sender TTL value as 535 255. 537 - In authenticated and encrypted modes, the HMAC MUST be 538 calculated first, then the appropriate portion of the packet 539 body is encrypted. 541 - Transmit a test packet to the Session-Sender in response to 542 every received packet. The response MUST be generated as 543 immediately as possible. The format and content of the test 544 packet is defined in section 4.2.1. Prior to the transmission 545 of the test packet, the Session-Reflector MUST enter the best 546 possible approximation of its actual sending time of as its 547 Timestamp (in the packet). This permits the determination of 548 the elapsed time between the reception of the packet and its 549 transmission. 551 - Packets not received within the Timeout (following the Stop- 552 Session command) MUST be ignored by the 553 Reflector. The Session-Reflector MUST NOT generate a test 554 packet to the Session-Sender for packets that are ignored. 556 The possibility exists for Session-Sender failure during a session, 557 or the path between the Session-Sender and Session-Reflector may 558 fail while a test session is in-progress. The Session-Reflector MAY 559 discontinue any session which has been Started when no packet 560 associated with that session has been received for REFWAIT seconds. 561 The default value of REFWAIT SHALL be 900 seconds, and this waiting 562 time MAY be configurable. This time-out allows a Session-Reflector 563 to free-up resources in case of failure. 565 4.2.1 TWAMP-Test Packet Format and Content 567 The Session-Reflector MUST transmit a packet to the Session-Sender 568 in response to each packet received. The Session-Reflector SHOULD 569 transmit the packets as immediately as possible. The 570 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 571 in the UDP packet to 255. 573 The test packet will have the necessary information for calculating 574 two-way metrics by the Session-Sender. The format of the test 575 packet depends on the mode being used. The various formats of the 576 packet are presented below. 578 For unauthenticated mode: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Sequence Number | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Timestamp | 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Error Estimate | MBZ | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Receive Timestamp | 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Sender Sequence Number | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Sender Timestamp | 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Sender Error Estimate | MBZ | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Sender TTL | | 601 +-+-+-+-+-+-+-+-+ + 602 | | 603 . . 604 . Packet Padding . 605 . . 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 For authenticated and encrypted modes: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Sequence Number | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | MBZ (12 octets) | 616 | | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Timestamp | 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Error Estimate | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 624 | MBZ (6 octets) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Receive Timestamp | 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | MBZ (8 octets) | 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Sender Sequence Number | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | MBZ (12 octets) | 635 | | 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Sender Timestamp | 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Sender Error Estimate | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 643 | MBZ (6 octets) | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Sender TTL | | 646 +-+-+-+-+-+-+-+-+ + 647 | | 648 | | 649 | MBZ (15 octets) | 650 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 651 | HMAC (16 octets) | 652 | | 653 | | 654 | | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 656 | | 657 . . 658 . Packet Padding . 659 . . 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Note that all Timestamps have the same format as OWAMP [RFC4656] as 664 follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Integer part of seconds | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Fractional part of seconds | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Sequence Number is the sequence number of the test packet according 675 to its transmit order. It starts with zero and is incremented by 676 one for each subsequent packet. The Sequence Number generated by 677 the Session-Reflector is independent from the sequence number of 678 the arriving packets. 680 Timestamp and Error Estimate are the Session-Reflector's transmit 681 timestamp and error estimate for the reflected test packet, 682 respectively. The format of all timestamp and error estimate 683 fields follow the definition and formats defined by OWAMP[RFC4656]. 685 Sender Timestamp and Sender Error Estimate are exact copies of the 686 timestamp and error estimate from the Session-Sender test packet 687 that corresponds to this test packet. 689 Sender TTL is 255 when transmitted by the Session Sender. Sender 690 TTL is set to the Time To Live (or Hop Count) value of the received 691 packet from the IP packet header when transmitted by the Session 692 Reflector. 694 Receive Timestamp is the time the test packet was received by the 695 reflector. The difference between Timestamp and Receive Timestamp 696 is the amount of time the packet was in transition in the 697 Session-Reflector. The Error Estimate associated with the 698 Timestamp field also applies to the Receive Timestamp. 700 Sender Sequence Number is a copy of the Sequence Number of the 701 packet transmitted by the Session-Sender that caused the 702 Session-Reflector to generate and send this test packet. 704 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 705 authenticated and encrypted modes. The encryption operation of 706 Session-Sender packet follow the same rules of Session-Sender 707 packets as defined in OWAMP [RFC4656]. 709 The minimum data segment length is, therefore, 41 octets in 710 unauthenticated mode, and 104 octets in both authenticated mode and 711 encrypted modes (with the implication that the later two modes will 712 not fit in a single ATM cell). 714 The Session-Reflector TWAMP-Test packet layout is the same in 715 authenticated and encrypted modes. The encryption operations are, 716 however, different. The difference is that in encrypted mode both 717 the sequence numbers and timestamps are encrypted to provide 718 maximum data integrity protection while in authenticated mode the 719 sequence numbers are encrypted and the timestamps are sent in clear 720 text. Sending the timestamp in clear text in authenticated mode 721 allows one to reduce the time between when a timestamp is obtained 722 by a reflector and when the packet is reflected out. In encrypted 723 mode, both the sender and reflector have to fetch the timestamp, 724 encrypt it, and send it; in authenticated mode, the middle step is 725 removed, potentially improving accuracy (the sequence number can be 726 encrypted before the timestamp is fetched). Authenticated mode 727 permits the timestamp to be fetched after a portion of the packet 728 is encrypted. Thus, the main differences between authenticated mode 729 and encrypted mode are the portions of the test packets that are 730 covered by HMAC and encrypted. 732 In authenticated mode, the first block (16 octets) of each packet 733 is encrypted using AES Electronic Cookbook (ECB) mode. 735 Obtaining the key, encryption method, and packet padding follows 736 the same procedure as OWAMP as described below. 737 Similarly to each TWAMP-Control session, each TWAMP-Test session 738 has two keys: an AES Session-key and an HMAC Session-key. However, 739 there is a difference in how the keys are obtained: in the case of 740 TWAMP-Control, the keys are generated by the client and 741 communicated (as part of the Token) during connection setup as part 742 of Set-Up-Response message; in the case of TWAMP-Test, described 743 here, the keys are derived from the TWAMP-Control keys and the SID. 745 The TWAMP-Test AES Session-key is obtained as follows: the 746 TWAMP-Control AES Session-key (the same AES Session-key as is used 747 for the corresponding TWAMP-Control session, where it is used in a 748 different chaining mode) is encrypted, using AES, with the 16-octet 749 session identifier (SID) as the key; this is a single-block ECB 750 encryption; its result is the TWAMP-Test AES Session-key to use in 751 encrypting (and decrypting) the packets of the particular 752 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 753 TWAMP-Control AES Session-key, and the SID are comprised of 16 754 octets. 756 The TWAMP-Test HMAC Session-key is obtained as follows: the 757 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 758 used for the corresponding TWAMP-Control session) is encrypted, 759 using AES, with the 16-octet session identifier (SID) as the key; 760 this is a two-block CBC encryption, always performed with IV=0; its 761 result is the TWAMP-Test HMAC Session-key to use in authenticating 762 the packets of the particular TWAMP-Test session. Note that all of 763 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 764 comprised of 32 octets, while the SID is 16 octets. 766 ECB mode used for encrypting the first block of TWAMP-Test packets 767 in authenticated mode does not involve any actual chaining; this 768 way, lost, duplicated, or reordered packets do not cause problems 769 with deciphering any packet in a TWAMP-Test session. 771 In encrypted mode, the first six blocks (96octets) are encrypted 772 using AES CBC mode. The AES Session-key to use is obtained in the 773 same way as the key for authenticated mode. Each TWAMP-Test packet 774 is encrypted as a separate stream, with just one chaining 775 operation; chaining does not span multiple packets so that lost, 776 duplicated, or reordered packets do not cause problems. The 777 initialization vector for the CBC encryption is a value with all 778 bits equal to zero. 780 Implementation note: Naturally, the key schedule for each 781 TWAMP-Test session MUST be set up at most once per session, not 782 once per packet. 784 HMAC in TWAMP-Test only covers the part of the packet that is also 785 encrypted. So, in authenticated mode, HMAC covers the first block 786 (16 octets); in encrypted mode, HMAC covers the first six blocks 787 (96 octets). In TWAMP-Test HMAC is not encrypted (note that this 788 is different from TWAMP-Control, where encryption in stream mode is 789 used, so everything including the HMAC blocks ends up being 790 encrypted). 792 In unauthenticated mode, no encryption or authentication is 793 applied. 795 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 796 generated independently of any other pseudo-random numbers 797 mentioned in this document). However, implementations MUST provide 798 a configuration parameter, an option, or a different means of 799 making Packet Padding consist of all zeros. 801 5. Implementers Guide 803 This section serves as guidance to implementers of TWAMP. The 804 example architecture presented here is not a requirement. Similar 805 to OWAMP [RFC4656], TWAMP is designed with enough flexibility to 806 allow different architectures that suit multiple system 807 requirements. 809 In this example the roles of Control-Client and Session-Sender are 810 implemented in one host referred to as the controller and the roles 811 of Server and Session-Reflector are implemented in another host 812 referred to as the responder. 814 controller responder 815 +-----------------+ +-------------------+ 816 | Control-Client |<--TWAMP-Control-->| Server | 817 | | | | 818 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 819 +-----------------+ +-------------------+ 821 This example provides an architecture that supports the full TWAMP 822 standard. The controller establishes the test session with the 823 responder through the TWAMP-Control protocol. After the session is 824 established the controller transmits test packets to the responder. 825 The responder follows the Session-Reflector behavior of TWAMP as 826 described in section 4.2. 828 Appendix I provides an example for purely informational purposes. 829 It suggests an incremental path to adopting TWAMP, by implementing 830 the TWAMP-Test protocol first. 832 6. Security Considerations 834 Fundamentally TWAMP and OWAMP use the same protocol for 835 establishment of Control and Test procedures. The main difference 836 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 837 vs. the Session-Receiver behavior in OWAMP. This difference in 838 behavior does not introduce any known security vulnerabilities that 839 are not already addressed by the security features of OWAMP. The 840 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 842 7. Acknowledgements 844 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 845 Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and 846 Murtaza Chiba for their comments, suggestions, reviews, helpful 847 discussion and proof-reading. 849 8. IANA Considerations 851 IANA has allocated a well-known TCP port number (861) for the 852 OWAMP-Control part of the OWAMP [RFC4656] protocol. 853 ... 854 owamp-control 861/tcp OWAMP-Control 855 owamp-control 861/udp OWAMP-Control 856 # [RFC4656] 857 # 862-872 Unassigned 859 IANA is requested to allocate a well-known TCP/UDP port number for 860 the TWAMP-Control protocol. It would be ideal if the port number 861 assignment was adjacent to the OWAMP assignment. The recommended 862 Keyword for this entry is "twamp-control" and the Description is 863 "Two-way Active Measurement Protocol (TWAMP) Control". 865 During final editing, port N in section 3.1 should be replaced with 866 the assigned port number. 868 Since TWAMP adds an additional Control command to the OWAMP-Control 869 specification, and describes behavior when this control command is 870 used, this memo requests creation an IANA registry for the TWAMP 871 Command Number field. The field is not explicitly named in 872 [RFC4656] but is called out for each command. This field is a 873 recognized extension mechanism for TWAMP. 875 8.1 Registry Specification 877 IANA will create an TWAMP-Control Command Number registry. TWAMP- 878 Control commands are specified by the first octet in OWAMP-Control 879 messages as shown in section 3.5 of [RFC4656], and modified by this 880 document. Thus this registry may contain sixteen possible values. 882 8.2 Registry Management 884 Because the registry may only contain sixteen values, and because 885 OWAMP and TWAMP are IETF protocols, this registry must only be 886 updated by "IETF Consensus" as specified in [RFC2434] -- an RFC 887 documenting the use that is approved by the IESG. We expect that 888 new values will be assigned as monotonically increasing integers in 889 the range [0-15], unless there is a good reason to do otherwise. 891 8.3 Experimental Numbers 893 [RFC3692] recommends allocating an appropriate number of values for 894 experimentation and testing. It is not clear to the authors 895 exactly how many numbers might be useful in this space, nor if it 896 would be useful that they were easily distinguishable or at the 897 "high end" of the number range. Two might be useful, say one for 898 session control, and one for session fetch. On the other hand, a 899 single number would allow for unlimited extension, because the 900 format of the rest of the message could be tailored, with 901 allocation of other numbers done once usefulness has been proven. 902 Thus, this document will allocate one number, the next sequential 903 number 6, as designated for experimentation and testing. 905 8.4 Initial Registry Contents 907 TWAMP-Control Command Number Registry 909 Value Description Semantics Definition 910 0 Reserved 911 1 Forbidden 912 2 Start-Sessions RFC4656, Section 3.7 913 3 Stop-Sessions RFC4656, Section 3.8 914 4 Reserved 915 5 Request-TW-Session this document, Section 3.5 916 6 Experimentation undefined, see Section 8.3. 918 9. Internationalization Considerations 920 The protocol does not carry any information in a natural language, 921 with the possible exception of the KeyID in TWAMP-Control, which is 922 encoded in UTF-8. 924 10. APPENDIX I - TWAMP Light (Informative) 926 In this example the roles of Control-Client, Server, and 927 Session-Sender are implemented in one host referred to as the 928 controller and the role of Session-Reflector is implemented in 929 another host referred to as the responder. 931 controller responder 932 +-----------------+ +-------------------+ 933 | Server |<----------------->| | 934 | Control-Client | | Session-Reflector | 935 | Session-Sender |<--TWAMP-Test----->| | 936 +-----------------+ +-------------------+ 938 This example provides a simple architecture for responders where 939 their role will be to simply act as light test points in the 940 network. The controller establishes the test session with the 941 Server through non-standard means. After the session is 942 established the controller transmits test packets to the responder. 943 The responder follows the Session-Reflector behavior of TWAMP as 944 described in section 4.2 with the following exceptions. 946 In the case of TWAMP Light, the Session-Reflector does not 947 necessarily have knowledge of the session state. IF the 948 Session-Reflector does not have knowledge of the session state, 949 THEN the Session-Reflector MUST copy the Sequence Number of the 950 received packet to the Sequence Number field of the reflected 951 packet. The controller receives the reflected test packets and 952 collects two-way metrics. This architecture allows for collection 953 of two-way metrics. 955 This example eliminates the need for the TWAMP-Control protocol and 956 assumes that the Session-Reflector is configured and communicates 957 its configuration with the Server through non-standard means. The 958 Session-Reflector simply reflects the incoming packets back to the 959 controller while copying the necessary information and generating 960 sequence number and timestamp values per section 4.2.1. 961 TWAMP Light introduces some additional security considerations. The 962 non-standard means to control the responder and establish test 963 sessions SHOULD offer the features listed below. 965 The non-standard responder control protocol SHOULD have an 966 authenticated mode of operation. The responder SHOULD be 967 configurable to accept only authenticated control sessions. 969 The non-standard responder control protocol SHOULD have a means to 970 activate the authenticated and encrypted modes of the TWAMP-Test 971 protocol. 973 11. References 975 11.1 Normative References 977 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 978 Zekauskas, M., "A One-way Active Measurement Protocol 979 (OWAMP)", RFC 4656, October 2004. 981 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 982 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 983 September 1999. 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, March 1997. 988 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 989 Definition of the Differentiated Services Field (DS 990 Field) in the IPv4 and IPv6 Headers", RFC 2474, 991 December 1998. 993 [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing 994 an IANA Considerations Section in RFCs, RFC 2434, 995 October 1998. 997 11.2 Informative References 999 [RFC3692] Narten, T., Assigning Experimental and Testing Numbers 1000 Considered Useful, RFC 3692, January 2004. 1002 Authors' Addresses 1004 Kaynam Hedayat 1005 Brix Networks 1006 285 Mill Road 1007 Chelmsford, MA 01824 1008 USA 1009 EMail: khedayat@brixnet.com 1010 URI: http://www.brixnet.com/ 1012 Roman M. Krzanowski, Ph.D. 1013 Verizon 1014 500 Westchester Ave. 1015 White Plains, NY 1016 USA 1017 EMail: roman.krzanowski@verizon.com 1018 URI: http://www.verizon.com/ 1020 Al Morton 1021 AT&T Labs 1022 Room D3 - 3C06 1023 200 Laurel Ave. South 1024 Middletown, NJ 07748 1025 USA 1026 Phone +1 732 420 1571 1027 EMail: acmorton@att.com 1028 URI: http://home.comcast.net/~acmacm/ 1030 Kiho Yum 1031 Juniper Networks 1032 1194 Mathilda Ave. 1033 Sunnyvale, CA 1034 USA 1035 EMail: kyum@juniper.net 1036 URI: http://www.juniper.com/ 1038 Jozef Z. Babiarz 1039 Nortel Networks 1040 3500 Carling Avenue 1041 Ottawa, Ont K2H 8E9 1042 Canada 1043 Email: babiarz@nortel.com 1044 URI: http://www.nortel.com/ 1046 Full Copyright Statement 1048 Copyright (C) The IETF Trust (2008). 1050 This document is subject to the rights, licenses and restrictions 1051 contained in BCP 78, and except as set forth therein, the authors 1052 retain all their rights. 1054 This document and the information contained herein are provided on 1055 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1056 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1057 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1058 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1059 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1060 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1061 FOR A PARTICULAR PURPOSE. 1063 Intellectual Property 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed 1067 to pertain to the implementation or use of the technology described 1068 in this document or the extent to which any license under such 1069 rights might or might not be available; nor does it represent that 1070 it has made any independent effort to identify any such rights. 1071 Information on the procedures with respect to rights in RFC 1072 documents can be found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use 1077 of such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository 1079 at http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. Please address the information to the IETF at 1085 ietf-ipr@ietf.org. 1087 Acknowledgement 1089 Funding for the RFC Editor function is provided by the IETF 1090 Administrative Support Activity (IASA).