idnits 2.17.1 draft-ietf-rserpool-common-param-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (May 29, 2008) is 5809 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-19 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-19 == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-08 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 Q. Xie 4 Intended status: Experimental 5 Expires: November 30, 2008 M. Stillman 6 Nokia 7 M. Tuexen 8 Muenster Univ. of Applied Sciences 9 May 29, 2008 11 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 12 Redundancy Protocol (ENRP) Parameters 13 draft-ietf-rserpool-common-param-17.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 30, 2008. 40 Abstract 42 This document details the parameters of the Aggregate Server Access 43 Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) 44 protocols defined within the Reliable Server Pooling (RSerPool) 45 architecture. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Parameters in General . . . . . . . . . . . . . . . . . . . . 5 52 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . . . 6 53 3.1. IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 8 54 3.2. IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 8 55 3.3. DCCP Transport Parameter . . . . . . . . . . . . . . . . . 9 56 3.4. SCTP Transport Parameter . . . . . . . . . . . . . . . . . 9 57 3.5. TCP Transport Parameter . . . . . . . . . . . . . . . . . 10 58 3.6. UDP Transport Parameter . . . . . . . . . . . . . . . . . 11 59 3.7. UDP-Lite Transport Parameter . . . . . . . . . . . . . . . 12 60 3.8. Pool Member Selection Policy Parameter . . . . . . . . . . 13 61 3.9. Pool Handle Parameter . . . . . . . . . . . . . . . . . . 13 62 3.10. Pool Element Parameter . . . . . . . . . . . . . . . . . . 14 63 3.11. Server Information Parameter . . . . . . . . . . . . . . . 15 64 3.12. Operation Error Parameter . . . . . . . . . . . . . . . . 16 65 3.12.1. Unspecified Error . . . . . . . . . . . . . . . . . . 17 66 3.12.2. Unrecognized Parameter Error . . . . . . . . . . . . 18 67 3.12.3. Unrecognized Message Error . . . . . . . . . . . . . 18 68 3.12.4. Invalid Values Error . . . . . . . . . . . . . . . . 18 69 3.12.5. Non-unique PE Identifier Error . . . . . . . . . . . 18 70 3.12.6. Inconsistent Pool Policy Error . . . . . . . . . . . 18 71 3.12.7. Lack of Resources Error . . . . . . . . . . . . . . . 18 72 3.12.8. Inconsistent Transport Type Error . . . . . . . . . . 18 73 3.12.9. Inconsistent Data/Control Configuration Error . . . . 19 74 3.12.10. Rejected due to security considerations . . . . . . . 19 75 3.12.11. Unknown Pool Handle Error . . . . . . . . . . . . . . 19 76 3.13. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 19 77 3.14. PE Identifier Parameter . . . . . . . . . . . . . . . . . 19 78 3.15. PE Checksum Parameter . . . . . . . . . . . . . . . . . . 20 79 3.16. Opaque Transport Parameter . . . . . . . . . . . . . . . . 20 80 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 22 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 5.1. A New Table for RSerPool Parameter Types . . . . . . . . . 24 83 5.2. A New Table for RSerPool Error Causes . . . . . . . . . . 26 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 85 7. Normative References . . . . . . . . . . . . . . . . . . . . . 28 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 87 Intellectual Property and Copyright Statements . . . . . . . . . . 30 89 1. Introduction 91 Aggregate Server Access Protocol (ASAP) [I-D.ietf-rserpool-asap] in 92 conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) 93 [I-D.ietf-rserpool-enrp] provides a high availability data transfer 94 mechanism over IP networks. 96 Both protocols work together and so share many common parameters used 97 in message formats. This document details the common message 98 parameters shared between the two protocols. This document provides 99 parameter formats only, for procedures and message composition please 100 refer to the respective [I-D.ietf-rserpool-asap] and 101 [I-D.ietf-rserpool-enrp] documents. 103 1.1. Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Parameters in General 111 All parameters described below MUST be in Network Byte Order (a.k.a. 112 Big Endian, i.e., the most significant byte first) during 113 transmission. 115 Please note that messages in both ENRP and ASAP are often composed of 116 multiple parameters. These parameters may also be nested. In such a 117 case a nested parameter will include the length of the padding 118 between the nested parameters but not the last padding. 120 3. ENRP-ASAP Common Parameters 122 Parameters are defined in the following Type-Length-Value (TLV) 123 format: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Parameter Type | Parameter Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 : : 131 : Parameter Value : 132 : +-------------------------------: 133 : | Padding : 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Parameter Type: 16 bits (unsigned integer) 137 The Type field is a 16 bit identifier of the type of parameter. 138 It takes a value of 0 to 65534. 139 The value of 65535 is reserved for IETF-defined extensions. 140 Values other than those defined in specific ENRP parameter 141 description are reserved by IETF. (Additional types, when needed, 142 will be defined in the future through appropriate IETF/IANA 143 procedures.) 144 The Parameter Types are encoded such that the highest-order two 145 bits specify the action that must be taken if the processing 146 endpoint does not recognize the Parameter Type. 148 00 Stop processing this ENRP or ASAP message and discard it, do 149 not process any further parameters within it. 151 01 Stop processing this ENRP or ASAP message and discard it, do 152 not process any further parameters within it, and report the 153 unrecognized parameter in an 'Unrecognized Parameter' error 154 (see Section 3.12). 156 10 Skip this parameter and continue processing. 158 11 Skip this parameter and continue processing, but report the 159 unrecognized parameter in an 'Unrecognized Parameter' error 160 (see Section 3.12). 162 The values of parameter types are defined as follows: 164 +------------+------------------------------+ 165 | Value | Parameter Type | 166 +------------+------------------------------+ 167 | 0x0 | (reserved by IETF) | 168 | | | 169 | 0x1 | IPv4 Address | 170 | | | 171 | 0x2 | IPv6 Address | 172 | | | 173 | 0x3 | DCCP Transport | 174 | | | 175 | 0x4 | SCTP Transport | 176 | | | 177 | 0x5 | TCP Transport | 178 | | | 179 | 0x6 | UDP Transport | 180 | | | 181 | 0x7 | UDP-Lite | 182 | | | 183 | 0x8 | Pool Member Selection Policy | 184 | | | 185 | 0x9 | Pool Handle | 186 | | | 187 | 0xa | Pool Element | 188 | | | 189 | 0xb | Server Information | 190 | | | 191 | 0xc | Operation Error | 192 | | | 193 | 0xd | Cookie | 194 | | | 195 | 0xe | PE Identifier | 196 | | | 197 | 0xf | PE Checksum | 198 | | | 199 | 0x10 | Opaque Transport | 200 | | | 201 | others | (reserved by IETF) | 202 | | | 203 | 0xffffffff | IETF-defined extensions | 204 +------------+------------------------------+ 206 Table 1 208 Parameter Length: 16 bits (unsigned integer) 209 The Parameter Length field contains the size of the parameter in 210 bytes, including the Parameter Type, Parameter Length, and 211 Parameter Value fields. Thus, a parameter with a zero-length 212 Parameter Value field would have a Length field of 4. 213 The total length of a parameter (including Type, Parameter Length 214 and Value fields) MUST be a multiple of 4 bytes. If the length of 215 the parameter is not a multiple of 4 bytes, the sender MUST pad 216 the parameter at the end (i.e., after the Parameter Value field) 217 with all zero bytes. The length of this padding is not included 218 in the Parameter Length field. A sender MUST NOT pad with more 219 than 3 bytes. The receiver MUST ignore the padding bytes. 221 Parameter Value: variable-length. 222 The Parameter Value field contains the actual information to be 223 transferred in the parameter. 225 Parameter Padding: variable-length. 226 The Parameter Padding as described above. 228 3.1. IPv4 Address Parameter 230 This parameter defines a TLV that carries an IPv4 address. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type = 0x1 | Length = 0x8 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | IPv4 Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 IPv4 Address: 32 bits (unsigned integer) 241 Contains an IPv4 address. It is binary encoded. 243 3.2. IPv6 Address Parameter 245 This parameter defines a TLV that carries an IPv6 address. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x2 | Length = 0x14 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | IPv6 Address | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 IPv6 Address: 128 bit (unsigned integer) 259 Contains an IPv6 address. It is binary encoded. 261 3.3. DCCP Transport Parameter 263 This parameter defines a TLV that describes a user transport using 264 DCCP protocol. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type = 0x3 | Length = variable | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | DCCP port | (reserved) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | DCCP service code | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 : IPv4 or IPv6 Address : 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Length: 16 bits (unsigned integer) 279 Indicates the entire length of the parameter in number of octets, 280 including the Type, Length, DCCP port, reserved fields, and IP 281 address parameter. 283 DCCP port: 16 bits (unsigned integer) 284 The DCCP port number signed to this DCCP user transport. 286 DCCP service code: 32 bits (unsigned integer) 287 The DCCP service code signed to this DCCP user transport. 289 IPv4 or IPv6 Address 290 Indicates an IPv4 or IPv6 address parameter (as defined above in 291 Section 3.1 and Section 3.2) assigned to this DCCP user transport. 292 Unlike in an SCTP transport parameter, only one IP address 293 parameter can be present in a DCCP transport parameter. 295 Note: A DCCP port MUST NOT be used for control information. For this 296 reason, no Transport Use field is provided. DCCP MUST always be 297 treated as a "Data Only" type transport use. 299 3.4. SCTP Transport Parameter 301 This parameter defines a TLV that describes a user transport using 302 SCTP protocol. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type = 0x4 | Length = variable | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | SCTP port | Transport Use | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 : IPv4 or IPv6 Address #1 : 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 : : 314 : ... : 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 : IPv4 or IPv6 Address #n : 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Length: 16 bits (unsigned integer) 320 Indicates the entire length of the parameter in number of octets, 321 including the Type, Length, SCTP port, reserved fields, and all IP 322 address parameters present. 324 SCTP port: 16 bits (unsigned integer) 325 The SCTP port number signed to this SCTP user transport. 327 Transport use: 16 bits (unsigned integer) 328 This field represents how the pool element intends this transport 329 address to be used. The field MUST be populated with one of the 330 following values: 332 +-------------------+--------+ 333 | Type | Value | 334 +-------------------+--------+ 335 | DATA ONLY | 0x0000 | 336 | | | 337 | DATA plus CONTROL | 0x0001 | 338 +-------------------+--------+ 340 IPv4 or IPv6 Address #1 - #n 341 Each indicates an IPv4 or IPv6 address parameter (as defined above 342 in Section 3.1 and Section 3.2) assigned to this SCTP user 343 transport. An SCTP Transport parameter may have a mixed list of 344 IPv4 and IPv6 addresses and at least one IP address parameter MUST 345 be present in an SCTP transport parameter. 347 3.5. TCP Transport Parameter 349 This parameter defines a TLV that describes a user transport using 350 TCP protocol. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type = 0x5 | Length = variable | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | TCP port | (reserved) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 : IPv4 or IPv6 Address : 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Length: 16 bits (unsigned integer) 363 Indicates the entire length of the parameter in number of octets, 364 including the Type, Length, TCP port, reserved fields, and IP 365 address parameter. 367 TCP port: 16 bits (unsigned integer) 368 The TCP port number signed to this TCP user transport. 370 IPv4 or IPv6 Address 371 Indicates an IPv4 or IPv6 address parameter (as defined above in 372 Section 3.1 and Section 3.2) assigned to this TCP user transport. 373 Unlike in an SCTP transport parameter, only one IP address 374 parameter can be present in a TCP transport parameter. 376 Note: A TCP port MUST NOT be used for control information. For this 377 reason, no Transport Use field is provided. TCP MUST always be 378 treated as a "Data Only" type transport use. 380 3.6. UDP Transport Parameter 382 This parameter defines a TLV that describes a user transport using 383 UDP protocol. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type = 0x6 | Length = variable | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | UDP port | (reserved) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 : IPv4 or IPv6 Address : 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Length: 16 bits (unsigned integer) 396 Indicates the entire length of the parameter in number of octets, 397 including the Type, Length, UDP port, reserved fields, and IP 398 address parameter. 400 UDP port: 16 bits (unsigned integer) 401 The UDP port number signed to this UDP user transport. 403 IPv4 or IPv6 Address 404 Indicates an IPv4 or IPv6 address parameter (as defined above in 405 Section 3.1 and Section 3.2) assigned to this UDP user transport. 406 Unlike in an SCTP transport parameter, only one IP address 407 parameter can be present in a UDP transport parameter. 409 Note: A UDP port MUST NOT be used for control information. For this 410 reason, no Transport Use field is provided. UDP MUST always be 411 treated as a "Data Only" type transport use. 413 3.7. UDP-Lite Transport Parameter 415 This parameter defines a TLV that describes a user transport using 416 UDP-Lite protocol. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type = 0x7 | Length = variable | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | UDP-Lite port | (reserved) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 : IPv4 or IPv6 Address : 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Length: 16 bits (unsigned integer) 429 Indicates the entire length of the parameter in number of octets, 430 including the Type, Length, UDP-Lite port, reserved fields, and IP 431 address parameter. 433 UDP port: 16 bits (unsigned integer) 434 The UDP-Lite port number signed to this UDP-Lite user transport. 436 IPv4 or IPv6 Address 437 Indicates an IPv4 or IPv6 address parameter (as defined above in 438 Section 3.1 and Section 3.2) assigned to this UDP-Lite user 439 transport. Unlike in an SCTP transport parameter, only one IP 440 address parameter can be present in a UDP-Lite transport 441 parameter. 443 Note: A UDP-Lite port MUST NOT be used for control information. For 444 this reason, no Transport Use field is provided. UDP-Lite MUST 445 always be treated as a "Data Only" type transport use. 447 3.8. Pool Member Selection Policy Parameter 449 This parameter defines a pool member selection policy. RSerPool 450 supports multiple pool member selection policies and also allows 451 definition of new selection policies in the future. 453 The enforcement rules and handling procedures of all the policies are 454 defined in [I-D.ietf-rserpool-asap]. 456 All pool member selection policies, both present and future, MUST use 457 the following general parameter format: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type = 0x8 | Length = variable | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Policy Type | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Policy-specific Data | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Length: 16 bits (unsigned integer) 470 Indicates the entire length of the parameter in number of octets, 471 including the Type, Length, Policy Type, and the Policy-specific 472 Data fields. 473 Note, the Length field value will NOT include any padding at the 474 end of the parameter. 476 Policy Type: 32 bits (unsigned integer) 477 Specifies the type of selection policy. The values are defined in 478 [I-D.ietf-rserpool-policies]. 480 Policy-specific Data: 481 The structure and fields for each presently defined policy type 482 are described in detail in [I-D.ietf-rserpool-policies]. 484 3.9. Pool Handle Parameter 486 This parameter holds a pool handle. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type = 0x9 | Length=variable | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 : : 494 : Pool Handle : 495 : : 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Length: 16 bits (unsigned integer) 499 Indicates the entire length of the parameter in number of octets, 500 including the Type, Length, and Pool Handle string. 501 Note, the value in Length field will NOT cover any padding at the 502 end of the parameter. 504 Pool Handle 505 defined as a sequence of (Length - 4) bytes. 507 3.10. Pool Element Parameter 509 This parameter is used in multiple ENRP messages to represent an ASAP 510 endpoint (i.e., a PE in a pool) and the associated information, such 511 as its transport address, selection policy, and other operational or 512 status information of the PE. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type = 0xa | Length=variable | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | PE Identifier | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Home ENRP Server Identifier | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Registration Life | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 : User Transport param : 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 : Member Selection Policy param : 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 : ASAP Transport param : 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Length: 16 bits (unsigned integer) 532 Indicates the entire length of the parameter in number of octets, 533 including the Type, Length, PE Identifier, Registration Life, User 534 Transport, and Member Selection Policy parameters. 535 Note, the value in Length field will NOT cover any padding at the 536 end of this Pool Element parameter. 538 PE Identifier: 32 bits (unsigned integer) 539 Uniquely identifies the PE in the pool. The PE picks its 540 identifier when it starts up. 542 Home ENRP Server Identifier: 32 bits (unsigned integer) 543 Indicates the current home ENRP server of this PE. Set to all 0's 544 if the PE's home ENRP server is undetermined. 546 Registration Life: 32 bits (signed integer) 547 Indicates the life time of the registration in number of seconds. 548 A value of -1 indicates infinite life time. 550 User Transport 551 This can be either an DCCP, SCTP, TCP, UDP, UDP-Lite, or Opaque 552 transport parameter (see Section 3.3, Section 3.4, Section 3.5, 553 Section 3.6, Section 3.7, Section 3.16). A PE MUST have one and 554 only one User Transport. 556 Member Selection Policy 557 Contains one of the defined member selection policy parameters 558 (see Section 3.8). 560 ASAP Transport 561 This indicates the ASAP transport address of the PE and MUST be an 562 SCTP type transport parameter (see Section 3.4). 564 3.11. Server Information Parameter 566 This parameter is used in ENRP to pass basic information of an ENRP 567 server. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type = 0xb | Length=variable | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Server ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 : Server Transport : 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Length: 16 bits (unsigned integer) 579 Indicates the entire length of the parameter in number of bytes. 580 Note, the value in Length field will NOT cover any padding at the 581 end of the parameter. 583 Server ID: 32 bit (unsigned integer) 584 This is the ID of the ENRP server, as defined in 585 [I-D.ietf-rserpool-enrp]. 587 Server Transport: 588 This is an SCTP Transport Parameter, as defined in Section 3.4 589 that contains the network access address(es), SCTP port number, 590 etc. of the ENRP server. 592 3.12. Operation Error Parameter 594 This parameter is used in both ENRP and ASAP for a message sender to 595 report an error(s) to a message receiver. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type = 0xc | Length=variable | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 : : 603 : one or more Error Causes : 604 : : 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Length: 16 bits (unsigned integer) 608 Indicates the entire length of the parameter in number of bytes. 609 Note, the value in Length field will NOT cover any padding at the 610 end of the parameter. 612 Error causes are defined as variable-length parameters using the 613 following format: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Cause Code | Cause Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 : : 621 : Cause-specific Information : 622 : : 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Cause Code: 16 bits (unsigned integer) 625 Defines the type of error condition being reported. 627 +------------------+-----------------------------------------+ 628 | Cause Code Value | Cause Code | 629 +------------------+-----------------------------------------+ 630 | 0x0 | Unspecified Error | 631 | | | 632 | 0x1 | Unrecognized Parameter | 633 | | | 634 | 0x2 | Unrecognized Message | 635 | | | 636 | 0x3 | Invalid Values | 637 | | | 638 | 0x4 | Non-unique PE Identifier | 639 | | | 640 | 0x5 | Inconsistent Pooling Policy | 641 | | | 642 | 0x6 | Lack of Resources | 643 | | | 644 | 0x7 | Inconsistent Transport Type | 645 | | | 646 | 0x8 | Inconsistent Data/Control Configuration | 647 | | | 648 | 0x9 | Unknown Pool Handle | 649 | | | 650 | 0xa | Rejected due to security considerations | 651 | | | 652 | others | reserved by IETF | 653 +------------------+-----------------------------------------+ 655 Table 2 657 Cause Length: 16 bits (unsigned integer) 658 Set to the size of the parameter in bytes, including the Cause 659 Code, Cause Length, and Cause-Specific Information fields, but not 660 including any padding at the end of this error cause TLV. 662 Cause-specific Information: variable length 663 This field carries the details of the error condition. 665 The following subsections (Section 3.12.1 - Section 3.12.9) define 666 specific error causes. 668 3.12.1. Unspecified Error 670 This error cause is used to report an unspecified error by the 671 sender. There is no cause specific information. 673 3.12.2. Unrecognized Parameter Error 675 This error cause is used to report an unrecognized parameter. The 676 complete unrecognized parameter TLV is included as cause specific 677 information. If a message contains multiple unrecognized parameters, 678 multiple error causes are used. 680 3.12.3. Unrecognized Message Error 682 This error cause is used to report an unrecognized message. The 683 unrecognized message TLV is included as cause specific information. 685 3.12.4. Invalid Values Error 687 This error cause is used to report one or more invalid values found 688 in a received parameter. The offending TLV that contains the invalid 689 value(s) is included as cause specific information. 691 3.12.5. Non-unique PE Identifier Error 693 This error cause is used by an ENRP server to indicate to a 694 registering PE that the PE Identifier it chooses has already been 695 used by another PE in the pool. There is no cause specific 696 information. 698 3.12.6. Inconsistent Pool Policy Error 700 This error cause is used by an ENRP server to indicate to a 701 registering PE that the Pool Policy it chooses does not match the 702 overall policy of the pool. A Pool Member Selection Policy TLV (see 703 Section 3.8) that indicates the overall pool policy is included as 704 cause specific information. 706 3.12.7. Lack of Resources Error 708 This error cause is used to indicate that the sender does not have 709 certain resources to perform a requested function. There is no cause 710 specific information. 712 3.12.8. Inconsistent Transport Type Error 714 This error cause is used by an ENRP server to indicate to a 715 registering PE that the User Transport it chooses does not match the 716 overall user transport of the pool. A Transport TLV that indicates 717 the overall pool user transport type is included as cause specific 718 information. 720 3.12.9. Inconsistent Data/Control Configuration Error 722 This error cause is used by an ENRP server to indicate to a 723 registering PE that the Transport Use field in the User Transport it 724 sent in its registration is inconsistent to the pool's overall data/ 725 control channel configuration. There is no cause specific 726 information. 728 3.12.10. Rejected due to security considerations 730 This error cause is used by any endpoint to indicate a rejection of a 731 request due to a failure in security credentials or authorizations. 733 3.12.11. Unknown Pool Handle Error 735 This error cause is used by an ENRP server to indicate to a PE or PU 736 that the requested pool is unknown by the server. There is no cause 737 specific information. 739 3.13. Cookie Parameter 741 This parameter defines a TLV that carries a Cookie. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type = 0xd | Length=variable | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 : : 749 : Cookie : 750 : : 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Length: 16 bits (unsigned integer) 754 Indicates the entire length of the parameter in number of bytes, 755 including the Type, Length, and Cookie. 757 Cookie: variable length The Cookie is an arbitrary byte string of 758 (Length - 4) bytes. 760 3.14. PE Identifier Parameter 762 This parameter defines a TLV that carries a PE Identifier. 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Type = 0xe | Length=0x8 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | PE Identifier | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 PE Identifier: 32 bits (unsigned integer) 773 Uniquely identifies the PE in the pool. The PE picks its 774 identifier when it starts up. See [I-D.ietf-rserpool-asap] for 775 recommendations on PE identifier generation. 777 3.15. PE Checksum Parameter 779 This parameter defines a TLV that carries a PE Checksum. 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Type = 0xf | Length=0x6 | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | PE Checksum | Padding | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 PE Checksum: 16 bits (unsigned integer) 790 An overall checksum of all PEs in the current handlespace owned by 791 an ENRP server (which is normally the sender of this TLV). The 792 definition and calculation of this checksum is defined in 793 [I-D.ietf-rserpool-enrp]. 795 3.16. Opaque Transport Parameter 797 This parameter defines a TLV that carries opaque transport 798 information. 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type = 0x10 | Length=variable | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 : : 806 : Opaque Transport Data : 807 : : 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Length: 16 bits (unsigned integer) 810 Indicates the entire length of the parameter in number of bytes, 811 including the Type, Length, and Opaque Transport Data. 813 Opaque Transport Data: variable length 814 The Opaque Transport Data is an arbitrary byte string of (Length - 815 4) bytes. 817 4. Common Message Formats 819 The figure below illustrates the common format for all ASAP and ENRP 820 messages. Each message is formatted with a Message Type field, a 821 message-specific Flag field, a Message Length field, and a Value 822 field. 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Message Type | Msg Flags | Message Length | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 : : 830 : Message Value : 831 : : 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Message Type: 8 bits (unsigned integer) 835 This field identifies the type of information contained in the 836 Message Value field. It takes a value from 0 to 254. The value 837 of 255 is reserved for future use as an extension field. 838 Message Types are encoded such that the highest-order two bits 839 specify the action that must be taken if the message receiver does 840 not recognize the Message Type. 842 00 Stop processing this message and discard it. 844 01 Stop processing this message and discard it, and report the 845 unrecognized message in an 'Unrecognized Message' error (see 846 Section 3.12.3). 848 10 reserved. 850 11 reserved. 852 Message Flags: 8 bits 853 The usage of these bits depends on the message type as given by 854 the Message Type. Unless otherwise specified, they are set to 855 zero on transmit and are ignored on receipt. 857 Message Length: 16 bits (unsigned integer) 858 This value represents the size of the message in bytes including 859 the Message Type, Message Flags, Message Length, and Message Value 860 fields. Therefore, if the Message Value field is zero-length, the 861 Length field will be set to 4. 862 Note, the value in Message Length field will NOT cover any padding 863 at the end of this message. 865 Message Value: variable length 866 The Message Value field contains the actual information to be 867 transferred in the message. The usage and format of this field is 868 dependent on the Message Type. 869 The total length of a message (including Type, Length and Value 870 fields) MUST be a multiple of 4 bytes. If the length of the 871 message is not a multiple of 4 bytes, the sender MUST pad the 872 message with all zero bytes and this padding is not included in 873 the message length field. The sender should never pad with more 874 than 3 bytes. The receiver MUST ignore the padding bytes. 876 5. IANA Considerations 878 [NOTE to RFC-Editor: 880 "RFCXXXX" is to be replaced by the RFC number you assign this 881 document. 883 ] 885 This document (RFCXXX) is the reference for all registrations 886 described in this section. All registrations need to be listed on an 887 RSerPool specific page. 889 5.1. A New Table for RSerPool Parameter Types 891 RSerPool Parameter Types have to be maintained by IANA. Thirteen 892 initial values should be assigned by IANA as described in Table 1. 893 This requires a new table "RSerPool Parameter Types": 895 +------------+------------------------------+ 896 | Value | Parameter Type | 897 +------------+------------------------------+ 898 | 0x0 | (reserved by IETF) | 899 | | | 900 | 0x1 | IPv4 Address | 901 | | | 902 | 0x2 | IPv6 Address | 903 | | | 904 | 0x3 | DCCP Transport | 905 | | | 906 | 0x4 | SCTP Transport | 907 | | | 908 | 0x5 | TCP Transport | 909 | | | 910 | 0x6 | UDP Transport | 911 | | | 912 | 0x7 | UDP-Lite | 913 | | | 914 | 0x8 | Pool Member Selection Policy | 915 | | | 916 | 0x9 | Pool Handle | 917 | | | 918 | 0xa | Pool Element | 919 | | | 920 | 0xb | Server Information | 921 | | | 922 | 0xc | Operation Error | 923 | | | 924 | 0xd | Cookie | 925 | | | 926 | 0xe | PE Identifier | 927 | | | 928 | 0xf | PE Checksum | 929 | | | 930 | 0x10 | Opaque Transport | 931 | | | 932 | others | (reserved by IETF) | 933 | | | 934 | 0xffffffff | IETF-defined extensions | 935 +------------+------------------------------+ 937 For registering at IANA an RSerPool Parameter Type in this table a 938 request has to be made to assign such a number. This number must be 939 unique. The "Specification Required" policy of [RFC5226] MUST be 940 applied. 942 5.2. A New Table for RSerPool Error Causes 944 RSerPool Error Causes have to be maintained by IANA. Eleven initial 945 values should be assigned by IANA as described in Table 2. This 946 requires a new table "RSerPool Error Causes": 948 +------------------+-----------------------------------------+ 949 | Cause Code Value | Cause Code | 950 +------------------+-----------------------------------------+ 951 | 0x0 | Unspecified Error | 952 | | | 953 | 0x1 | Unrecognized Parameter | 954 | | | 955 | 0x2 | Unrecognized Message | 956 | | | 957 | 0x3 | Invalid Values | 958 | | | 959 | 0x4 | Non-unique PE Identifier | 960 | | | 961 | 0x5 | Inconsistent Pooling Policy | 962 | | | 963 | 0x6 | Lack of Resources | 964 | | | 965 | 0x7 | Inconsistent Transport Type | 966 | | | 967 | 0x8 | Inconsistent Data/Control Configuration | 968 | | | 969 | 0x9 | Unknown Pool Handle | 970 | | | 971 | 0xa | Rejected due to security considerations | 972 | | | 973 | others | reserved by IETF | 974 +------------------+-----------------------------------------+ 976 For registering at IANA an RSerPool Error Cause in this table a 977 request has to be made to assign such a number. This number must be 978 unique. The "Specification Required" policy of [RFC5226] MUST be 979 applied. 981 6. Security Considerations 983 This document contains common parameter formats only. As such it 984 specifies no new security constraints on either ENRP or ASAP. 985 Details on ENRP and ASAP security constraints are addressed in 986 [I-D.ietf-rserpool-enrp] and [I-D.ietf-rserpool-asap]. 988 7. Normative References 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 994 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 995 May 2008. 997 [I-D.ietf-rserpool-asap] 998 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 999 "Aggregate Server Access Protocol (ASAP)", 1000 draft-ietf-rserpool-asap-19 (work in progress), 1001 March 2008. 1003 [I-D.ietf-rserpool-enrp] 1004 Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A. 1005 Silverton, "Endpoint Handlespace Redundancy Protocol 1006 (ENRP)", draft-ietf-rserpool-enrp-19 (work in progress), 1007 March 2008. 1009 [I-D.ietf-rserpool-policies] 1010 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 1011 Policies", draft-ietf-rserpool-policies-08 (work in 1012 progress), March 2008. 1014 Authors' Addresses 1016 Randall R. Stewart 1017 4875 Forest Drive 1018 Suite 200 1019 Columbia, SC 29206 1020 USA 1022 Phone: 1023 Email: randall@lakerest.net 1025 Qiaobing Xie 1026 USA 1028 Phone: +1 224-465-5954 1029 Email: Qiaobing.Xie@gmail.org 1031 Maureen Stillman 1032 Nokia 1033 127 W. State Street 1034 Ithaca, NY 14850 1035 USA 1037 Email: maureen.stillman@nokia.com 1039 Michael Tuexen 1040 Muenster Univ. of Applied Sciences 1041 Stegerwaldstr. 39 1042 48565 Steinfurt 1043 Germany 1045 Email: tuexen@fh-muenster.de 1047 Full Copyright Statement 1049 Copyright (C) The IETF Trust (2008). 1051 This document is subject to the rights, licenses and restrictions 1052 contained in BCP 78, and except as set forth therein, the authors 1053 retain all their rights. 1055 This document and the information contained herein are provided on an 1056 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1057 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1058 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1059 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1060 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1061 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1063 Intellectual Property 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed to 1067 pertain to the implementation or use of the technology described in 1068 this document or the extent to which any license under such rights 1069 might or might not be available; nor does it represent that it has 1070 made any independent effort to identify any such rights. Information 1071 on the procedures with respect to rights in RFC documents can be 1072 found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use of 1077 such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository at 1079 http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. Please address the information to the IETF at 1085 ietf-ipr@ietf.org.