idnits 2.17.1 draft-ietf-rserpool-common-param-15.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 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. 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 (December 3, 2007) is 5988 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-18 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-18 == 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: June 5, 2008 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 December 3, 2007 12 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 13 Redundancy Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-15.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 June 5, 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 . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 15 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 | DCCP service code | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 : IPv4 or IPv6 Address : 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Length: 16 bits (unsigned integer) 275 Indicates the entire length of the parameter in number of octets, 276 including the Type, Length, DCCP port, reserved fields, and IP 277 address parameter. 279 DCCP port: 16 bits (unsigned integer) 280 The DCCP port number signed to this DCCP user transport. 282 DCCP service code: 32 bits (unsigned integer) 283 The DCCP service code signed to this DCCP user transport. 285 IPv4 or IPv6 Address 286 Indicates an IPv4 or IPv6 address parameter (as defined above in 287 Section 3.1 and Section 3.2) assigned to this DCCP user transport. 288 Unlike in an SCTP transport parameter, only one IP address 289 parameter can be present in a DCCP transport parameter. 291 Note: A DCCP port MUST NOT be used for control information. For this 292 reason, no Transport Use field is provided. DCCP MUST always be 293 treated as a "Data Only" type transport use. 295 3.4. SCTP Transport Parameter 297 This parameter defines a TLV that describes a user transport using 298 SCTP protocol. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = 0x4 | Length = variable | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | SCTP port | Transport Use | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : IPv4 or IPv6 Address #1 : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 : : 310 : ... : 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 : IPv4 or IPv6 Address #n : 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Length: 16 bits (unsigned integer) 316 Indicates the entire length of the parameter in number of octets, 317 including the Type, Length, SCTP port, reserved fields, and all IP 318 address parameters present. 320 SCTP port: 16 bits (unsigned integer) 321 The SCTP port number signed to this SCTP user transport. 323 Transport use: 16 bits (unsigned integer) 324 This field represents how the pool element intends this transport 325 address to be used. The field MUST be populated with one of the 326 following values: 328 +-------------------+--------+ 329 | Type | Value | 330 +-------------------+--------+ 331 | DATA ONLY | 0x0000 | 332 | | | 333 | DATA plus CONTROL | 0x0001 | 334 +-------------------+--------+ 336 IPv4 or IPv6 Address #1 - #n 337 Each indicates an IPv4 or IPv6 address parameter (as defined above 338 in Section 3.1 and Section 3.2) assigned to this SCTP user 339 transport. An SCTP Transport parameter may have a mixed list of 340 IPv4 and IPv6 addresses and at least one IP address parameter MUST 341 be present in an SCTP transport parameter. 343 3.5. TCP Transport Parameter 345 This parameter defines a TLV that describes a user transport using 346 TCP protocol. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type = 0x5 | Length = variable | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | TCP port | (reserved) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 : IPv4 or IPv6 Address : 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Length: 16 bits (unsigned integer) 359 Indicates the entire length of the parameter in number of octets, 360 including the Type, Length, TCP port, reserved fields, and IP 361 address parameter. 363 TCP port: 16 bits (unsigned integer) 364 The TCP port number signed to this TCP user transport. 366 IPv4 or IPv6 Address 367 Indicates an IPv4 or IPv6 address parameter (as defined above in 368 Section 3.1 and Section 3.2) assigned to this TCP user transport. 369 Unlike in an SCTP transport parameter, only one IP address 370 parameter can be present in a TCP transport parameter. 372 Note: A TCP port MUST NOT be used for control information. For this 373 reason, no Transport Use field is provided. TCP MUST always be 374 treated as a "Data Only" type transport use. 376 3.6. UDP Transport Parameter 378 This parameter defines a TLV that describes a user transport using 379 UDP protocol. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type = 0x6 | Length = variable | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | UDP port | (reserved) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 : IPv4 or IPv6 Address : 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Length: 16 bits (unsigned integer) 392 Indicates the entire length of the parameter in number of octets, 393 including the Type, Length, UDP port, reserved fields, and IP 394 address parameter. 396 UDP port: 16 bits (unsigned integer) 397 The UDP port number signed to this UDP user transport. 399 IPv4 or IPv6 Address 400 Indicates an IPv4 or IPv6 address parameter (as defined above in 401 Section 3.1 and Section 3.2) assigned to this UDP user transport. 402 Unlike in an SCTP transport parameter, only one IP address 403 parameter can be present in a UDP transport parameter. 405 Note: A UDP port MUST NOT be used for control information. For this 406 reason, no Transport Use field is provided. UDP MUST always be 407 treated as a "Data Only" type transport use. 409 3.7. UDP-Lite Transport Parameter 411 This parameter defines a TLV that describes a user transport using 412 UDP-Lite protocol. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type = 0x7 | Length = variable | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | UDP-Lite port | (reserved) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 : IPv4 or IPv6 Address : 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Length: 16 bits (unsigned integer) 425 Indicates the entire length of the parameter in number of octets, 426 including the Type, Length, UDP-Lite port, reserved fields, and IP 427 address parameter. 429 UDP port: 16 bits (unsigned integer) 430 The UDP-Lite port number signed to this UDP-Lite user transport. 432 IPv4 or IPv6 Address 433 Indicates an IPv4 or IPv6 address parameter (as defined above in 434 Section 3.1 and Section 3.2) assigned to this UDP-Lite user 435 transport. Unlike in an SCTP transport parameter, only one IP 436 address parameter can be present in a UDP-Lite transport 437 parameter. 439 Note: A UDP-Lite port MUST NOT be used for control information. For 440 this reason, no Transport Use field is provided. UDP-Lite MUST 441 always be treated as a "Data Only" type transport use. 443 3.8. Pool Member Selection Policy Parameter 445 This parameter defines a pool member selection policy. RSerPool 446 supports multiple pool member selection policies and also allows 447 definition of new selection policies in the future. 449 The enforcement rules and handling procedures of all the policies are 450 defined in [I-D.ietf-rserpool-asap]. 452 All pool member selection policies, both present and future, MUST use 453 the following general parameter format: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type = 0x8 | Length = variable | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Policy Type | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Policy-specific Data | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Length: 16 bits (unsigned integer) 466 Indicates the entire length of the parameter in number of octets, 467 including the Type, Length, Policy Type, and the Policy-specific 468 Data fields. 469 Note, the Length field value will NOT include any padding at the 470 end of the parameter. 472 Policy Type: 32 bits (unsigned integer) 473 Specifies the type of selection policy. 475 Policy-specific Data: 476 The structure and fields for each presently defined policy types 477 are described in detail in [I-D.ietf-rserpool-policies]. 479 3.9. Pool Handle Parameter 481 This parameter holds a pool handle. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type = 0x9 | Length=variable | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 : : 489 : Pool Handle : 490 : : 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Length: 16 bits (unsigned integer) 494 Indicates the entire length of the parameter in number of octets, 495 including the Type, Length, and Pool Handle string. 496 Note, the value in Length field will NOT cover any padding at the 497 end of the parameter. 499 Pool Handle 500 defined as a sequence of (Length - 4) bytes. 502 3.10. Pool Element Parameter 504 This parameter is used in multiple ENRP messages to represent an ASAP 505 endpoint (i.e., a PE in a pool) and the associated information, such 506 as its transport address, selection policy, and other operational or 507 status information of the PE. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type = 0xa | Length=variable | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | PE Identifier | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Home ENRP Server Identifier | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Registration Life | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 : User Transport param : 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 : Member Selection Policy param : 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 : ASAP Transport param : 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Length: 16 bits (unsigned integer) 527 Indicates the entire length of the parameter in number of octets, 528 including the Type, Length, PE Identifier, Registration Life, User 529 Transport, and Member Selection Policy parameters. 530 Note, the value in Length field will NOT cover any padding at the 531 end of this Pool Element parameter. 533 PE Identifier: 32 bits (unsigned integer) 534 Uniquely identifies the PE in the pool. The PE picks its 535 identifier when it starts up. 537 Home ENRP Server Identifier: 32 bits (unsigned integer) 538 Indicates the current home ENRP server of this PE. Set to all 0's 539 if the PE's home ENRP server is undetermined. 541 Registration Life: 32 bits (signed integer) 542 Indicates the life time of the registration in number of seconds. 543 A value of -1 indicates infinite life time. 545 User Transport 546 This can be either an DCCP, SCTP, TCP, UDP, or UDP-Lite type 547 transport parameter (see Section 3.3, Section 3.4, Section 3.5, 548 Section 3.6, Section 3.7). A PE MUST have one and only one User 549 Transport. 551 Member Selection Policy 552 Contains one of the defined member selection policy parameters 553 (see Section 3.8). 555 ASAP Transport 556 This indicates the ASAP transport address of the PE and MUST be an 557 SCTP type transport parameter (see Section 3.4). 559 3.11. Server Information Parameter 561 This parameter is used in ENRP to pass basic information of an ENRP 562 server. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type = 0xb | Length=variable | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Server ID | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : Server Transport : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Length: 16 bits (unsigned integer) 574 Indicates the entire length of the parameter in number of bytes. 575 Note, the value in Length field will NOT cover any padding at the 576 end of the parameter. 578 Server ID: 32 bit (unsigned integer) 579 This is the ID of the ENRP server, as defined in 580 [I-D.ietf-rserpool-enrp]. 582 Server Transport: 583 This is an SCTP Transport Parameter, as defined in Section 3.4 584 that contains the network access address(es), SCTP port number, 585 etc. of the ENRP server. 587 3.12. Operation Error Parameter 589 This parameter is used in both ENPR and ASAP for a message sender to 590 report an error(s) to a message receiver. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type = 0xc | Length=variable | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 : : 598 : one or more Error Causes : 599 : : 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Length: 16 bits (unsigned integer) 603 Indicates the entire length of the parameter in number of bytes. 604 Note, the value in Length field will NOT cover any padding at the 605 end of the parameter. 607 Error causes are defined as variable-length parameters using the 608 following format: 610 0 1 2 3 611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Cause Code | Cause Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 : : 616 : Cause-specific Information : 617 : : 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Cause Code: 16 bits (unsigned integer) 620 Defines the type of error condition being reported. 622 +------------------+-----------------------------------------+ 623 | Cause Code Value | Cause Code | 624 +------------------+-----------------------------------------+ 625 | 0x0 | Unspecified Error | 626 | | | 627 | 0x1 | Unrecognized Parameter | 628 | | | 629 | 0x2 | Unrecognized Message | 630 | | | 631 | 0x3 | Invalid Values | 632 | | | 633 | 0x4 | Non-unique PE Identifier | 634 | | | 635 | 0x5 | Inconsistent Pooling Policy | 636 | | | 637 | 0x6 | Lack of Resources | 638 | | | 639 | 0x7 | Inconsistent Transport Type | 640 | | | 641 | 0x8 | Inconsistent Data/Control Configuration | 642 | | | 643 | 0x9 | Unknown Poor Handle | 644 | | | 645 | 0xa | Rejected due to security considerations | 646 | | | 647 | others | reserved by IETF | 648 +------------------+-----------------------------------------+ 650 Table 2 652 Cause Length: 16 bits (unsigned integer) 653 Set to the size of the parameter in bytes, including the Cause 654 Code, Cause Length, and Cause-Specific Information fields, but not 655 including any padding at the end of this error cause TLV. 657 Cause-specific Information: variable length 658 This field carries the details of the error condition. 660 The following subsections (Section 3.12.1 - Section 3.12.9) define 661 specific error causes. 663 3.12.1. Unspecified Error 665 This error cause is used to report an unspecified error by the 666 sender. There is no cause specific information. 668 3.12.2. Unrecognized Parameter Error 670 This error cause is used to report an unrecognized parameter. The 671 unrecognized parameter TLV is included as cause specific information. 672 If a message contains multiple unrecognized parameters, multiple 673 error causes are used. 675 3.12.3. Unrecognized Message Error 677 This error cause is used to report an unrecognized message. The 678 unrecognized message TLV is included as cause specific information. 680 3.12.4. Invalid Values Error 682 This error cause is used to report one or more invalid values found 683 in a received parameter. The offending TLV that contains the invalid 684 value(s) is included as cause specific information. 686 3.12.5. Non-unique PE Identifier Error 688 This error cause is used by an ENRP server to indicate to a 689 registering PE that the PE Identifier it chooses has already been 690 used by another PE in the pool. There is no cause specific 691 information. 693 3.12.6. Inconsistent Pool Policy Error 695 This error cause is used by an ENRP server to indicate to a 696 registering PE that the Pool Policy it chooses does not match the 697 overall policy of the pool. A Pool Member Selection Policy TLV (see 698 Section 3.8) that indicates the overall pool policy is included as 699 cause specific information. 701 3.12.7. Lack of Resources Error 703 This error cause is used to indicate that the sender does not have 704 certain resources to perform a requested function. There is no cause 705 specific information. 707 3.12.8. Inconsistent Transport Type Error 709 This error cause is used by an ENRP server to indicate to a 710 registering PE that the User Transport it chooses does not match the 711 overall user transport of the pool. A Transport TLV that indicates 712 the overall pool user transport type is included as cause specific 713 information. 715 3.12.9. Inconsistent Data/Control Configuration Error 717 This error cause is used by an ENRP server to indicate to a 718 registering PE that the Transport Use field in the User Transport it 719 sent in its registration is inconsistent to the pool's overall data/ 720 control channel configuration. There is no cause specific 721 information. 723 3.12.10. Rejected due to security considerations 725 This error cause is used by any endpoint to indicate a rejection of a 726 request due to a failure in security credentials or authorizations. 728 3.12.11. Unknown Poor Handle Error 730 This error cause is used by an ENRP server to indicate to a PE or PU 731 that the requested pool is unknown by the server. There is no cause 732 specific information. 734 3.13. Cookie Parameter 736 This parameter defines a TLV that carries a Cookie. 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type = 0xd | Length=variable | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 : : 744 : Cookie : 745 : : 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 Length: 16 bits (unsigned integer) 749 Indicates the entire length of the parameter in number of bytes, 750 including the Type, Length, and Cookie. 752 Cookie: variable length The Cookie is an arbitrary byte string of 753 (Length - 4) bytes. 755 3.14. PE Identifier Parameter 757 This parameter defines a TLV that carries a PE Identifier. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type = 0xe | Length=0x8 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | PE Identifier | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 PE Identifier: 32 bits (unsigned integer) 768 Uniquely identifies the PE in the pool. The PE picks its 769 identifier when it starts up. See [I-D.ietf-rserpool-asap] for 770 recommendations on PE identifier generation. 772 3.15. PE Checksum Parameter 774 This parameter defines a TLV that carries a PE Checksum. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type = 0xf | Length=0x6 | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | PE Checksum | Padding | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 PE Checksum: 16 bits (unsigned integer) 785 An overall checksum of all PEs in the current handlespace owned by 786 an ENRP server (which is normally the sender of this TLV). The 787 definition and calculation of this checksum is defined in 788 [I-D.ietf-rserpool-enrp]. 790 4. Common Message Formats 792 The figure below illustrates the common format for all ASAP and ENRP 793 messages. Each message is formatted with a Message Type field, a 794 message-specific Flag field, a Message Length field, and a Value 795 field. 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Message Type | Msg Flags | Message Length | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 : : 803 : Message Value : 804 : : 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Message Type: 8 bits (unsigned integer) 808 This field identifies the type of information contained in the 809 Message Value field. It takes a value from 0 to 254. The value 810 of 255 is reserved for future use as an extension field. 811 Message Types are encoded such that the highest-order two bits 812 specify the action that must be taken if the message receiver does 813 not recognize the Message Type. 815 00 Stop processing this message and discard it. 817 01 Stop processing this message and discard it, and report the 818 unrecognized message in an 'Unrecognized Message' error (see 819 Section 3.12.3). 821 10 reserved. 823 11 reserved. 825 Message Flags: 8 bits 826 The usage of these bits depends on the message type as given by 827 the Message Type. Unless otherwise specified, they are set to 828 zero on transmit and are ignored on receipt. 830 Message Length: 16 bits (unsigned integer) 831 This value represents the size of the message in bytes including 832 the Message Type, Message Flags, Message Length, and Message Value 833 fields. Therefore, if the Message Value field is zero-length, the 834 Length field will be set to 4. 835 Note, the value in Message Length field will NOT cover any padding 836 at the end of this message. 838 Message Value: variable length 839 The Message Value field contains the actual information to be 840 transferred in the message. The usage and format of this field is 841 dependent on the Message Type. 842 The total length of a message (including Type, Length and Value 843 fields) MUST be a multiple of 4 bytes. If the length of the 844 message is not a multiple of 4 bytes, the sender MUST pad the 845 message with all zero bytes and this padding is not included in 846 the message length field. The sender should never pad with more 847 than 3 bytes. The receiver MUST ignore the padding bytes. 849 5. IANA Considerations 851 [NOTE to RFC-Editor: 853 "RFCXXXX" is to be replaced by the RFC number you assign this 854 document. 856 ] 858 This document (RFCXXX) is the reference for all registrations 859 described in this section. All registrations need to be listed on an 860 RSerPool specific page. 862 5.1. A New Table for RSerPool Parameter Types 864 RSerPool Parameter Types have to be maintained by IANA. Thirteen 865 initial values should be assigned by IANA as described in Table 1. 866 This requires a new table "RSerPool Parameter Types": 868 +--------+------------------------------+ 869 | Value | Parameter Type | 870 +--------+------------------------------+ 871 | 0x0 | (reserved by IETF) | 872 | | | 873 | 0x1 | IPv4 Address | 874 | | | 875 | 0x2 | IPv6 Address | 876 | | | 877 | 0x3 | DCCP Transport | 878 | | | 879 | 0x4 | SCTP Transport | 880 | | | 881 | 0x5 | TCP Transport | 882 | | | 883 | 0x6 | UDP Transport | 884 | | | 885 | 0x7 | UDP-Lite | 886 | | | 887 | 0x8 | Pool Member Selection Policy | 888 | | | 889 | 0x9 | Pool Handle | 890 | | | 891 | 0xa | Pool Element | 892 | | | 893 | 0xb | Server Information | 894 | | | 895 | 0xc | Operation Error | 896 | | | 897 | 0xd | Cookie | 898 | | | 899 | 0xe | PE Identifier | 900 | | | 901 | 0xf | PE Checksum | 902 | | | 903 | others | (reserved by IETF) | 904 +--------+------------------------------+ 906 For registering at IANA an RSerPool Parameter Type in this table a 907 request has to be made to assign such a number. This number must be 908 unique. The "Specification Required" policy of [RFC2434] MUST be 909 applied. 911 5.2. A New Table for RSerPool Error Causes 913 RSerPool Error Causes have to be maintained by IANA. Eleven initial 914 values should be assigned by IANA as described in Table 2. This 915 requires a new table "RSerPool Error Causes": 917 +------------------+-----------------------------------------+ 918 | Cause Code Value | Cause Code | 919 +------------------+-----------------------------------------+ 920 | 0x0 | Unspecified Error | 921 | | | 922 | 0x1 | Unrecognized Parameter | 923 | | | 924 | 0x2 | Unrecognized Message | 925 | | | 926 | 0x3 | Invalid Values | 927 | | | 928 | 0x4 | Non-unique PE Identifier | 929 | | | 930 | 0x5 | Inconsistent Pooling Policy | 931 | | | 932 | 0x6 | Lack of Resources | 933 | | | 934 | 0x7 | Inconsistent Transport Type | 935 | | | 936 | 0x8 | Inconsistent Data/Control Configuration | 937 | | | 938 | 0x9 | Unknown Poor Handle | 939 | | | 940 | 0xa | Rejected due to security considerations | 941 | | | 942 | others | reserved by IETF | 943 +------------------+-----------------------------------------+ 945 For registering at IANA an RSerPool Error Cause in this table a 946 request has to be made to assign such a number. This number must be 947 unique. The "Specification Required" policy of [RFC2434] MUST be 948 applied. 950 6. Security Considerations 952 This document contains common parameter formats only. As such it 953 specifies no new security constraints on either ENRP or ASAP. 954 Details on ENRP and ASAP security constraints are addressed in 955 [I-D.ietf-rserpool-enrp] and [I-D.ietf-rserpool-asap]. 957 7. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 963 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 964 October 1998. 966 [I-D.ietf-rserpool-asap] 967 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 968 "Aggregate Server Access Protocol (ASAP)", 969 draft-ietf-rserpool-asap-18 (work in progress), 970 November 2007. 972 [I-D.ietf-rserpool-enrp] 973 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 974 Silverton, "Endpoint Handlespace Redundancy Protocol 975 (ENRP)", draft-ietf-rserpool-enrp-18 (work in progress), 976 November 2007. 978 [I-D.ietf-rserpool-policies] 979 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 980 Policies", draft-ietf-rserpool-policies-07 (work in 981 progress), November 2007. 983 Authors' Addresses 985 Randall R. Stewart 986 Cisco Systems, Inc. 987 4875 Forest Drive 988 Suite 200 989 Columbia, SC 29206 990 USA 992 Email: rrs@cisco.com 994 Qiaobing Xie 995 Motorola, Inc. 996 1501 W. Shure Drive, #2309 997 Arlington Heights, IL 60004 998 USA 1000 Email: qxie1@email.mot.com 1002 Maureen Stillman 1003 Nokia 1004 127 W. State Street 1005 Ithaca, NY 14850 1006 USA 1008 Email: maureen.stillman@nokia.com 1010 Michael Tuexen 1011 Muenster Univ. of Applied Sciences 1012 Stegerwaldstr. 39 1013 48565 Steinfurt 1014 Germany 1016 Email: tuexen@fh-muenster.de 1018 Full Copyright Statement 1020 Copyright (C) The IETF Trust (2007). 1022 This document is subject to the rights, licenses and restrictions 1023 contained in BCP 78, and except as set forth therein, the authors 1024 retain all their rights. 1026 This document and the information contained herein are provided on an 1027 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1028 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1029 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1030 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1031 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1032 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1034 Intellectual Property 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed to 1038 pertain to the implementation or use of the technology described in 1039 this document or the extent to which any license under such rights 1040 might or might not be available; nor does it represent that it has 1041 made any independent effort to identify any such rights. Information 1042 on the procedures with respect to rights in RFC documents can be 1043 found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use of 1048 such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository at 1050 http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at 1056 ietf-ipr@ietf.org. 1058 Acknowledgment 1060 Funding for the RFC Editor function is provided by the IETF 1061 Administrative Support Activity (IASA).