idnits 2.17.1 draft-ietf-ippm-twamp-07.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 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1081. 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 777 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 (May 13, 2008) is 5826 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 973 looks like a reference -- Missing reference section? 'RFC2681' on line 977 looks like a reference -- Missing reference section? 'RFC2119' on line 981 looks like a reference -- Missing reference section? 'RFC2474' on line 984 looks like a reference -- Missing reference section? 'RFC2434' on line 989 looks like a reference -- Missing reference section? '0-15' on line 885 looks like a reference -- Missing reference section? 'RFC3692' on line 995 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: Nov 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 May 13, 2008 13 A Two-way Active Measurement Protocol (TWAMP) 14 draft-ietf-ippm-twamp-07 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 repsponds 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 acknowleges. 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, AND no packet associated 270 with any test sessions started by that control connection have been 271 received for SERVWAIT seconds. The default value of SERVWAIT SHALL 272 be 900 seconds, and this waiting time MAY be configurable. This 273 time-out allows a Server to free-up resources in case of failure. 275 3.2 Integrity Protection 277 Integrity protection of TWAMP follows the same procedure defined in 278 section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers 279 everything sent in a given direction between the previous HMAC (but 280 not including it) and up to the beginning of the new HMAC. This 281 way, once encryption is set up, each bit of the TWAMP-Control 282 connection is authenticated by an HMAC exactly once. 284 Note that the Server-Start message (sent by a Server during the 285 initial control connection exchanges) does not terminate with an 286 HMAC field. Therefore, the HMAC in the first Accept-Session message 287 also covers the Server-Start message and includes the Start-Time 288 field in the HMAC calculation. 290 3.3 Value of the Accept Fields 292 Accept values used in TWAMP are the same as the values defined in 293 section 3.3 of OWAMP [RFC4656]. 295 3.4 TWAMP Control Commands 297 TWAMP control commands conform to the rules defined in section 3.4 298 of OWAMP [RFC4656] 300 The following commands are available for the Control-client: 301 Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server 302 can send specific messages in response to the commands it receives 303 (as described in the sections that follow). 305 Note that the OWAMP Request-Session command is replaced by the 306 TWAMP Request-TW-Session command, and the Fetch-Session command 307 does not appear in TWAMP. 309 3.5 Creating Test Sessions 311 Test sessions creation follows the same procedure as defined in 312 section 3.5 of OWAMP [RFC4656]. 314 In TWAMP, the first octet is referred to as the Command Number, and 315 the Command Number is a recognized extension mechanism. Readers are 316 encouraged to consult the TWAMP-Control Command Number Registry to 317 determine if there have been additional values assigned. 319 The Command Number value of 5 indicates a Request-TW-Session 320 Command, and the Server MUST interpret this command as a request 321 for a two-way test session using the TWAMP-Test protocol. 323 If a TWAMP Server receives an unexpected command number, it MUST 324 respond with the Accept field set to 3 (meaning "Some aspect of 325 request is not supported") in the Accept-Session message. Command 326 numbers that are Forbidden (and possibly numbers that are Reserved) 327 are unexpected. 329 In OWAMP, the Conf-Sender field is set to 1 when the 330 Request-Session message describes a task where the Server will 331 configure a one-way test packet sender. Likewise, the 332 Conf-Receiver field is set to 1 when the message describes the 333 configuration for a Session-Receiver. In TWAMP, both endpoints 334 perform in these roles, with the Session-Sender first sending and 335 then receiving test packets. The Session-Reflector first receives 336 the test packets, and returns each test packet to the 337 Session-Sender as fast as possible. 339 Both Conf-Sender field and Conf-Receiver field MUST be set to 0 340 since the Session-Reflector will both receive and send packets, and 341 the roles are established according to which host initiates the TCP 342 connection for control. The server MUST interpret any non-zero 343 value as an improperly formatted command, and MUST respond with the 344 Accept field set to 3 (meaning "Some aspect of request is not 345 supported") in the Accept-Session message. 347 The Session-Reflector in TWAMP does not process incoming test 348 packets for performance metrics and consequently does not need to 349 know the number of incoming packets and their timing schedule. 350 Consequently the Number of Scheduled Slots and Number of Packets 351 MUST be set to 0. 353 The Sender Port is the UDP port from which TWAMP-Test packets will 354 be sent and the port to which TWAMP-Test packets will be sent by 355 the Session-Reflector (Session-Sender will use the same UDP port to 356 send and receive packets). Receiver Port is the desired UDP port 357 to which TWAMP test packets will be sent by the Session-Sender (the 358 port where the Session-Reflector is asked to receive test packets). 359 Receiver Port is also the UDP port from which TWAMP test packets 360 will be sent by the Session-Reflector (Session-Reflector will use 361 the same UDP port to send and receive packets). 363 The Sender Address and Receiver Address fields contain, 364 respectively, the sender and receiver addresses of the endpoints of 365 the Internet path over which a TWAMP test session is requested. 366 They MAY be set to 0, in which case the IP addresses used for the 367 Control-Client to Server TWAMP-Control Message exchange MUST be 368 used in the test packets. 370 The Session Identifier (SID) is as defined in OWAMP [RFC4656]. 371 Since the SID is always generated by the receiving side, the Server 372 determines the SID, and the SID in the Request-TW-Session message 373 MUST be set to 0. 375 The Start Time is as as defined in OWAMP [RFC4656]. 377 The Timeout is interpreted differently from the definition in OWAMP 378 [RFC4656]. In TWAMP, Timeout is the interval that the 379 Session-Reflector MUST wait after receiving a Stop-Sessions 380 message. In case there are test packets still in transit, the 381 Session Reflector MUST reflect them if they arrive within the 382 timeout interval following the reception of the Stop-Sessions 383 message. The Session-Reflector MUST NOT reflect packets that are 384 received beyond the timeout. 386 Type-P descriptor is as defined in OWAMP [RFC4656]. The only 387 capability of this field is to set the Differentiated Services Code 388 Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST 389 be used in test packets reflected by the Session-Reflector. 391 Since there are no Schedule Slot Descriptions, the Request-TW- 392 Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash 393 Message Authentication Code) fields. This completes one logical 394 message, referred to as the Request-TW-Session Command. 396 The Session-Reflector MUST respond to each Request-TW-Session 397 Command with an Accept-Message as defined in OWAMP [RFC4656]. When 398 the Accept Field = 0, the Port field confirms (repeats) the port to 399 which TWAMP test packets are sent by the Session-Sender toward the 400 Session-Reflector. In other words, the Port field indicates the 401 port number where the Session-Reflector expects to receive packets 402 from the Session-Sender. 404 When the requested Receiver Port is not available (e.g., port in 405 use), the Server at the Session-Reflector MAY suggest an alternate 406 and available port for this session in the Port Field. The 407 Session-Sender either accepts the alternate port, or composes a new 408 Session-Request message with suitable parameters. Otherwise, the 409 Server at the Session-Reflector uses the Accept Field to convey 410 other forms of session rejection or failure and MUST NOT suggest an 411 alternate port. In this case the Port Field MUST be set to zero. 413 3.6 Send Schedules 415 The Send Schedule for test packets defined in section 3.6 of OWAMP 416 [RFC4656] is not used in TWAMP. The Control-Client and 417 Session-Sender MAY autonomously decide the Send Schedule. The 418 Session-Reflector SHOULD return each test packet to the 419 Session-Sender as quickly as possible. 421 3.7 Starting Test Sessions 423 The procedure and guidelines for Starting test sessions is the same 424 as defined in section 3.7 of OWAMP [RFC4656]. 426 3.8 Stop-Sessions 428 The procedure and guidelines for Stopping test sessions is the same 429 as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions 430 command can only be issued by the Control-Client. The message MUST 431 NOT contain any session description records or skip ranges. The 432 message is terminated with a single block HMAC, to complete the 433 Stop-Sessions Command. Since the TWAMP Stop-Sessions command does 434 not convey SIDs, it applies to all sessions previously requested 435 and started with a Start-Sessions command. 437 Thus, the TWAMP Stop-Sessions command is constructed as follows: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | 3 | Accept | MBZ | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Number of Sessions | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | MBZ (8 octets) | 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | HMAC (16 octets) | 451 | | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 3.9 Fetch-Session 457 The purpose of TWAMP is measurement of two-way metrics. Two-way 458 measurement methods do not require packet level data to be 459 collected by the Session-Reflector (such as sequence number, 460 timestamp, and TTL) because this data is communicated in the 461 "reflected" test packets. As such the protocol does not require 462 the retrieval of packet level data from the Server and the OWAMP 463 Fetch-Session command is not used in TWAMP. 465 4. TWAMP Test 467 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 468 protocol with the exception that the Session-Reflector transmits 469 test packets to the Session-Sender in response to each test packet 470 it receives. TWAMP defines two different test packet formats, one 471 for packets transmitted by the Session-Sender and one for packets 472 transmitted by the Session-Reflector. As with OWAMP [RFC4656] test 473 protocol there are three modes: unauthenticated, authenticated, and 474 encrypted. 476 4.1 Sender Behavior 478 The sender behavior is determined by the configuration of the 479 Session-Sender and is not defined in this standard. Further, the 480 Session-Reflector does not need to know the Session-Sender 481 behaviour to the degree of detail as needed in OWAMP [RFC4656]. 482 Additionally the Session-Sender collects and records the necessary 483 information provided from the packets transmitted by the 484 Session-Reflector for measuring two-way metrics. The information 485 recording based on the received packet by the Session-Sender is 486 implementation dependent. 488 4.1.1 Packet Timings 490 Since the Send Schedule is not communicated to the 491 Session-Reflector, there is no need for a standardized computation 492 of packet timing. 494 Regardless of any scheduling delays, each packet that is actually 495 sent MUST have the best possible approximation of its real time of 496 departure as its timestamp (in the packet). 498 4.1.2 Packet Format and Content 500 The Session-Sender packet format and content follow the same 501 procedure and guidelines as defined in section 4.1.2 of OWAMP 502 [RFC4656] (with the exception of the reference to the Send 503 Schedule). 505 4.2 Reflector Behavior 507 TWAMP requires the Session-Reflector to transmit a packet to the 508 Session-Sender in response to each packet it receives. 510 As packets are received the Session-Reflector will, 512 - Timestamp the received packet. Each packet that is actually 513 received MUST have the best possible approximation of its real 514 time of arrival entered as its timestamp (in the packet). 516 - In authenticated or encrypted mode, decrypt the appropriate 517 sections of the packet body (first block (16 octets) for 518 authenticated, 96 octets for encrypted), and then check 519 integrity of sections covered by the HMAC. 521 - Copy the packet sequence number into the corresponding reflected 522 packet to the Session-Sender. 524 - Sender TTL value is extracted from the TTL/Hop Limit value of 525 received packets. Session-Reflector Implementations SHOULD 526 fetch the TTL/Hop Limit value from the IP header of the packet, 527 replacing the value of 255 set by the Session-Sender. If an 528 implementation does not fetch the actual TTL value (the only 529 good reason not to do so is an inability to access the TTL 530 field of arriving packets), it MUST set the Sender TTL value as 531 255. 533 - In authenticated and encrypted modes, the HMAC MUST be 534 calculated first, then the appropriate portion of the packet 535 body is encrypted. 537 - Transmit a test packet to the Session-Sender in response to 538 every received packet. The response MUST be generated as 539 immediately as possible. The format and content of the test 540 packet is defined in section 4.2.1. Prior to the transmission 541 of the test packet, the Session-Reflector MUST enter the best 542 possible approximation of its actual sending time of as its 543 Timestamp (in the packet). This permits the determination of 544 the elapsed time between the reception of the packet and its 545 transmission. 547 - Packets not received within the Timeout (following the Stop- 548 Session command) MUST be ignored by the 549 Reflector. The Session-Reflector MUST NOT generate a test 550 packet to the Session-Sender for packets that are ignored. 552 The possibility exists for Session-Sender failure during a session, 553 or the path between the Session-Sender and Session-Reflector may 554 fail while a test session is in-progress. The Session-Reflector MAY 555 discontinue any session which has been Started when no packet 556 associated with that session has been received for REFWAIT seconds. 557 The default value of REFWAIT SHALL be 900 seconds, and this waiting 558 time MAY be configurable. This time-out allows a Session-Reflector 559 to free-up resources in case of failure. 561 4.2.1 TWAMP-Test Packet Format and Content 563 The Session-Reflector MUST transmit a packet to the Session-Sender 564 in response to each packet received. The Session-Reflector SHOULD 565 transmit the packets as immediately as possible. The 566 Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) 567 in the UDP packet to 255. 569 The test packet will have the necessary information for calculating 570 two-way metrics by the Session-Sender. The format of the test 571 packet depends on the mode being used. The various formats of the 572 packet are presented below. 574 For unauthenticated mode: 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Sequence Number | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Timestamp | 582 | | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Error Estimate | MBZ | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Receive Timestamp | 587 | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Sender Sequence Number | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Sender Timestamp | 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Sender Error Estimate | MBZ | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Sender TTL | | 597 +-+-+-+-+-+-+-+-+ + 598 | | 599 . . 600 . Packet Padding . 601 . . 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 For authenticated and encrypted modes: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Sequence Number | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | MBZ (12 octets) | 612 | | 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Timestamp | 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Error Estimate | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 620 | MBZ (6 octets) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Receive Timestamp | 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | MBZ (8 octets) | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Sender Sequence Number | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | MBZ (12 octets) | 631 | | 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Sender Timestamp | 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Sender Error Estimate | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 639 | MBZ (6 octets) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Sender TTL | | 642 +-+-+-+-+-+-+-+-+ + 643 | | 644 | | 645 | MBZ (15 octets) | 646 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 647 | HMAC (16 octets) | 648 | | 649 | | 650 | | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 652 | | 653 . . 654 . Packet Padding . 655 . . 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Note that all Timestamps have the same format as OWAMP [RFC4656] as 660 follows: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Integer part of seconds | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Fractional part of seconds | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Sequence Number is the sequence number of the test packet according 671 to its transmit order. It starts with zero and is incremented by 672 one for each subsequent packet. The Sequence Number generated by 673 the Session-Reflector is independent from the sequence number of 674 the arriving packets. 676 Timestamp and Error Estimate are the Session-Reflector's transmit 677 timestamp and error estimate for the reflected test packet, 678 respectively. The format of all timestamp and error estimate 679 fields follow the definition and formats defined by OWAMP[RFC4656]. 681 Sender Timestamp and Sender Error Estimate are exact copies of the 682 timestamp and error estimate from the Session-Sender test packet 683 that corresponds to this test packet. 685 Sender TTL is 255 when transmitted by the Session Sender. Sender 686 TTL is set to the Time To Live (or Hop Count) value of the received 687 packet from the IP packet header when transmitted by the Session 688 Reflector. 690 Receive Timestamp is the time the test packet was received by the 691 reflector. The difference between Timestamp and Receive Timestamp 692 is the amount of time the packet was in transition in the 693 Session-Reflector. The Error Estimate associated with the 694 Timestamp field also applies to the Receive Timestamp. 696 Sender Sequence Number is a copy of the Sequence Number of the 697 packet transmitted by the Session-Sender that caused the 698 Session-Reflector to generate and send this test packet. 700 Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in 701 authenticated and encrypted modes. The encryption operation of 702 Session-Sender packet follow the same rules of Session-Sender 703 packets as defined in OWAMP [RFC4656]. 705 The minimum data segment length is, therefore, 41 octets in 706 unauthenticated mode, and 104 octets in both authenticated mode and 707 encrypted modes (with the implication that the later two modes will 708 not fit in a single ATM cell). 710 The Session-Reflector TWAMP-Test packet layout is the same in 711 authenticated and encrypted modes. The encryption operations are, 712 however, different. The difference is that in encrypted mode both 713 the sequence numbers and timestamps are encrypted to provide 714 maximum data integrity protection while in authenticated mode the 715 sequence numbers are encrypted and the timestamps are sent in clear 716 text. Sending the timestamp in clear text in authenticated mode 717 allows one to reduce the time between when a timestamp is obtained 718 by a reflector and when the packet is reflected out. In encrypted 719 mode, both the sender and reflector have to fetch the timestamp, 720 encrypt it, and send it; in authenticated mode, the middle step is 721 removed, potentially improving accuracy (the sequence number can be 722 encrypted before the timestamp is fetched). Authenticated mode 723 permits the timestamp to be fetched after a portion of the packet 724 is encrypted. Thus, the main differences between authenticated mode 725 and encrypted mode are the portions of the test packets that are 726 covered by HMAC and encrypted. 728 In authenticated mode, the first block (16 octets) of each packet 729 is encrypted using AES Electronic Cookbook (ECB) mode. 731 Obtaining the key, encryption method, and packet padding follows 732 the same procedure as OWAMP as described below. 733 Similarly to each TWAMP-Control session, each TWAMP-Test session 734 has two keys: an AES Session-key and an HMAC Session-key. However, 735 there is a difference in how the keys are obtained: in the case of 736 TWAMP-Control, the keys are generated by the client and 737 communicated (as part of the Token) during connection setup as part 738 of Set-Up-Response message; in the case of TWAMP-Test, described 739 here, the keys are derived from the TWAMP-Control keys and the SID. 741 The TWAMP-Test AES Session-key is obtained as follows: the 742 TWAMP-Control AES Session-key (the same AES Session-key as is used 743 for the corresponding TWAMP-Control session, where it is used in a 744 different chaining mode) is encrypted, using AES, with the 16-octet 745 session identifier (SID) as the key; this is a single-block ECB 746 encryption; its result is the TWAMP-Test AES Session-key to use in 747 encrypting (and decrypting) the packets of the particular 748 TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, 749 TWAMP-Control AES Session-key, and the SID are comprised of 16 750 octets. 752 The TWAMP-Test HMAC Session-key is obtained as follows: the 753 TWAMP-Control HMAC Session-key (the same HMAC Session-key as is 754 used for the corresponding TWAMP-Control session) is encrypted, 755 using AES, with the 16-octet session identifier (SID) as the key; 756 this is a two-block CBC encryption, always performed with IV=0; its 757 result is the TWAMP-Test HMAC Session-key to use in authenticating 758 the packets of the particular TWAMP-Test session. Note that all of 759 TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are 760 comprised of 32 octets, while the SID is 16 octets. 762 ECB mode used for encrypting the first block of TWAMP-Test packets 763 in authenticated mode does not involve any actual chaining; this 764 way, lost, duplicated, or reordered packets do not cause problems 765 with deciphering any packet in an TWAMP-Test session. 767 In encrypted mode, the first six blocks (96octets) are encrypted 768 using AES CBC mode. The AES Session-key to use is obtained in the 769 same way as the key for authenticated mode. Each TWAMP-Test packet 770 is encrypted as a separate stream, with just one chaining 771 operation; chaining does not span multiple packets so that lost, 772 duplicated, or reordered packets do not cause problems. The 773 initialization vector for the CBC encryption is a value with all 774 bits equal to zero. 776 Implementation note: Naturally, the key schedule for each 777 TWAMP-Test session MUST be set up at most once per session, not 778 once per packet. 780 HMAC in TWAMP-Test only covers the part of the packet that is also 781 encrypted. So, in authenticated mode, HMAC covers the first block 782 (16 octets); in encrypted mode, HMAC covers the first six blocks 783 (96 octets). In TWAMP-Test HMAC is not encrypted (note that this 784 is different from TWAMP-Control, where encryption in stream mode is 785 used, so everything including the HMAC blocks ends up being 786 encrypted). 788 In unauthenticated mode, no encryption or authentication is 789 applied. 791 Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be 792 generated independently of any other pseudo-random numbers 793 mentioned in this document). However, implementations MUST provide 794 a configuration parameter, an option, or a different means of 795 making Packet Padding consist of all zeros. 797 5. Implementers Guide 799 This section serves as guidance to implementers of TWAMP. The 800 example architecture presented here is not a requirement. Similar 801 to OWAMP [RFC4656], TWAMP is designed with enough flexibility to 802 allow different architectures that suit multiple system 803 requirements. 805 In this example the roles of Control-Client and Session-Sender are 806 implemented in one host referred to as the controller and the roles 807 of Server and Session-Reflector are implemented in another host 808 referred to as the responder. 810 controller responder 811 +-----------------+ +-------------------+ 812 | Control-Client |<--TWAMP-Control-->| Server | 813 | | | | 814 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 815 +-----------------+ +-------------------+ 817 This example provides an architecture that supports the full TWAMP 818 standard. The controller establishes the test session with the 819 responder through the TWAMP-Control protocol. After the session is 820 established the controller transmits test packets to the responder. 821 The responder follows the Session-Reflector behavior of TWAMP as 822 described in section 4.2. 824 Appendix I provides an example for purely informational purposes. 825 It suggests an incremental path to adopting TWAMP, by implementing 826 the TWAMP-Test protocol first. 828 6. Security Considerations 830 Fundamentally TWAMP and OWAMP use the same protocol for 831 establishment of Control and Test procedures. The main difference 832 between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP 833 vs. the Session-Receiver behavior in OWAMP. This difference in 834 behavior does not introduce any known security vulnerabilities that 835 are not already addressed by the security features of OWAMP. The 836 entire security considerations of OWAMP [RFC4656] applies to TWAMP. 838 7. Acknowledgements 840 We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, 841 Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and 842 Murtaza Chiba for their comments, suggestions, reviews, helpful 843 discussion and proof-reading. 845 8. IANA Considerations 847 IANA has allocated a well-known TCP port number (861) for the 848 OWAMP-Control part of the OWAMP [RFC4656] protocol. 849 ... 850 owamp-control 861/tcp OWAMP-Control 851 owamp-control 861/udp OWAMP-Control 852 # [RFC4656] 853 # 862-872 Unassigned 855 IANA is requested to allocate a well-known TCP/UDP port number for 856 the TWAMP-Control protocol. It would be ideal if the port number 857 assignment was adjacent to the OWAMP assignment. The recommended 858 Keyword for this entry is "twamp-control" and the Description is 859 "Two-way Active Measurement Protocol (TWAMP) Control". 861 During final editing, port N in section 3.1 should be replaced with 862 the assigned port number. 864 Since TWAMP adds an additional Control command to the OWAMP-Control 865 specification, and describes behavior when this control command is 866 used, this memo requests creation an IANA registry for the TWAMP 867 Command Number field. The field is not explicitly named in 868 [RFC4656] but is called out for each command. This field is a 869 recognized extension mechanism for TWAMP. 871 8.1 Registry Specification 873 IANA will create an TWAMP-Control Command Number registry. TWAMP- 874 Control commands are specified by the first octet in OWAMP-Control 875 messages as shown in section 3.5 of [RFC4656], and modified by this 876 document. Thus this registry may contain sixteen possible values. 878 8.2 Registry Management 880 Because the registry may only contain sixteen values, and because 881 OWAMP and TWAMP are IETF protocols, this registry must only be 882 updated by "IETF Consensus" as specified in [RFC2434] -- an RFC 883 documenting the use that is approved by the IESG. We expect that 884 new values will be assigned as monotonically increasing integers in 885 the range [0-15], unless there is a good reason to do otherwise. 887 8.3 Experimental Numbers 889 [RFC3692] recommends allocating an appropriate number of values for 890 experimentation and testing. It is not clear to the authors 891 exactly how many numbers might be useful in this space, nor if it 892 would be useful that they were easily distinguishable or at the 893 "high end" of the number range. Two might be useful, say one for 894 session control, and one for session fetch. On the other hand, a 895 single number would allow for unlimited extension, because the 896 format of the rest of the message could be tailored, with 897 allocation of other numbers done once usefulness has been proven. 898 Thus, this document will allocate one number, the next sequential 899 number 6, as designated for experimentation and testing. 901 8.4 Initial Registry Contents 903 TWAMP-Control Command Number Registry 905 Value Description Semantics Definition 906 0 Reserved 907 1 Forbidden 908 2 Start-Sessions RFC4656, Section 3.7 909 3 Stop-Sessions RFC4656, Section 3.8 910 4 Reserved 911 5 Request-TW-Session this document, Section 3.5 912 6 Experimentation undefined, see Section 8.3. 914 9. Internationalization Considerations 916 The protocol does not carry any information in a natural language, 917 with the possible exception of the KeyID in TWAMP-Control, which is 918 encoded in UTF-8. 920 10. APPENDIX I - TWAMP Light (Informative) 922 In this example the roles of Control-Client, Server, and 923 Session-Sender are implemented in one host referred to as the 924 controller and the role of Session-Reflector is implemented in 925 another host referred to as the responder. 927 controller responder 928 +-----------------+ +-------------------+ 929 | Server |<----------------->| | 930 | Control-Client | | Session-Reflector | 931 | Session-Sender |<--TWAMP-Test----->| | 932 +-----------------+ +-------------------+ 934 This example provides a simple architecture for responders where 935 their role will be to simply act as light test points in the 936 network. The controller establishes the test session with the 937 Server through non-standard means. After the session is 938 established the controller transmits test packets to the responder. 939 The responder follows the Session-Reflector behavior of TWAMP as 940 described in section 4.2 with the following exceptions. 942 In the case of TWAMP Light, the Session-Reflector does not 943 necessarily have knowledge of the session state. IF the 944 Session-Reflector does not have knowledge of the session state, 945 THEN the Session-Reflector MUST copy the Sequence Number of the 946 received packet to the Sequence Number field of the reflected 947 packet. The controller receives the reflected test packets and 948 collects two-way metrics. This architecture allows for collection 949 of two-way metrics. 951 This example eliminates the need for the TWAMP-Control protocol and 952 assumes that the Session-Reflector is configured and communicates 953 its configuration with the Server through non-standard means. The 954 Session-Reflector simply reflects the incoming packets back to the 955 controller while copying the necessary information and generating 956 sequence number and timestamp values per section 4.2.1. 957 TWAMP Light introduces some additional security considerations. The 958 non-standard means to control the responder and establish test 959 sessions SHOULD offer the features listed below. 961 The non-standard responder control protocol SHOULD have an 962 authenticated mode of operation. The responder SHOULD be 963 configurable to accept only authenticated control sessions. 965 The non-standard responder control protocol SHOULD have a means to 966 activate the authenticated and encrypted modes of the TWAMP-Test 967 protocol. 969 11. References 971 11.1 Normative References 973 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., 974 Zekauskas, M., "A One-way Active Measurement Protocol 975 (OWAMP)", RFC 4656, October 2004. 977 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A 978 Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, 979 September 1999. 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 985 Definition of the Differentiated Services Field (DS 986 Field) in the IPv4 and IPv6 Headers", RFC 2474, 987 December 1998. 989 [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing 990 an IANA Considerations Section in RFCs, RFC 2434, 991 October 1998. 993 11.2 Informative References 995 [RFC3692] Narten, T., Assigning Experimental and Testing Numbers 996 Considered Useful, RFC 3692, January 2004. 998 Authors' Addresses 1000 Kaynam Hedayat 1001 Brix Networks 1002 285 Mill Road 1003 Chelmsford, MA 01824 1004 USA 1005 EMail: khedayat@brixnet.com 1006 URI: http://www.brixnet.com/ 1008 Roman M. Krzanowski, Ph.D. 1009 Verizon 1010 500 Westchester Ave. 1011 White Plains, NY 1012 USA 1013 EMail: roman.krzanowski@verizon.com 1014 URI: http://www.verizon.com/ 1016 Al Morton 1017 AT&T Labs 1018 Room D3 - 3C06 1019 200 Laurel Ave. South 1020 Middletown, NJ 07748 1021 USA 1022 Phone +1 732 420 1571 1023 EMail: acmorton@att.com 1024 URI: http://home.comcast.net/~acmacm/ 1026 Kiho Yum 1027 Juniper Networks 1028 1194 Mathilda Ave. 1029 Sunnyvale, CA 1030 USA 1031 EMail: kyum@juniper.net 1032 URI: http://www.juniper.com/ 1034 Jozef Z. Babiarz 1035 Nortel Networks 1036 3500 Carling Avenue 1037 Ottawa, Ont K2H 8E9 1038 Canada 1039 Email: babiarz@nortel.com 1040 URI: http://www.nortel.com/ 1042 Full Copyright Statement 1044 Copyright (C) The IETF Trust (2008). 1046 This document is subject to the rights, licenses and restrictions 1047 contained in BCP 78, and except as set forth therein, the authors 1048 retain all their rights. 1050 This document and the information contained herein are provided on 1051 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1052 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1053 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1054 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1055 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1056 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1057 FOR A PARTICULAR PURPOSE. 1059 Intellectual Property 1061 The IETF takes no position regarding the validity or scope of any 1062 Intellectual Property Rights or other rights that might be claimed 1063 to pertain to the implementation or use of the technology described 1064 in this document or the extent to which any license under such 1065 rights might or might not be available; nor does it represent that 1066 it has made any independent effort to identify any such rights. 1067 Information on the procedures with respect to rights in RFC 1068 documents can be found in BCP 78 and BCP 79. 1070 Copies of IPR disclosures made to the IETF Secretariat and any 1071 assurances of licenses to be made available, or the result of an 1072 attempt made to obtain a general license or permission for the use 1073 of such proprietary rights by implementers or users of this 1074 specification can be obtained from the IETF on-line IPR repository 1075 at http://www.ietf.org/ipr. 1077 The IETF invites any interested party to bring to its attention any 1078 copyrights, patents or patent applications, or other proprietary 1079 rights that may cover technology that may be required to implement 1080 this standard. Please address the information to the IETF at 1081 ietf-ipr@ietf.org. 1083 Acknowledgement 1085 Funding for the RFC Editor function is provided by the IETF 1086 Administrative Support Activity (IASA).