idnits 2.17.1 draft-ietf-rserpool-common-param-14.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 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1053. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2007) is 5976 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-17 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-17 == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-07 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental Q. Xie 5 Expires: May 20, 2008 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 November 17, 2007 12 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 13 Redundancy Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-14.txt 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 Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 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 This Internet-Draft will expire on May 20, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document details the parameters of the Aggregate Server Access 48 Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) 49 protocols defined within the Reliable Server Pooling (RSerPool) 50 architecture. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Parameters in General . . . . . . . . . . . . . . . . . . . . 4 57 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . . . 5 58 3.1. IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 7 59 3.2. IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 60 3.3. DCCP Transport Parameter . . . . . . . . . . . . . . . . . 7 61 3.4. SCTP Transport Parameter . . . . . . . . . . . . . . . . . 8 62 3.5. TCP Transport Parameter . . . . . . . . . . . . . . . . . 9 63 3.6. UDP Transport Parameter . . . . . . . . . . . . . . . . . 10 64 3.7. UDP-Lite Transport Parameter . . . . . . . . . . . . . . . 11 65 3.8. Pool Member Selection Policy Parameter . . . . . . . . . . 11 66 3.9. Pool Handle Parameter . . . . . . . . . . . . . . . . . . 12 67 3.10. Pool Element Parameter . . . . . . . . . . . . . . . . . . 13 68 3.11. Server Information Parameter . . . . . . . . . . . . . . . 14 69 3.12. Operation Error Parameter . . . . . . . . . . . . . . . . 14 70 3.12.1. Unspecified Error . . . . . . . . . . . . . . . . . . 16 71 3.12.2. Unrecognized Parameter Error . . . . . . . . . . . . 17 72 3.12.3. Unrecognized Message Error . . . . . . . . . . . . . 17 73 3.12.4. Invalid Values Error . . . . . . . . . . . . . . . . 17 74 3.12.5. Non-unique PE Identifier Error . . . . . . . . . . . 17 75 3.12.6. Inconsistent Pool Policy Error . . . . . . . . . . . 17 76 3.12.7. Lack of Resources Error . . . . . . . . . . . . . . . 17 77 3.12.8. Inconsistent Transport Type Error . . . . . . . . . . 17 78 3.12.9. Inconsistent Data/Control Configuration Error . . . . 18 79 3.12.10. Rejected due to security considerations . . . . . . . 18 80 3.12.11. Unknown Poor Handle Error . . . . . . . . . . . . . . 18 81 3.13. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 18 82 3.14. PE Identifier Parameter . . . . . . . . . . . . . . . . . 18 83 3.15. PE Checksum Parameter . . . . . . . . . . . . . . . . . . 19 84 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 20 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 5.1. A New Table for RSerPool Parameter Types . . . . . . . . . 22 87 5.2. A New Table for RSerPool Error Causes . . . . . . . . . . 23 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 7. Normative References . . . . . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 91 Intellectual Property and Copyright Statements . . . . . . . . . . 28 93 1. Introduction 95 Aggregate Server Access Protocol (ASAP) [I-D.ietf-rserpool-asap] in 96 conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) 97 [I-D.ietf-rserpool-enrp] provides a high availability data transfer 98 mechanism over IP networks. 100 Both protocols work together and so share many common parameters used 101 in message formats. This document details the common message 102 parameters shared between the two protocols. This document provides 103 parameter formats only, for procedures and message composition please 104 refer to the respective [I-D.ietf-rserpool-asap] and 105 [I-D.ietf-rserpool-enrp] documents. 107 1.1. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Parameters in General 115 All parameters described below MUST be in Network Byte Order (a.k.a. 116 Big Endian, i.e., the most significant byte first) during 117 transmission. 119 Please note that messages in both ENRP and ASAP are often composed of 120 multiple parameters. These parameters may also be nested. In such a 121 case a nested parameter will include the length of the padding 122 between the nested parameters but not the last padding. 124 3. ENRP-ASAP Common Parameters 126 Parameters are defined in the following Type-Length-Value (TLV) 127 format: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Parameter Type | Parameter Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 : : 135 : Parameter Value : 136 : : 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Parameter Type: 16 bits (unsigned integer) 140 The Type field is a 16 bit identifier of the type of parameter. 141 It takes a value of 0 to 65534. 142 The value of 65535 is reserved for IETF-defined extensions. 143 Values other than those defined in specific ENRP parameter 144 description are reserved by IETF. (Additional types, when needed, 145 will be defined in the future through appropriate IETF/IANA 146 procedures.) 147 The Parameter Types are encoded such that the highest-order two 148 bits specify the action that must be taken if the processing 149 endpoint does not recognize the Parameter Type. 151 00 Stop processing this ENRP or ASAP message and discard it, do 152 not process any further parameters within it. 154 01 Stop processing this ENRP or ASAP message and discard it, do 155 not process any further parameters within it, and report the 156 unrecognized parameter in an 'Unrecognized Parameter' error 157 (see Section 3.12). 159 10 Skip this parameter and continue processing. 161 11 Skip this parameter and continue processing, but report the 162 unrecognized parameter in an 'Unrecognized Parameter' error 163 (see Section 3.12). 165 The values of parameter types are defined as follows: 167 +--------+------------------------------+ 168 | Value | Parameter Type | 169 +--------+------------------------------+ 170 | 0x0 | (reserved by IETF) | 171 | | | 172 | 0x1 | IPv4 Address | 173 | | | 174 | 0x2 | IPv6 Address | 175 | | | 176 | 0x3 | DCCP Transport | 177 | | | 178 | 0x4 | SCTP Transport | 179 | | | 180 | 0x5 | TCP Transport | 181 | | | 182 | 0x6 | UDP Transport | 183 | | | 184 | 0x7 | UDP-Lite | 185 | | | 186 | 0x8 | Pool Member Selection Policy | 187 | | | 188 | 0x9 | Pool Handle | 189 | | | 190 | 0xa | Pool Element | 191 | | | 192 | 0xb | Server Information | 193 | | | 194 | 0xc | Operation Error | 195 | | | 196 | 0xd | Cookie | 197 | | | 198 | 0xe | PE Identifier | 199 | | | 200 | 0xf | PE Checksum | 201 | | | 202 | others | (reserved by IETF) | 203 +--------+------------------------------+ 205 Table 1 207 Parameter Length: 16 bits (unsigned integer) 208 The Parameter Length field contains the size of the parameter in 209 bytes, including the Parameter Type, Parameter Length, and 210 Parameter Value fields. Thus, a parameter with a zero-length 211 Parameter Value field would have a Length field of 4. 212 The total length of a parameter (including Type, Parameter Length 213 and Value fields) MUST be a multiple of 4 bytes. If the length of 214 the parameter is not a multiple of 4 bytes, the sender MUST pad 215 the parameter at the end (i.e., after the Parameter Value field) 216 with all zero bytes. The length of this padding is not included 217 in the Parameter Length field. A sender MUST NOT pad with more 218 than 3 bytes. The receiver MUST ignore the padding bytes. 220 Parameter Value: variable-length. 221 The Parameter Value field contains the actual information to be 222 transferred in the parameter. 224 3.1. IPv4 Address Parameter 226 This parameter defines a TLV that carries an IPv4 address. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type = 0x1 | Length = 0x8 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | IPv4 Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 IPv4 Address: 32 bits (unsigned integer) 237 Contains an IPv4 address. It is binary encoded. 239 3.2. IPv6 Address Parameter 241 This parameter defines a TLV that carries an IPv6 address. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type = 0x2 | Length = 0x14 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 | IPv6 Address | 250 | | 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 IPv6 Address: 128 bit (unsigned integer) 255 Contains an IPv6 address. It is binary encoded. 257 3.3. DCCP Transport Parameter 259 This parameter defines a TLV that describes a user transport using 260 DCCP protocol. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type = 0x3 | Length = variable | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | DCCP port | (reserved) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 : IPv4 or IPv6 Address : 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Length: 16 bits (unsigned integer) 273 Indicates the entire length of the parameter in number of octets, 274 including the Type, Length, DCCP port, reserved fields, and IP 275 address parameter. 277 DCCP port: 16 bits (unsigned integer) 278 The DCCP port number signed to this DCCP user transport. 280 IPv4 or IPv6 Address 281 Indicates an IPv4 or IPv6 address parameter (as defined above in 282 Section 3.1 and Section 3.2) assigned to this DCCP user transport. 283 Unlike in an SCTP transport parameter, only one IP address 284 parameter can be present in a DCCP transport parameter. 286 Note: A DCCP port MUST NOT be used for control information. For this 287 reason, no Transport Use field is provided. DCCP MUST always be 288 treated as a "Data Only" type transport use. 290 3.4. SCTP Transport Parameter 292 This parameter defines a TLV that describes a user transport using 293 SCTP protocol. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type = 0x4 | Length = variable | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | SCTP port | Transport Use | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 : IPv4 or IPv6 Address #1 : 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 : : 305 : ... : 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : IPv4 or IPv6 Address #n : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Length: 16 bits (unsigned integer) 310 Indicates the entire length of the parameter in number of octets, 311 including the Type, Length, SCTP port, reserved fields, and all IP 312 address parameters present. 314 SCTP port: 16 bits (unsigned integer) 315 The SCTP port number signed to this SCTP user transport. 317 Transport use: 16 bits (unsigned integer) 318 This field represents how the pool element intends this transport 319 address to be used. The field MUST be populated with one of the 320 following values: 322 +-------------------+--------+ 323 | Type | Value | 324 +-------------------+--------+ 325 | DATA ONLY | 0x0000 | 326 | | | 327 | DATA plus CONTROL | 0x0001 | 328 +-------------------+--------+ 330 IPv4 or IPv6 Address #1 - #n 331 Each indicates an IPv4 or IPv6 address parameter (as defined above 332 in Section 3.1 and Section 3.2) assigned to this SCTP user 333 transport. An SCTP Transport parameter may have a mixed list of 334 IPv4 and IPv6 addresses and at least one IP address parameter MUST 335 be present in an SCTP transport parameter. 337 3.5. TCP Transport Parameter 339 This parameter defines a TLV that describes a user transport using 340 TCP protocol. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = 0x5 | Length = variable | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | TCP port | (reserved) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 : IPv4 or IPv6 Address : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Length: 16 bits (unsigned integer) 353 Indicates the entire length of the parameter in number of octets, 354 including the Type, Length, TCP port, reserved fields, and IP 355 address parameter. 357 TCP port: 16 bits (unsigned integer) 358 The TCP port number signed to this TCP user transport. 360 IPv4 or IPv6 Address 361 Indicates an IPv4 or IPv6 address parameter (as defined above in 362 Section 3.1 and Section 3.2) assigned to this TCP user transport. 363 Unlike in an SCTP transport parameter, only one IP address 364 parameter can be present in a TCP transport parameter. 366 Note: A TCP port MUST NOT be used for control information. For this 367 reason, no Transport Use field is provided. TCP MUST always be 368 treated as a "Data Only" type transport use. 370 3.6. UDP Transport Parameter 372 This parameter defines a TLV that describes a user transport using 373 UDP protocol. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type = 0x6 | Length = variable | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | UDP port | (reserved) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 : IPv4 or IPv6 Address : 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Length: 16 bits (unsigned integer) 386 Indicates the entire length of the parameter in number of octets, 387 including the Type, Length, UDP port, reserved fields, and IP 388 address parameter. 390 UDP port: 16 bits (unsigned integer) 391 The UDP port number signed to this UDP user transport. 393 IPv4 or IPv6 Address 394 Indicates an IPv4 or IPv6 address parameter (as defined above in 395 Section 3.1 and Section 3.2) assigned to this UDP user transport. 396 Unlike in an SCTP transport parameter, only one IP address 397 parameter can be present in a UDP transport parameter. 399 Note: A UDP port MUST NOT be used for control information. For this 400 reason, no Transport Use field is provided. UDP MUST always be 401 treated as a "Data Only" type transport use. 403 3.7. UDP-Lite Transport Parameter 405 This parameter defines a TLV that describes a user transport using 406 UDP-Lite protocol. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type = 0x7 | Length = variable | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | UDP-Lite port | (reserved) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 : IPv4 or IPv6 Address : 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Length: 16 bits (unsigned integer) 419 Indicates the entire length of the parameter in number of octets, 420 including the Type, Length, UDP-Lite port, reserved fields, and IP 421 address parameter. 423 UDP port: 16 bits (unsigned integer) 424 The UDP-Lite port number signed to this UDP-Lite user transport. 426 IPv4 or IPv6 Address 427 Indicates an IPv4 or IPv6 address parameter (as defined above in 428 Section 3.1 and Section 3.2) assigned to this UDP-Lite user 429 transport. Unlike in an SCTP transport parameter, only one IP 430 address parameter can be present in a UDP-Lite transport 431 parameter. 433 Note: A UDP-Lite port MUST NOT be used for control information. For 434 this reason, no Transport Use field is provided. UDP-Lite MUST 435 always be treated as a "Data Only" type transport use. 437 3.8. Pool Member Selection Policy Parameter 439 This parameter defines a pool member selection policy. RSerPool 440 supports multiple pool member selection policies and also allows 441 definition of new selection policies in the future. 443 The enforcement rules and handling procedures of all the policies are 444 defined in [I-D.ietf-rserpool-asap]. 446 All pool member selection policies, both present and future, MUST use 447 the following general parameter format: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type = 0x8 | Length = variable | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Policy Type | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Policy-specific Data | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Length: 16 bits (unsigned integer) 460 Indicates the entire length of the parameter in number of octets, 461 including the Type, Length, Policy Type, and the Policy-specific 462 Data fields. 463 Note, the Length field value will NOT include any padding at the 464 end of the parameter. 466 Policy Type: 32 bits (unsigned integer) 467 Specifies the type of selection policy. 469 Policy-specific Data: 470 The structure and fields for each presently defined policy types 471 are described in detail in [I-D.ietf-rserpool-policies]. 473 3.9. Pool Handle Parameter 475 This parameter holds a pool handle. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type = 0x9 | Length=variable | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 : : 483 : Pool Handle : 484 : : 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Length: 16 bits (unsigned integer) 488 Indicates the entire length of the parameter in number of octets, 489 including the Type, Length, and Pool Handle string. 490 Note, the value in Length field will NOT cover any padding at the 491 end of the parameter. 493 Pool Handle 494 defined as a sequence of (Length - 4) bytes. 496 3.10. Pool Element Parameter 498 This parameter is used in multiple ENRP messages to represent an ASAP 499 endpoint (i.e., a PE in a pool) and the associated information, such 500 as its transport address, selection policy, and other operational or 501 status information of the PE. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type = 0xa | Length=variable | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | PE Identifier | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Home ENRP Server Identifier | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Registration Life | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 : User Transport param : 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : Member Selection Policy param : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 : ASAP Transport param : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Length: 16 bits (unsigned integer) 522 Indicates the entire length of the parameter in number of octets, 523 including the Type, Length, PE Identifier, Registration Life, User 524 Transport, and Member Selection Policy parameters. 525 Note, the value in Length field will NOT cover any padding at the 526 end of this Pool Element parameter. 528 PE Identifier: 32 bits (unsigned integer) 529 Uniquely identifies the PE in the pool. The PE picks its 530 identifier when it starts up. 532 Home ENRP Server Identifier: 32 bits (unsigned integer) 533 Indicates the current home ENRP server of this PE. Set to all 0's 534 if the PE's home ENRP server is undetermined. 536 Registration Life: 32 bits (signed integer) 537 Indicates the life time of the registration in number of seconds. 538 A value of -1 indicates infinite life time. 540 User Transport 541 This can be either an DCCP, SCTP, TCP, UDP, or UDP-Lite type 542 transport parameter (see Section 3.3, Section 3.4, Section 3.5, 543 Section 3.6, Section 3.7). A PE MUST have one and only one User 544 Transport. 546 Member Selection Policy 547 Contains one of the defined member selection policy parameters 548 (see Section 3.8). 550 ASAP Transport 551 This indicates the ASAP transport address of the PE and MUST be an 552 SCTP type transport parameter (see Section 3.4). 554 3.11. Server Information Parameter 556 This parameter is used in ENRP to pass basic information of an ENRP 557 server. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type = 0xb | Length=variable | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Server ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 : Server Transport : 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Length: 16 bits (unsigned integer) 570 Indicates the entire length of the parameter in number of bytes. 571 Note, the value in Length field will NOT cover any padding at the 572 end of the parameter. 574 Server ID: 32 bit (unsigned integer) 575 This is the ID of the ENRP server, as defined in 576 [I-D.ietf-rserpool-enrp]. 578 Server Transport: 579 This is an SCTP Transport Parameter, as defined in Section 3.4 580 that contains the network access address(es), SCTP port number, 581 etc. of the ENRP server. 583 3.12. Operation Error Parameter 585 This parameter is used in both ENPR and ASAP for a message sender to 586 report an error(s) to a message receiver. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = 0xc | Length=variable | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 : : 594 : one or more Error Causes : 595 : : 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Length: 16 bits (unsigned integer) 599 Indicates the entire length of the parameter in number of bytes. 600 Note, the value in Length field will NOT cover any padding at the 601 end of the parameter. 603 Error causes are defined as variable-length parameters using the 604 following format: 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 | Cause Code | Cause Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 : : 612 : Cause-specific Information : 613 : : 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Cause Code: 16 bits (unsigned integer) 617 Defines the type of error condition being reported. 619 +------------------+-----------------------------------------+ 620 | Cause Code Value | Cause Code | 621 +------------------+-----------------------------------------+ 622 | 0x0 | Unspecified Error | 623 | | | 624 | 0x1 | Unrecognized Parameter | 625 | | | 626 | 0x2 | Unrecognized Message | 627 | | | 628 | 0x3 | Invalid Values | 629 | | | 630 | 0x4 | Non-unique PE Identifier | 631 | | | 632 | 0x5 | Inconsistent Pooling Policy | 633 | | | 634 | 0x6 | Lack of Resources | 635 | | | 636 | 0x7 | Inconsistent Transport Type | 637 | | | 638 | 0x8 | Inconsistent Data/Control Configuration | 639 | | | 640 | 0x9 | Unknown Poor Handle | 641 | | | 642 | 0xa | Rejected due to security considerations | 643 | | | 644 | others | reserved by IETF | 645 +------------------+-----------------------------------------+ 647 Table 2 649 Cause Length: 16 bits (unsigned integer) 650 Set to the size of the parameter in bytes, including the Cause 651 Code, Cause Length, and Cause-Specific Information fields, but not 652 including any padding at the end of this error cause TLV. 654 Cause-specific Information: variable length 655 This field carries the details of the error condition. 657 The following subsections (Section 3.12.1 - Section 3.12.9) define 658 specific error causes. 660 3.12.1. Unspecified Error 662 This error cause is used to report an unspecified error by the 663 sender. There is no cause specific information. 665 3.12.2. Unrecognized Parameter Error 667 This error cause is used to report an unrecognized parameter. The 668 unrecognized parameter TLV is included as cause specific information. 669 If a message contains multiple unrecognized parameters, multiple 670 error causes are used. 672 3.12.3. Unrecognized Message Error 674 This error cause is used to report an unrecognized message. The 675 unrecognized message TLV is included as cause specific information. 677 3.12.4. Invalid Values Error 679 This error cause is used to report one or more invalid values found 680 in a received parameter. The offending TLV that contains the invalid 681 value(s) is included as cause specific information. 683 3.12.5. Non-unique PE Identifier Error 685 This error cause is used by an ENRP server to indicate to a 686 registering PE that the PE Identifier it chooses has already been 687 used by another PE in the pool. There is no cause specific 688 information. 690 3.12.6. Inconsistent Pool Policy Error 692 This error cause is used by an ENRP server to indicate to a 693 registering PE that the Pool Policy it chooses does not match the 694 overall policy of the pool. A Pool Member Selection Policy TLV (see 695 Section 3.8) that indicates the overall pool policy is included as 696 cause specific information. 698 3.12.7. Lack of Resources Error 700 This error cause is used to indicate that the sender does not have 701 certain resources to perform a requested function. There is no cause 702 specific information. 704 3.12.8. Inconsistent Transport Type Error 706 This error cause is used by an ENRP server to indicate to a 707 registering PE that the User Transport it chooses does not match the 708 overall user transport of the pool. A Transport TLV that indicates 709 the overall pool user transport type is included as cause specific 710 information. 712 3.12.9. Inconsistent Data/Control Configuration Error 714 This error cause is used by an ENRP server to indicate to a 715 registering PE that the Transport Use field in the User Transport it 716 sent in its registration is inconsistent to the pool's overall data/ 717 control channel configuration. There is no cause specific 718 information. 720 3.12.10. Rejected due to security considerations 722 This error cause is used by any endpoint to indicate a rejection of a 723 request due to a failure in security credentials or authorizations. 725 3.12.11. Unknown Poor Handle Error 727 This error cause is used by an ENRP server to indicate to a PE or PU 728 that the requested pool is unknown by the server. There is no cause 729 specific information. 731 3.13. Cookie Parameter 733 This parameter defines a TLV that carries a Cookie. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type = 0xd | Length=variable | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 : : 741 : Cookie : 742 : : 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Length: 16 bits (unsigned integer) 746 Indicates the entire length of the parameter in number of bytes, 747 including the Type, Length, and Cookie. 749 Cookie: variable length The Cookie is an arbitrary byte string of 750 (Length - 4) bytes. 752 3.14. PE Identifier Parameter 754 This parameter defines a TLV that carries a PE Identifier. 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type = 0xe | Length=0x8 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | PE Identifier | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 PE Identifier: 32 bits (unsigned integer) 765 Uniquely identifies the PE in the pool. The PE picks its 766 identifier when it starts up. See [I-D.ietf-rserpool-asap] for 767 recommendations on PE identifier generation. 769 3.15. PE Checksum Parameter 771 This parameter defines a TLV that carries a PE Checksum. 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Type = 0xf | Length=0x6 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | PE Checksum | Padding | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 PE Checksum: 16 bits (unsigned integer) 782 An overall checksum of all PEs in the current handlespace owned by 783 an ENRP server (which is normally the sender of this TLV). The 784 definition and calculation of this checksum is defined in 785 [I-D.ietf-rserpool-enrp]. 787 4. Common Message Formats 789 The figure below illustrates the common format for all ASAP and ENRP 790 messages. Each message is formatted with a Message Type field, a 791 message-specific Flag field, a Message Length field, and a Value 792 field. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Message Type | Msg Flags | Message Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 : : 800 : Message Value : 801 : : 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Message Type: 8 bits (unsigned integer) 805 This field identifies the type of information contained in the 806 Message Value field. It takes a value from 0 to 254. The value 807 of 255 is reserved for future use as an extension field. 808 Message Types are encoded such that the highest-order two bits 809 specify the action that must be taken if the message receiver does 810 not recognize the Message Type. 812 00 Stop processing this message and discard it. 814 01 Stop processing this message and discard it, and report the 815 unrecognized message in an 'Unrecognized Message' error (see 816 Section 3.12.3). 818 10 reserved. 820 11 reserved. 822 Message Flags: 8 bits 823 The usage of these bits depends on the message type as given by 824 the Message Type. Unless otherwise specified, they are set to 825 zero on transmit and are ignored on receipt. 827 Message Length: 16 bits (unsigned integer) 828 This value represents the size of the message in bytes including 829 the Message Type, Message Flags, Message Length, and Message Value 830 fields. Therefore, if the Message Value field is zero-length, the 831 Length field will be set to 4. 832 Note, the value in Message Length field will NOT cover any padding 833 at the end of this message. 835 Message Value: variable length 836 The Message Value field contains the actual information to be 837 transferred in the message. The usage and format of this field is 838 dependent on the Message Type. 839 The total length of a message (including Type, Length and Value 840 fields) MUST be a multiple of 4 bytes. If the length of the 841 message is not a multiple of 4 bytes, the sender MUST pad the 842 message with all zero bytes and this padding is not included in 843 the message length field. The sender should never pad with more 844 than 3 bytes. The receiver MUST ignore the padding bytes. 846 5. IANA Considerations 848 [NOTE to RFC-Editor: 850 "RFCXXXX" is to be replaced by the RFC number you assign this 851 document. 853 ] 855 This document (RFCXXX) is the reference for all registrations 856 described in this section. All registrations need to be listed on an 857 RSerPool specific page. 859 5.1. A New Table for RSerPool Parameter Types 861 RSerPool Parameter Types have to be maintained by IANA. Thirteen 862 initial values should be assigned by IANA as described in Table 1. 863 This requires a new table "RSerPool Parameter Types": 865 +--------+------------------------------+ 866 | Value | Parameter Type | 867 +--------+------------------------------+ 868 | 0x0 | (reserved by IETF) | 869 | | | 870 | 0x1 | IPv4 Address | 871 | | | 872 | 0x2 | IPv6 Address | 873 | | | 874 | 0x3 | DCCP Transport | 875 | | | 876 | 0x4 | SCTP Transport | 877 | | | 878 | 0x5 | TCP Transport | 879 | | | 880 | 0x6 | UDP Transport | 881 | | | 882 | 0x7 | UDP-Lite | 883 | | | 884 | 0x8 | Pool Member Selection Policy | 885 | | | 886 | 0x9 | Pool Handle | 887 | | | 888 | 0xa | Pool Element | 889 | | | 890 | 0xb | Server Information | 891 | | | 892 | 0xc | Operation Error | 893 | | | 894 | 0xd | Cookie | 895 | | | 896 | 0xe | PE Identifier | 897 | | | 898 | 0xf | PE Checksum | 899 | | | 900 | others | (reserved by IETF) | 901 +--------+------------------------------+ 903 For registering at IANA an RSerPool Parameter Type in this table a 904 request has to be made to assign such a number. This number must be 905 unique. The "Specification Required" policy of [RFC2434] MUST be 906 applied. 908 5.2. A New Table for RSerPool Error Causes 910 RSerPool Error Causes have to be maintained by IANA. Eleven initial 911 values should be assigned by IANA as described in Table 2. This 912 requires a new table "RSerPool Error Causes": 914 +------------------+-----------------------------------------+ 915 | Cause Code Value | Cause Code | 916 +------------------+-----------------------------------------+ 917 | 0x0 | Unspecified Error | 918 | | | 919 | 0x1 | Unrecognized Parameter | 920 | | | 921 | 0x2 | Unrecognized Message | 922 | | | 923 | 0x3 | Invalid Values | 924 | | | 925 | 0x4 | Non-unique PE Identifier | 926 | | | 927 | 0x5 | Inconsistent Pooling Policy | 928 | | | 929 | 0x6 | Lack of Resources | 930 | | | 931 | 0x7 | Inconsistent Transport Type | 932 | | | 933 | 0x8 | Inconsistent Data/Control Configuration | 934 | | | 935 | 0x9 | Unknown Poor Handle | 936 | | | 937 | 0xa | Rejected due to security considerations | 938 | | | 939 | others | reserved by IETF | 940 +------------------+-----------------------------------------+ 942 For registering at IANA an RSerPool Error Cause in this table a 943 request has to be made to assign such a number. This number must be 944 unique. The "Specification Required" policy of [RFC2434] MUST be 945 applied. 947 6. Security Considerations 949 This document contains common parameter formats only. As such it 950 specifies no new security constraints on either ENRP or ASAP. 951 Details on ENRP and ASAP security constraints are addressed in 952 [I-D.ietf-rserpool-enrp] and [I-D.ietf-rserpool-asap]. 954 7. Normative References 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 960 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 961 October 1998. 963 [I-D.ietf-rserpool-asap] 964 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 965 "Aggregate Server Access Protocol (ASAP)", 966 draft-ietf-rserpool-asap-17 (work in progress), 967 September 2007. 969 [I-D.ietf-rserpool-enrp] 970 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 971 Silverton, "Endpoint Handlespace Redundancy Protocol 972 (ENRP)", draft-ietf-rserpool-enrp-17 (work in progress), 973 September 2007. 975 [I-D.ietf-rserpool-policies] 976 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 977 Policies", draft-ietf-rserpool-policies-07 (work in 978 progress), November 2007. 980 Authors' Addresses 982 Randall R. Stewart 983 Cisco Systems, Inc. 984 4875 Forest Drive 985 Suite 200 986 Columbia, SC 29206 987 USA 989 Email: rrs@cisco.com 991 Qiaobing Xie 992 Motorola, Inc. 993 1501 W. Shure Drive, #2309 994 Arlington Heights, IL 60004 995 USA 997 Email: qxie1@email.mot.com 999 Maureen Stillman 1000 Nokia 1001 127 W. State Street 1002 Ithaca, NY 14850 1003 USA 1005 Email: maureen.stillman@nokia.com 1007 Michael Tuexen 1008 Muenster Univ. of Applied Sciences 1009 Stegerwaldstr. 39 1010 48565 Steinfurt 1011 Germany 1013 Email: tuexen@fh-muenster.de 1015 Full Copyright Statement 1017 Copyright (C) The IETF Trust (2007). 1019 This document is subject to the rights, licenses and restrictions 1020 contained in BCP 78, and except as set forth therein, the authors 1021 retain all their rights. 1023 This document and the information contained herein are provided on an 1024 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1025 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1026 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1027 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1028 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1029 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1031 Intellectual Property 1033 The IETF takes no position regarding the validity or scope of any 1034 Intellectual Property Rights or other rights that might be claimed to 1035 pertain to the implementation or use of the technology described in 1036 this document or the extent to which any license under such rights 1037 might or might not be available; nor does it represent that it has 1038 made any independent effort to identify any such rights. Information 1039 on the procedures with respect to rights in RFC documents can be 1040 found in BCP 78 and BCP 79. 1042 Copies of IPR disclosures made to the IETF Secretariat and any 1043 assurances of licenses to be made available, or the result of an 1044 attempt made to obtain a general license or permission for the use of 1045 such proprietary rights by implementers or users of this 1046 specification can be obtained from the IETF on-line IPR repository at 1047 http://www.ietf.org/ipr. 1049 The IETF invites any interested party to bring to its attention any 1050 copyrights, patents or patent applications, or other proprietary 1051 rights that may cover technology that may be required to implement 1052 this standard. Please address the information to the IETF at 1053 ietf-ipr@ietf.org. 1055 Acknowledgment 1057 Funding for the RFC Editor function is provided by the IETF 1058 Administrative Support Activity (IASA).