idnits 2.17.1 draft-ietf-rserpool-common-param-18.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 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1086. 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 (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 The Resource Group 4 Intended status: Experimental Q. Xie 5 Expires: January 15, 2009 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 July 14, 2008 12 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 13 Redundancy Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-18.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 January 15, 2009. 41 Abstract 43 This document details the parameters of the Aggregate Server Access 44 Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) 45 protocols defined within the Reliable Server Pooling (RSerPool) 46 architecture. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Parameters in General . . . . . . . . . . . . . . . . . . . . 5 53 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . . . 6 54 3.1. IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 8 55 3.2. IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 8 56 3.3. DCCP Transport Parameter . . . . . . . . . . . . . . . . . 9 57 3.4. SCTP Transport Parameter . . . . . . . . . . . . . . . . . 9 58 3.5. TCP Transport Parameter . . . . . . . . . . . . . . . . . 10 59 3.6. UDP Transport Parameter . . . . . . . . . . . . . . . . . 11 60 3.7. UDP-Lite Transport Parameter . . . . . . . . . . . . . . . 12 61 3.8. Pool Member Selection Policy Parameter . . . . . . . . . . 13 62 3.9. Pool Handle Parameter . . . . . . . . . . . . . . . . . . 13 63 3.10. Pool Element Parameter . . . . . . . . . . . . . . . . . . 14 64 3.11. Server Information Parameter . . . . . . . . . . . . . . . 15 65 3.12. Operation Error Parameter . . . . . . . . . . . . . . . . 16 66 3.12.1. Unspecified Error . . . . . . . . . . . . . . . . . . 17 67 3.12.2. Unrecognized Parameter Error . . . . . . . . . . . . 18 68 3.12.3. Unrecognized Message Error . . . . . . . . . . . . . 18 69 3.12.4. Invalid Values Error . . . . . . . . . . . . . . . . 18 70 3.12.5. Non-unique PE Identifier Error . . . . . . . . . . . 18 71 3.12.6. Inconsistent Pool Policy Error . . . . . . . . . . . 18 72 3.12.7. Lack of Resources Error . . . . . . . . . . . . . . . 18 73 3.12.8. Inconsistent Transport Type Error . . . . . . . . . . 18 74 3.12.9. Inconsistent Data/Control Configuration Error . . . . 19 75 3.12.10. Rejected due to security considerations . . . . . . . 19 76 3.12.11. Unknown Pool Handle Error . . . . . . . . . . . . . . 19 77 3.13. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 19 78 3.14. PE Identifier Parameter . . . . . . . . . . . . . . . . . 19 79 3.15. PE Checksum Parameter . . . . . . . . . . . . . . . . . . 20 80 3.16. Opaque Transport Parameter . . . . . . . . . . . . . . . . 20 81 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 22 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 5.1. A New Table for RSerPool Parameter Types . . . . . . . . . 24 84 5.2. A New Table for RSerPool Error Causes . . . . . . . . . . 26 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 86 7. Normative References . . . . . . . . . . . . . . . . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 88 Intellectual Property and Copyright Statements . . . . . . . . . . 30 90 1. Introduction 92 Aggregate Server Access Protocol (ASAP) [I-D.ietf-rserpool-asap] in 93 conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) 94 [I-D.ietf-rserpool-enrp] provides a high availability data transfer 95 mechanism over IP networks. 97 Both protocols work together and so share many common parameters used 98 in message formats. This document details the common message 99 parameters shared between the two protocols. This document provides 100 parameter formats only, for procedures and message composition please 101 refer to the respective [I-D.ietf-rserpool-asap] and 102 [I-D.ietf-rserpool-enrp] documents. 104 1.1. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Parameters in General 112 All parameters described below MUST be in Network Byte Order (a.k.a. 113 Big Endian, i.e., the most significant byte first) during 114 transmission. 116 Please note that messages in both ENRP and ASAP are often composed of 117 multiple parameters. These parameters may also be nested. In such a 118 case a nested parameter will include the length of the padding 119 between the nested parameters but not the last padding. 121 3. ENRP-ASAP Common Parameters 123 Parameters are defined in the following Type-Length-Value (TLV) 124 format: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Parameter Type | Parameter Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 : : 132 : Parameter Value : 133 : +-------------------------------: 134 : | Padding : 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Parameter Type: 16 bits (unsigned integer) 138 The Type field is a 16 bit identifier of the type of parameter. 139 It takes a value of 0 to 65534. 140 The value of 65535 is reserved for IETF-defined extensions. 141 Values other than those defined in specific ENRP parameter 142 description are reserved by IETF. (Additional types, when needed, 143 will be defined in the future through appropriate IETF/IANA 144 procedures.) 145 The Parameter Types are encoded such that the highest-order two 146 bits specify the action that must be taken if the processing 147 endpoint does not recognize the Parameter Type. 149 00 Stop processing this ENRP or ASAP message and discard it, do 150 not process any further parameters within it. 152 01 Stop processing this ENRP or ASAP message and discard it, do 153 not process any further parameters within it, and report the 154 unrecognized parameter in an 'Unrecognized Parameter' error 155 (see Section 3.12). 157 10 Skip this parameter and continue processing. 159 11 Skip this parameter and continue processing, but report the 160 unrecognized parameter in an 'Unrecognized Parameter' error 161 (see Section 3.12). 163 The values of parameter types are defined as follows: 165 +------------+------------------------------+ 166 | Value | Parameter Type | 167 +------------+------------------------------+ 168 | 0x0 | (reserved by IETF) | 169 | | | 170 | 0x1 | IPv4 Address | 171 | | | 172 | 0x2 | IPv6 Address | 173 | | | 174 | 0x3 | DCCP Transport | 175 | | | 176 | 0x4 | SCTP Transport | 177 | | | 178 | 0x5 | TCP Transport | 179 | | | 180 | 0x6 | UDP Transport | 181 | | | 182 | 0x7 | UDP-Lite | 183 | | | 184 | 0x8 | Pool Member Selection Policy | 185 | | | 186 | 0x9 | Pool Handle | 187 | | | 188 | 0xa | Pool Element | 189 | | | 190 | 0xb | Server Information | 191 | | | 192 | 0xc | Operation Error | 193 | | | 194 | 0xd | Cookie | 195 | | | 196 | 0xe | PE Identifier | 197 | | | 198 | 0xf | PE Checksum | 199 | | | 200 | 0x10 | Opaque Transport | 201 | | | 202 | others | (reserved by IETF) | 203 | | | 204 | 0xffffffff | IETF-defined extensions | 205 +------------+------------------------------+ 207 Table 1 209 Parameter Length: 16 bits (unsigned integer) 210 The Parameter Length field contains the size of the parameter in 211 bytes, including the Parameter Type, Parameter Length, and 212 Parameter Value fields. Thus, a parameter with a zero-length 213 Parameter Value field would have a Length field of 4. 214 The total length of a parameter (including Type, Parameter Length 215 and Value fields) MUST be a multiple of 4 bytes. If the length of 216 the parameter is not a multiple of 4 bytes, the sender MUST pad 217 the parameter at the end (i.e., after the Parameter Value field) 218 with all zero bytes. The length of this padding is not included 219 in the Parameter Length field. A sender MUST NOT pad with more 220 than 3 bytes. The receiver MUST ignore the padding bytes. 222 Parameter Value: variable-length. 223 The Parameter Value field contains the actual information to be 224 transferred in the parameter. 226 Parameter Padding: variable-length. 227 The Parameter Padding as described above. 229 3.1. IPv4 Address Parameter 231 This parameter defines a TLV that carries an IPv4 address. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type = 0x1 | Length = 0x8 | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | IPv4 Address | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 IPv4 Address: 32 bits (unsigned integer) 242 Contains an IPv4 address. It is binary encoded. 244 3.2. IPv6 Address Parameter 246 This parameter defines a TLV that carries an IPv6 address. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 0x2 | Length = 0x14 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 | IPv6 Address | 255 | | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 IPv6 Address: 128 bit (unsigned integer) 260 Contains an IPv6 address. It is binary encoded. 262 3.3. DCCP Transport Parameter 264 This parameter defines a TLV that describes a user transport using 265 DCCP protocol. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type = 0x3 | Length = variable | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | DCCP port | (reserved) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | DCCP service code | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : IPv4 or IPv6 Address : 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Length: 16 bits (unsigned integer) 280 Indicates the entire length of the parameter in number of octets, 281 including the Type, Length, DCCP port, reserved fields, and IP 282 address parameter. 284 DCCP port: 16 bits (unsigned integer) 285 The DCCP port number signed to this DCCP user transport. 287 DCCP service code: 32 bits (unsigned integer) 288 The DCCP service code signed to this DCCP user transport. 290 IPv4 or IPv6 Address 291 Indicates an IPv4 or IPv6 address parameter (as defined above in 292 Section 3.1 and Section 3.2) assigned to this DCCP user transport. 293 Unlike in an SCTP transport parameter, only one IP address 294 parameter can be present in a DCCP transport parameter. 296 Note: A DCCP port MUST NOT be used for control information. For this 297 reason, no Transport Use field is provided. DCCP MUST always be 298 treated as a "Data Only" type transport use. 300 3.4. SCTP Transport Parameter 302 This parameter defines a TLV that describes a user transport using 303 SCTP protocol. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 0x4 | Length = variable | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SCTP port | Transport Use | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 : IPv4 or IPv6 Address #1 : 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 : : 315 : ... : 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 : IPv4 or IPv6 Address #n : 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Length: 16 bits (unsigned integer) 321 Indicates the entire length of the parameter in number of octets, 322 including the Type, Length, SCTP port, reserved fields, and all IP 323 address parameters present. 325 SCTP port: 16 bits (unsigned integer) 326 The SCTP port number signed to this SCTP user transport. 328 Transport use: 16 bits (unsigned integer) 329 This field represents how the pool element intends this transport 330 address to be used. The field MUST be populated with one of the 331 following values: 333 +-------------------+--------+ 334 | Type | Value | 335 +-------------------+--------+ 336 | DATA ONLY | 0x0000 | 337 | | | 338 | DATA plus CONTROL | 0x0001 | 339 +-------------------+--------+ 341 IPv4 or IPv6 Address #1 - #n 342 Each indicates an IPv4 or IPv6 address parameter (as defined above 343 in Section 3.1 and Section 3.2) assigned to this SCTP user 344 transport. An SCTP Transport parameter may have a mixed list of 345 IPv4 and IPv6 addresses and at least one IP address parameter MUST 346 be present in an SCTP transport parameter. 348 3.5. TCP Transport Parameter 350 This parameter defines a TLV that describes a user transport using 351 TCP protocol. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type = 0x5 | Length = variable | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | TCP port | (reserved) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 : IPv4 or IPv6 Address : 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Length: 16 bits (unsigned integer) 364 Indicates the entire length of the parameter in number of octets, 365 including the Type, Length, TCP port, reserved fields, and IP 366 address parameter. 368 TCP port: 16 bits (unsigned integer) 369 The TCP port number signed to this TCP user transport. 371 IPv4 or IPv6 Address 372 Indicates an IPv4 or IPv6 address parameter (as defined above in 373 Section 3.1 and Section 3.2) assigned to this TCP user transport. 374 Unlike in an SCTP transport parameter, only one IP address 375 parameter can be present in a TCP transport parameter. 377 Note: A TCP port MUST NOT be used for control information. For this 378 reason, no Transport Use field is provided. TCP MUST always be 379 treated as a "Data Only" type transport use. 381 3.6. UDP Transport Parameter 383 This parameter defines a TLV that describes a user transport using 384 UDP protocol. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type = 0x6 | Length = variable | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | UDP port | (reserved) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 : IPv4 or IPv6 Address : 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Length: 16 bits (unsigned integer) 397 Indicates the entire length of the parameter in number of octets, 398 including the Type, Length, UDP port, reserved fields, and IP 399 address parameter. 401 UDP port: 16 bits (unsigned integer) 402 The UDP port number signed to this UDP user transport. 404 IPv4 or IPv6 Address 405 Indicates an IPv4 or IPv6 address parameter (as defined above in 406 Section 3.1 and Section 3.2) assigned to this UDP user transport. 407 Unlike in an SCTP transport parameter, only one IP address 408 parameter can be present in a UDP transport parameter. 410 Note: A UDP port MUST NOT be used for control information. For this 411 reason, no Transport Use field is provided. UDP MUST always be 412 treated as a "Data Only" type transport use. 414 3.7. UDP-Lite Transport Parameter 416 This parameter defines a TLV that describes a user transport using 417 UDP-Lite protocol. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = 0x7 | Length = variable | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | UDP-Lite port | (reserved) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 : IPv4 or IPv6 Address : 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Length: 16 bits (unsigned integer) 430 Indicates the entire length of the parameter in number of octets, 431 including the Type, Length, UDP-Lite port, reserved fields, and IP 432 address parameter. 434 UDP port: 16 bits (unsigned integer) 435 The UDP-Lite port number signed to this UDP-Lite user transport. 437 IPv4 or IPv6 Address 438 Indicates an IPv4 or IPv6 address parameter (as defined above in 439 Section 3.1 and Section 3.2) assigned to this UDP-Lite user 440 transport. Unlike in an SCTP transport parameter, only one IP 441 address parameter can be present in a UDP-Lite transport 442 parameter. 444 Note: A UDP-Lite port MUST NOT be used for control information. For 445 this reason, no Transport Use field is provided. UDP-Lite MUST 446 always be treated as a "Data Only" type transport use. 448 3.8. Pool Member Selection Policy Parameter 450 This parameter defines a pool member selection policy. RSerPool 451 supports multiple pool member selection policies and also allows 452 definition of new selection policies in the future. 454 The enforcement rules and handling procedures of all the policies are 455 defined in [I-D.ietf-rserpool-asap]. 457 All pool member selection policies, both present and future, MUST use 458 the following general parameter format: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type = 0x8 | Length = variable | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Policy Type | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Policy-specific Data | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Length: 16 bits (unsigned integer) 471 Indicates the entire length of the parameter in number of octets, 472 including the Type, Length, Policy Type, and the Policy-specific 473 Data fields. 474 Note, the Length field value will NOT include any padding at the 475 end of the parameter. 477 Policy Type: 32 bits (unsigned integer) 478 Specifies the type of selection policy. The values are defined in 479 [I-D.ietf-rserpool-policies]. 481 Policy-specific Data: 482 The structure and fields for each presently defined policy type 483 are described in detail in [I-D.ietf-rserpool-policies]. 485 3.9. Pool Handle Parameter 487 This parameter holds a pool handle. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type = 0x9 | Length=variable | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 : : 495 : Pool Handle : 496 : : 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Length: 16 bits (unsigned integer) 500 Indicates the entire length of the parameter in number of octets, 501 including the Type, Length, and Pool Handle string. 502 Note, the value in Length field will NOT cover any padding at the 503 end of the parameter. 505 Pool Handle 506 defined as a sequence of (Length - 4) bytes. 508 3.10. Pool Element Parameter 510 This parameter is used in multiple ENRP messages to represent an ASAP 511 endpoint (i.e., a PE in a pool) and the associated information, such 512 as its transport address, selection policy, and other operational or 513 status information of the PE. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type = 0xa | Length=variable | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | PE Identifier | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Home ENRP Server Identifier | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Registration Life | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 : User Transport param : 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 : Member Selection Policy param : 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 : ASAP Transport param : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Length: 16 bits (unsigned integer) 533 Indicates the entire length of the parameter in number of octets, 534 including the Type, Length, PE Identifier, Registration Life, User 535 Transport, and Member Selection Policy parameters. 536 Note, the value in Length field will NOT cover any padding at the 537 end of this Pool Element parameter. 539 PE Identifier: 32 bits (unsigned integer) 540 Uniquely identifies the PE in the pool. The PE picks its 541 identifier when it starts up. 543 Home ENRP Server Identifier: 32 bits (unsigned integer) 544 Indicates the current home ENRP server of this PE. Set to all 0's 545 if the PE's home ENRP server is undetermined. 547 Registration Life: 32 bits (signed integer) 548 Indicates the life time of the registration in number of seconds. 549 A value of -1 indicates infinite life time. 551 User Transport 552 This can be either an DCCP, SCTP, TCP, UDP, UDP-Lite, or Opaque 553 transport parameter (see Section 3.3, Section 3.4, Section 3.5, 554 Section 3.6, Section 3.7, Section 3.16). A PE MUST have one and 555 only one User Transport. 557 Member Selection Policy 558 Contains one of the defined member selection policy parameters 559 (see Section 3.8). 561 ASAP Transport 562 This indicates the ASAP transport address of the PE and MUST be an 563 SCTP type transport parameter (see Section 3.4). 565 3.11. Server Information Parameter 567 This parameter is used in ENRP to pass basic information of an ENRP 568 server. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type = 0xb | Length=variable | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Server ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 : Server Transport : 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Length: 16 bits (unsigned integer) 580 Indicates the entire length of the parameter in number of bytes. 581 Note, the value in Length field will NOT cover any padding at the 582 end of the parameter. 584 Server ID: 32 bit (unsigned integer) 585 This is the ID of the ENRP server, as defined in 586 [I-D.ietf-rserpool-enrp]. 588 Server Transport: 589 This is an SCTP Transport Parameter, as defined in Section 3.4 590 that contains the network access address(es), SCTP port number, 591 etc. of the ENRP server. 593 3.12. Operation Error Parameter 595 This parameter is used in both ENRP and ASAP for a message sender to 596 report an error(s) to a message receiver. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type = 0xc | Length=variable | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 : : 604 : one or more Error Causes : 605 : : 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Length: 16 bits (unsigned integer) 609 Indicates the entire length of the parameter in number of bytes. 610 Note, the value in Length field will NOT cover any padding at the 611 end of the parameter. 613 Error causes are defined as variable-length parameters using the 614 following format: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Cause Code | Cause Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 : : 622 : Cause-specific Information : 623 : : 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Cause Code: 16 bits (unsigned integer) 626 Defines the type of error condition being reported. 628 +------------------+-----------------------------------------+ 629 | Cause Code Value | Cause Code | 630 +------------------+-----------------------------------------+ 631 | 0x0 | Unspecified Error | 632 | | | 633 | 0x1 | Unrecognized Parameter | 634 | | | 635 | 0x2 | Unrecognized Message | 636 | | | 637 | 0x3 | Invalid Values | 638 | | | 639 | 0x4 | Non-unique PE Identifier | 640 | | | 641 | 0x5 | Inconsistent Pooling Policy | 642 | | | 643 | 0x6 | Lack of Resources | 644 | | | 645 | 0x7 | Inconsistent Transport Type | 646 | | | 647 | 0x8 | Inconsistent Data/Control Configuration | 648 | | | 649 | 0x9 | Unknown Pool Handle | 650 | | | 651 | 0xa | Rejected due to security considerations | 652 | | | 653 | others | reserved by IETF | 654 +------------------+-----------------------------------------+ 656 Table 2 658 Cause Length: 16 bits (unsigned integer) 659 Set to the size of the parameter in bytes, including the Cause 660 Code, Cause Length, and Cause-Specific Information fields, but not 661 including any padding at the end of this error cause TLV. 663 Cause-specific Information: variable length 664 This field carries the details of the error condition. 666 The following subsections (Section 3.12.1 - Section 3.12.9) define 667 specific error causes. 669 3.12.1. Unspecified Error 671 This error cause is used to report an unspecified error by the 672 sender. There is no cause specific information. 674 3.12.2. Unrecognized Parameter Error 676 This error cause is used to report an unrecognized parameter. The 677 complete unrecognized parameter TLV is included as cause specific 678 information. If a message contains multiple unrecognized parameters, 679 multiple error causes are used. 681 3.12.3. Unrecognized Message Error 683 This error cause is used to report an unrecognized message. The 684 unrecognized message TLV is included as cause specific information. 686 3.12.4. Invalid Values Error 688 This error cause is used to report one or more invalid values found 689 in a received parameter. The offending TLV that contains the invalid 690 value(s) is included as cause specific information. 692 3.12.5. Non-unique PE Identifier Error 694 This error cause is used by an ENRP server to indicate to a 695 registering PE that the PE Identifier it chooses has already been 696 used by another PE in the pool. There is no cause specific 697 information. 699 3.12.6. Inconsistent Pool Policy Error 701 This error cause is used by an ENRP server to indicate to a 702 registering PE that the Pool Policy it chooses does not match the 703 overall policy of the pool. A Pool Member Selection Policy TLV (see 704 Section 3.8) that indicates the overall pool policy is included as 705 cause specific information. 707 3.12.7. Lack of Resources Error 709 This error cause is used to indicate that the sender does not have 710 certain resources to perform a requested function. There is no cause 711 specific information. 713 3.12.8. Inconsistent Transport Type Error 715 This error cause is used by an ENRP server to indicate to a 716 registering PE that the User Transport it chooses does not match the 717 overall user transport of the pool. A Transport TLV that indicates 718 the overall pool user transport type is included as cause specific 719 information. 721 3.12.9. Inconsistent Data/Control Configuration Error 723 This error cause is used by an ENRP server to indicate to a 724 registering PE that the Transport Use field in the User Transport it 725 sent in its registration is inconsistent to the pool's overall data/ 726 control channel configuration. There is no cause specific 727 information. 729 3.12.10. Rejected due to security considerations 731 This error cause is used by any endpoint to indicate a rejection of a 732 request due to a failure in security credentials or authorizations. 734 3.12.11. Unknown Pool Handle Error 736 This error cause is used by an ENRP server to indicate to a PE or PU 737 that the requested pool is unknown by the server. There is no cause 738 specific information. 740 3.13. Cookie Parameter 742 This parameter defines a TLV that carries a Cookie. 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Type = 0xd | Length=variable | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 : : 750 : Cookie : 751 : : 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Length: 16 bits (unsigned integer) 755 Indicates the entire length of the parameter in number of bytes, 756 including the Type, Length, and Cookie. 758 Cookie: variable length The Cookie is an arbitrary byte string of 759 (Length - 4) bytes. 761 3.14. PE Identifier Parameter 763 This parameter defines a TLV that carries a PE Identifier. 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Type = 0xe | Length=0x8 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | PE Identifier | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 PE Identifier: 32 bits (unsigned integer) 774 Uniquely identifies the PE in the pool. The PE picks its 775 identifier when it starts up. See [I-D.ietf-rserpool-asap] for 776 recommendations on PE identifier generation. 778 3.15. PE Checksum Parameter 780 This parameter defines a TLV that carries a PE Checksum. 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Type = 0xf | Length=0x6 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | PE Checksum | Padding | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 PE Checksum: 16 bits (unsigned integer) 791 An overall checksum of all PEs in the current handlespace owned by 792 an ENRP server (which is normally the sender of this TLV). The 793 definition and calculation of this checksum is defined in 794 [I-D.ietf-rserpool-enrp]. 796 3.16. Opaque Transport Parameter 798 This parameter defines a TLV that carries opaque transport 799 information. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type = 0x10 | Length=variable | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 : : 807 : Opaque Transport Data : 808 : : 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Length: 16 bits (unsigned integer) 811 Indicates the entire length of the parameter in number of bytes, 812 including the Type, Length, and Opaque Transport Data. 814 Opaque Transport Data: variable length 815 The Opaque Transport Data is an arbitrary byte string of (Length - 816 4) bytes. 818 4. Common Message Formats 820 The figure below illustrates the common format for all ASAP and ENRP 821 messages. Each message is formatted with a Message Type field, a 822 message-specific Flag field, a Message Length field, and a Value 823 field. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Message Type | Msg Flags | Message Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 : : 831 : Message Value : 832 : : 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Message Type: 8 bits (unsigned integer) 836 This field identifies the type of information contained in the 837 Message Value field. It takes a value from 0 to 254. The value 838 of 255 is reserved for future use as an extension field. 839 Message Types are encoded such that the highest-order two bits 840 specify the action that must be taken if the message receiver does 841 not recognize the Message Type. 843 00 Stop processing this message and discard it. 845 01 Stop processing this message and discard it, and report the 846 unrecognized message in an 'Unrecognized Message' error (see 847 Section 3.12.3). 849 10 reserved. 851 11 reserved. 853 Message Flags: 8 bits 854 The usage of these bits depends on the message type as given by 855 the Message Type. Unless otherwise specified, they are set to 856 zero on transmit and are ignored on receipt. 858 Message Length: 16 bits (unsigned integer) 859 This value represents the size of the message in bytes including 860 the Message Type, Message Flags, Message Length, and Message Value 861 fields. Therefore, if the Message Value field is zero-length, the 862 Length field will be set to 4. 863 Note, the value in Message Length field will NOT cover any padding 864 at the end of this message. 866 Message Value: variable length 867 The Message Value field contains the actual information to be 868 transferred in the message. The usage and format of this field is 869 dependent on the Message Type. 870 The total length of a message (including Type, Length and Value 871 fields) MUST be a multiple of 4 bytes. If the length of the 872 message is not a multiple of 4 bytes, the sender MUST pad the 873 message with all zero bytes and this padding is not included in 874 the message length field. The sender should never pad with more 875 than 3 bytes. The receiver MUST ignore the padding bytes. 877 5. IANA Considerations 879 [NOTE to RFC-Editor: 881 "RFCXXXX" is to be replaced by the RFC number you assign this 882 document. 884 ] 886 This document (RFCXXX) is the reference for all registrations 887 described in this section. All registrations need to be listed on an 888 RSerPool specific page. 890 5.1. A New Table for RSerPool Parameter Types 892 RSerPool Parameter Types have to be maintained by IANA. Thirteen 893 initial values should be assigned by IANA as described in Table 1. 894 This requires a new table "RSerPool Parameter Types": 896 +------------+------------------------------+ 897 | Value | Parameter Type | 898 +------------+------------------------------+ 899 | 0x0 | (reserved by IETF) | 900 | | | 901 | 0x1 | IPv4 Address | 902 | | | 903 | 0x2 | IPv6 Address | 904 | | | 905 | 0x3 | DCCP Transport | 906 | | | 907 | 0x4 | SCTP Transport | 908 | | | 909 | 0x5 | TCP Transport | 910 | | | 911 | 0x6 | UDP Transport | 912 | | | 913 | 0x7 | UDP-Lite | 914 | | | 915 | 0x8 | Pool Member Selection Policy | 916 | | | 917 | 0x9 | Pool Handle | 918 | | | 919 | 0xa | Pool Element | 920 | | | 921 | 0xb | Server Information | 922 | | | 923 | 0xc | Operation Error | 924 | | | 925 | 0xd | Cookie | 926 | | | 927 | 0xe | PE Identifier | 928 | | | 929 | 0xf | PE Checksum | 930 | | | 931 | 0x10 | Opaque Transport | 932 | | | 933 | others | (reserved by IETF) | 934 | | | 935 | 0xffffffff | IETF-defined extensions | 936 +------------+------------------------------+ 938 For registering at IANA an RSerPool Parameter Type in this table a 939 request has to be made to assign such a number. This number must be 940 unique. The "Specification Required" policy of [RFC5226] MUST be 941 applied. 943 5.2. A New Table for RSerPool Error Causes 945 RSerPool Error Causes have to be maintained by IANA. Eleven initial 946 values should be assigned by IANA as described in Table 2. This 947 requires a new table "RSerPool Error Causes": 949 +------------------+-----------------------------------------+ 950 | Cause Code Value | Cause Code | 951 +------------------+-----------------------------------------+ 952 | 0x0 | Unspecified Error | 953 | | | 954 | 0x1 | Unrecognized Parameter | 955 | | | 956 | 0x2 | Unrecognized Message | 957 | | | 958 | 0x3 | Invalid Values | 959 | | | 960 | 0x4 | Non-unique PE Identifier | 961 | | | 962 | 0x5 | Inconsistent Pooling Policy | 963 | | | 964 | 0x6 | Lack of Resources | 965 | | | 966 | 0x7 | Inconsistent Transport Type | 967 | | | 968 | 0x8 | Inconsistent Data/Control Configuration | 969 | | | 970 | 0x9 | Unknown Pool Handle | 971 | | | 972 | 0xa | Rejected due to security considerations | 973 | | | 974 | others | reserved by IETF | 975 +------------------+-----------------------------------------+ 977 For registering at IANA an RSerPool Error Cause in this table a 978 request has to be made to assign such a number. This number must be 979 unique. The "Specification Required" policy of [RFC5226] MUST be 980 applied. 982 6. Security Considerations 984 This document contains common parameter formats only. As such it 985 specifies no new security constraints on either ENRP or ASAP. 986 Details on ENRP and ASAP security constraints are addressed in 987 [I-D.ietf-rserpool-enrp] and [I-D.ietf-rserpool-asap]. 989 7. Normative References 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, March 1997. 994 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 995 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 996 May 2008. 998 [I-D.ietf-rserpool-asap] 999 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 1000 "Aggregate Server Access Protocol (ASAP)", 1001 draft-ietf-rserpool-asap-21 (work in progress), July 2008. 1003 [I-D.ietf-rserpool-enrp] 1004 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 1005 Silverton, "Endpoint Handlespace Redundancy Protocol 1006 (ENRP)", draft-ietf-rserpool-enrp-21 (work in progress), 1007 July 2008. 1009 [I-D.ietf-rserpool-policies] 1010 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 1011 Policies", draft-ietf-rserpool-policies-10 (work in 1012 progress), July 2008. 1014 Authors' Addresses 1016 Randall R. Stewart 1017 The Resource Group 1018 1700 Pennsylvania Ave NW 1019 Suite 56 1020 Washington, DC 20006 1021 USA 1023 Phone: 1024 Email: randall.stewart@trgworld.com 1026 Qiaobing Xie 1027 USA 1029 Phone: +1 224-465-5954 1030 Email: Qiaobing.Xie@gmail.org 1032 Maureen Stillman 1033 Nokia 1034 127 W. State Street 1035 Ithaca, NY 14850 1036 USA 1038 Email: maureen.stillman@nokia.com 1040 Michael Tuexen 1041 Muenster Univ. of Applied Sciences 1042 Stegerwaldstr. 39 1043 48565 Steinfurt 1044 Germany 1046 Email: tuexen@fh-muenster.de 1048 Full Copyright Statement 1050 Copyright (C) The IETF Trust (2008). 1052 This document is subject to the rights, licenses and restrictions 1053 contained in BCP 78, and except as set forth therein, the authors 1054 retain all their rights. 1056 This document and the information contained herein are provided on an 1057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1059 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1060 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1061 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Intellectual Property 1066 The IETF takes no position regarding the validity or scope of any 1067 Intellectual Property Rights or other rights that might be claimed to 1068 pertain to the implementation or use of the technology described in 1069 this document or the extent to which any license under such rights 1070 might or might not be available; nor does it represent that it has 1071 made any independent effort to identify any such rights. Information 1072 on the procedures with respect to rights in RFC documents can be 1073 found in BCP 78 and BCP 79. 1075 Copies of IPR disclosures made to the IETF Secretariat and any 1076 assurances of licenses to be made available, or the result of an 1077 attempt made to obtain a general license or permission for the use of 1078 such proprietary rights by implementers or users of this 1079 specification can be obtained from the IETF on-line IPR repository at 1080 http://www.ietf.org/ipr. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights that may cover technology that may be required to implement 1085 this standard. Please address the information to the IETF at 1086 ietf-ipr@ietf.org.