idnits 2.17.1 draft-ietf-rserpool-common-param-11.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 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 990. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 681 has weird spacing: '... values res...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 17, 2006) is 6400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ASAP' on line 556 == Unused Reference: '1' is defined on line 900, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-12 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-12 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: Informational Q. Xie 5 Expires: April 20, 2007 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 October 17, 2006 12 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 13 Redundancy Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-11.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 April 20, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . 6 59 3.2. IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 60 3.3. SCTP Transport Parameter . . . . . . . . . . . . . . . . . 7 61 3.4. TCP Transport Parameter . . . . . . . . . . . . . . . . . 9 62 3.5. UDP Transport Parameter . . . . . . . . . . . . . . . . . 9 63 3.6. Pool Member Selection Policy Parameter . . . . . . . . . . 10 64 3.6.1. Round Robin Policy . . . . . . . . . . . . . . . . . 12 65 3.6.2. Least Used Policy . . . . . . . . . . . . . . . . . . 12 66 3.6.3. Least Used with Degradation Policy . . . . . . . . . 12 67 3.6.4. Weighted Round Robin Policy . . . . . . . . . . . . . 13 68 3.7. Pool Handle Parameter . . . . . . . . . . . . . . . . . . 13 69 3.8. Pool Element Parameter . . . . . . . . . . . . . . . . . . 14 70 3.9. Server Information Parameter . . . . . . . . . . . . . . . 15 71 3.10. Operation Error Parameter . . . . . . . . . . . . . . . . 16 72 3.10.1. Unspecified Error . . . . . . . . . . . . . . . . . . 17 73 3.10.2. Unrecognized Parameter Error . . . . . . . . . . . . 17 74 3.10.3. Unrecognized Message Error . . . . . . . . . . . . . 17 75 3.10.4. Invalid Values Error . . . . . . . . . . . . . . . . 18 76 3.10.5. Non-unique PE Identifier Error . . . . . . . . . . . 18 77 3.10.6. Inconsistent Pool Policy Error . . . . . . . . . . . 18 78 3.10.7. Lack of Resources Error . . . . . . . . . . . . . . . 18 79 3.10.8. Inconsistent Transport Type Error . . . . . . . . . . 18 80 3.10.9. Inconsistent Data/Control Configuration Error . . . . 18 81 3.10.10. Rejected due to security considerations . . . . . . . 18 82 3.10.11. Unknown Poor Handle Error . . . . . . . . . . . . . . 19 83 3.11. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 19 84 3.12. PE Identifier Parameter . . . . . . . . . . . . . . . . . 19 85 3.13. PE Checksum Parameter . . . . . . . . . . . . . . . . . . 20 86 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 21 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 6. Normative References . . . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 90 Intellectual Property and Copyright Statements . . . . . . . . . . 26 92 1. Introduction 94 Aggregate Server Access Protocol (ASAP) [3] in conjunction with the 95 Endpoint Handlespace Redundancy Protocol (ENRP) [4] provides a high 96 availability data transfer mechanism over IP networks. 98 Both protocols work together and so share many common parameters used 99 in message formats. This document details the common message 100 parameters shared between the two protocols. This document provides 101 parameter formats only, for procedures and message composition please 102 refer to the respective ASAP [3] and ENRP [4] documents. 104 1.1. Conventions 106 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 107 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 108 they appear in this document, are to be interpreted as described in 109 RFC2119 [2]. 111 2. Parameters in General 113 All parameters described below MUST be in Network Byte Order (a.k.a. 114 Big Endian, i.e., the most significant byte first) during 115 transmission. 117 Please note that messages in both ENRP and ASAP are often composed of 118 multiple parameters. These parameters may also be nested. In such a 119 case a nested parameter will include the length of the padding 120 between the nested parameters but not the last padding. 122 3. ENRP-ASAP Common Parameters 124 Parameters are defined in the following Type-Length-Value (TLV) 125 format: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Parameter Type | Parameter Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 : : 133 : Parameter Value : 134 : : 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Parameter Type: 16 bits (unsigned integer) 139 The Type field is a 16 bit identifier of the type of parameter. It 140 takes a value of 0 to 65534. 142 The value of 65535 is reserved for IETF-defined extensions. Values 143 other than those defined in specific ENRP parameter description are 144 reserved by IETF. (Additional types, when needed, will be defined in 145 the future through appropriate IETF/IANA procedures.) 147 The Parameter Types are encoded such that the highest-order two bits 148 specify the action that must be taken if the processing endpoint does 149 not recognize the Parameter Type. 151 00 Stop processing this ENRP or ASAP message and discard it, do not 152 process any further parameters within it. 154 01 Stop processing this ENRP or ASAP message and discard it, do not 155 process any further parameters within it, and report the 156 unrecognized parameter in an 'Unrecognized Parameter' error (see 157 Section 3.10). 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 (see 163 Section 3.10). 165 The values of parameter types are defined as follows: 167 Value Parameter Type 168 ----- ---------- 169 0x0 - (reserved by IETF) 170 0x1 - IPv4 Address 171 0x2 - IPv6 Address 172 0x3 - SCTP Transport 173 0x4 - TCP Transport 174 0x5 - UDP Transport 175 0x6 - Pool Member Selection Policy 176 0x7 - Pool Handle 177 0x8 - Pool Element 178 0x9 - Server Information 179 0xa - Operation Error 180 0xb - Cookie 181 0xc - PE Identifier 182 0xd - PE Checksum 184 others - (reserved by IETF) 186 Parameter Length: 16 bits (unsigned integer) 188 The Parameter Length field contains the size of the parameter in 189 bytes, including the Parameter Type, Parameter Length, and Parameter 190 Value fields. Thus, a parameter with a zero-length Parameter Value 191 field would have a Length field of 4. 193 The total length of a parameter (including Type, Parameter Length and 194 Value fields) MUST be a multiple of 4 bytes. If the length of the 195 parameter is not a multiple of 4 bytes, the sender MUST pad the 196 parameter at the end (i.e., after the Parameter Value field) with all 197 zero bytes. The length of this padding is not included in the 198 Parameter Length field. A sender MUST NOT pad with more than 3 199 bytes. The receiver MUST ignore the padding bytes. 201 (Editor's note: clarify further that any padding inside in the 202 parameter, such as the padding in sub-param is included in the total 203 length) 205 Parameter Value: variable-length. 207 The Parameter Value field contains the actual information to be 208 transferred in the parameter. 210 3.1. IPv4 Address Parameter 212 This parameter defines a TLV that carries an IPv4 address. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type = 0x1 | Length = 0x8 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | IPv4 Address | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 IPv4 Address: 32 bits (unsigned integer) 224 Contains an IPv4 address. It is binary encoded. 226 3.2. IPv6 Address Parameter 228 This parameter defines a TLV that carries an IPv6 address. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type = 0x2 | Length = 0x14 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 | IPv6 Address | 237 | | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 IPv6 Address: 128 bit (unsigned integer) 243 Contains an IPv6 address. It is binary encoded. 245 3.3. SCTP Transport Parameter 247 This parameter defines a TLV that describes a user transport using 248 SCTP protocol. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type = 0x3 | Length = variable | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | SCTP port | Transport Use | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 : IPv4 or IPv6 Address #1 : 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 : : 260 : ... : 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 : IPv4 or IPv6 Address #n : 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Length: 16 bits (unsigned integer) 267 Indicates the entire length of the parameter in number of octets, 268 including the Type, Length, SCTP port, reserved fields, and all IP 269 address parameters present. 271 SCTP port: 16 bits (unsigned integer) 273 The SCTP port number signed to this SCTP user transport. 275 Transport use: 16 bits (unsigned integer) 277 This field represents how the pool element intends this transport 278 address to be used. The field MUST be populated with one of the 279 following values: 281 Type | Value 282 ------------------+---------------- 283 DATA ONLY | 0x0000 284 DATA plus CONTROL | 0x0001 286 IPv4 or IPv6 Address #1 - #n: 288 Each indicates an IPv4 or IPv6 address parameter (as defined above in 289 Section 3.1 and Section 3.2) assigned to this SCTP user transport. 290 An SCTP Transport parameter may have a mixed list of IPv4 and IPv6 291 addresses and at least one IP address parameter MUST be present in an 292 SCTP transport parameter. 294 3.4. TCP Transport Parameter 296 This parameter defines a TLV that describes a user transport using 297 TCP protocol. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type = 0x4 | Length = variable | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | TCP port | Transport Use | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 : IPv4 or IPv6 Address : 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Length: 16 bits (unsigned integer) 311 Indicates the entire length of the parameter in number of octets, 312 including the Type, Length, TCP port, reserved fields, and IP address 313 parameter. 315 TCP port: 16 bits (unsigned integer) 317 The TCP port number signed to this TCP user transport. 319 Transport use: 16 bits (unsigned integer) 321 This field represents how the pool element intends this transport 322 address to be used. The field MUST be populated with one of the 323 following values: 325 Type | Value 326 ------------------+---------------- 327 DATA ONLY | 0x0000 328 DATA plus CONTROL | 0x0001 330 IPv4 or IPv6 Address: 332 Indicates an IPv4 or IPv6 address parameter (as defined above in 333 Section 3.1 and Section 3.2) assigned to this TCP user transport. 334 Unlike in an SCTP transport, only one IP address parameter can be 335 present in a TCP transport parameter. 337 3.5. UDP Transport Parameter 339 This parameter defines a TLV that describes a user transport using 340 UDP protocol. 342 0 1 2 3 343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = 0x5 | Length = variable | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | UDP port | (reserved) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 : IPv4 or IPv6 Address : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Length: 16 bits (unsigned integer) 354 Indicates the entire length of the parameter in number of octets, 355 including the Type, Length, UDP port, reserved fields, and IP address 356 parameter. 358 UDP port: 16 bits (unsigned integer) 360 The UDP port number signed to this UDP user transport. 362 IPv4 or IPv6 Address: 364 Indicates an IPv4 or IPv6 address parameter (as defined above in 365 Section 3.1 and Section 3.2) assigned to this UDP user transport. 366 Unlike in an SCTP transport, only one IP address parameter can be 367 present in a UDP transport parameter. 369 Note: A UDP port MUST NOT be used for control information. For this 370 reason, no Transport Use field is provided. UDP MUST always be 371 treated as a "Data Only" type transport use. 373 3.6. Pool Member Selection Policy Parameter 375 This parameter defines a pool member selection policy. RSERPOOL 376 supports multiple pool member selection policies and also allows 377 definition of new selection policies in the future. 379 The enforcement rules and handling procedures of all the policies are 380 defined in Section xxxxx in ASAP [3]. 382 All pool member selection policies, both present and future, MUST use 383 the following general parameter format: 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 | Policy Type | Reserved | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Policy-specific Data | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Length: 16 bits (unsigned integer) 397 Indicates the entire length of the parameter in number of octets, 398 including the Type, Length, Policy Type, and the Policy-specific Data 399 fields. 401 Note, the Length field value will NOT include any padding at the end 402 of the parameter. 404 Policy Type: 8 bits (unsigned integer) 406 Specifies the type of selection policy. 408 Currently defined policy types are: 410 Value Policy 411 ----- --------- 412 0x0 (reserved by IETF) 413 0x1 Round Robin 414 0x2 Least Used 415 0x3 Least Used with Degradation (a.k.a. dog pile) 416 0x4 Weighted Round Robin 417 others (reserved by IETF) 419 Policy-specific Data: 421 The structure and fields for each presently defined policy types are 422 described in detail in the following subsections. The enforcement 423 rules and handling procedures of these policies are defined in 424 Section xxxxx in ASAP [3]. 426 3.6.1. Round Robin Policy 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Param Type = 0x6 | Length = 0x8 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Policy=0x1 | (reserved) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 436 Reserved: 24 bits 438 MUST be set to 0's by sender and ignored by the receiver. 440 3.6.2. Least Used Policy 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Param Type = 0x6 | Length = 0x8 | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Policy=0x2 | Reserved | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Load | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Reserved: 24 bits 454 Load: 32 bits (signed integer) 456 (TBD) 458 3.6.3. Least Used with Degradation Policy 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 | Param Type = 0x6 | Length = 0x8 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Policy=0x3 | Reserved | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Load | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Reserved: 24 bits 472 Load: 32 bits (signed integer) 473 (TBD) 475 3.6.4. Weighted Round Robin Policy 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Param Type = 0x6 | Length = 0x8 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Policy=0x4 | Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Weight | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Reserved: 24 bits 489 Load: 32 bits (signed integer) 491 (TBD) 493 3.7. Pool Handle Parameter 495 This parameter holds a pool handle. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type = 0x7 | Length=variable | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 : : 503 : Pool Handle : 504 : : 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Length: 16 bits (unsigned integer) 509 Indicates the entire length of the parameter in number of octets, 510 including the Type, Length, and Pool Handle string. 512 Note, the value in Length field will NOT cover any padding at the end 513 of the parameter. 515 Pool Handle: 517 defined as a sequence of (Length - 4) bytes. 519 3.8. Pool Element Parameter 521 This parameter is used in multiple ENRP messages to represent an ASAP 522 endpoint (i.e., a PE in a pool) and the associated information, such 523 as its transport address, selection policy, and other operational or 524 status information of the PE. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type = 0x8 | Length=variable | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | PE Identifier | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Home ENRP Server Identifier | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Registration Life | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 : User Transport param : 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 : Member Selection Policy param : 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 : ASAP Transport param : 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Length: 16 bits (unsigned integer) 546 Indicates the entire length of the parameter in number of octets, 547 including the Type, Length, PE Identifier, Registration Life, User 548 Transport, and Member Selection Policy parameters. 550 Note, the value in Length field will NOT cover any padding at the end 551 of this Pool Element parameter. 553 PE Identifier: 32 bits (unsigned integer) 555 Uniquely identifies the PE in the pool. The PE picks its identifier 556 when it starts up. See Section ???? in [ASAP] for recommendations on 557 PE identifier generation. 559 Home ENRP Server Identifier: 32 bits (unsigned integer) 561 Indicates the current home ENRP server of this PE. Set to all 0's if 562 the PE's home ENRP server is undetermined. 564 Registration Life: 32 bits (signed integer) 566 Indicates the life time of the registration in number of seconds. A 567 value of -1 indicates infinite life time. 569 User Transport: 571 This can be either an SCTP, TCP, or UDP type transport parameter (see 572 Section 3.3, Section 3.4, Section 3.5). A PE MUST have one and only 573 one User Transport. 575 Member Selection Policy: 577 Contains one of the defined member selection policy parameters (see 578 Section 3.6). 580 ASAP Transport: 582 This indicates the ASAP transport address of the PE and MUST be an 583 SCTP type transport parameter (see Section 3.3). 585 3.9. Server Information Parameter 587 This parameter is used in ENRP to pass basic information of an ENRP 588 server. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type = 0x9 | Length=variable | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Server ID | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |M| (reserved) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 : Server Transport : 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Length: 16 bits (unsigned integer) 604 Indicates the entire length of the parameter in number of octets. 606 Note, the value in Length field will NOT cover any padding at the end 607 of the parameter. 609 Server ID: 32 bit (unsigned integer) 611 This is the ID of the ENRP server, as defined in Section xxxxxx in 612 ENRP [4] . 614 Multicast Flag (M): 1 bit 615 If set to '1', indicates the ENRP server is allowed to use multicast 616 for communications. If set to '0', multicast is not used by the 617 server. 619 Reserved: 31 bits 621 MUST be set to 0's by sender and ignored by the receiver. 623 Server Transport: 625 This is an SCTP Transport Parameter, as defined in Section 3.3 that 626 contains the network access address(es), SCTP port number, etc. of 627 the ENRP server. 629 3.10. Operation Error Parameter 631 This parameter is used in both ENPR and ASAP for a message sender to 632 report an error(s) to a message receiver. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type = 0xa | Length=variable | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 : : 640 : one or more Error Causes : 641 : : 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Length: 16 bits (unsigned integer) 646 Indicates the entire length of the parameter in number of octets. 648 Note, the value in Length field will NOT cover any padding at the end 649 of the parameter. 651 Error causes are defined as variable-length parameters using the 652 following format: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Cause Code | Cause Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 : : 660 : Cause-specific Information : 661 : : 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Cause Code: 16 bits (unsigned integer) 665 Defines the type of error condition being reported. 667 Cause Code 668 Value Cause Code 669 --------- ---------------- 670 0 Unspecified Error 671 1 Unrecognized Parameter 672 2 Unrecognized Message 673 3 Invalid Values 674 4 Non-unique PE Identifier 675 5 Inconsistent Pooling Policy 676 6 Lack of Resources 677 7 Inconsistent Transport Type 678 8 Inconsistent Data/Control Configuration 679 9 Unknown Poor Handle 680 10 Rejected due to security considerations. 681 other values reserved by IETF 683 Cause Length: 16 bits (unsigned integer) 685 Set to the size of the parameter in bytes, including the Cause Code, 686 Cause Length, and Cause-Specific Information fields, but not 687 including any padding at the end of this error cause TLV. 689 Cause-specific Information: variable length 691 This field carries the details of the error condition. 693 The following subsections (Section 3.10.1 - Section 3.10.9) define 694 specific error causes. 696 3.10.1. Unspecified Error 698 This error cause is used to report an unspecified error by the 699 sender. There is no cause specific information. 701 3.10.2. Unrecognized Parameter Error 703 This error cause is used to report an unrecognized parameter. The 704 unrecognized parameter TLV is included as cause specific information. 706 3.10.3. Unrecognized Message Error 708 This error cause is used to report an unrecognized message. The 709 unrecognized message TLV is included as cause specific information. 711 3.10.4. Invalid Values Error 713 This error cause is used to report one or more invalid values found 714 in a received parameter. The offending TLV that contains the invalid 715 value(s) is included as cause specific information. 717 3.10.5. Non-unique PE Identifier Error 719 This error cause is used by an ENRP server to indicate to a 720 registering PE that the PE Identifier it chooses has already been 721 used by another PE in the pool. There is no cause specific 722 information. 724 3.10.6. Inconsistent Pool Policy Error 726 This error cause is used by an ENRP server to indicate to a 727 registering PE that the Pool Policy it chooses does not match the 728 overall policy of the pool. A Pool Member Selection Policy TLV (see 729 Section 3.6) that indicates the overall pool policy is included as 730 cause specific information. 732 3.10.7. Lack of Resources Error 734 This error cause is used to indicate that the sender does not have 735 certain resources to perform a requested function. There is no cause 736 specific information. 738 3.10.8. Inconsistent Transport Type Error 740 This error cause is used by an ENRP server to indicate to a 741 registering PE that the User Transport it chooses does not match the 742 overall user transport of the pool. A Transport TLV that indicates 743 the overall pool user transport type is included as cause specific 744 information. 746 3.10.9. Inconsistent Data/Control Configuration Error 748 This error cause is used by an ENRP server to indicate to a 749 registering PE that the Transport Use field in the User Transport it 750 sent in its registration is inconsistent to the pool's overall data/ 751 control channel configuration. There is no cause specific 752 information. 754 3.10.10. Rejected due to security considerations 756 This error cause is used by any endpoint to indicate a rejection of a 757 request due to a failure in security credentials or authorizations. 759 3.10.11. Unknown Poor Handle Error 761 This error cause is used by an ENRP server to indicate to a PE or PU 762 that the requested pool is unknown by the server. There is no cause 763 specific information. 765 3.11. Cookie Parameter 767 This parameter defines a TLV that carries a Cookie. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type = 0xb | Length=variable | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 : : 775 : Cookie : 776 : : 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Length: 16 bits (unsigned integer) 781 Indicates the entire length of the parameter in number of bytes, 782 including the Type, Length, and Cookie. 784 Cookie: variable length 786 The Cookie is an arbitrary byte string of (Length - 4) bytes. 788 3.12. PE Identifier Parameter 790 This parameter defines a TLV that carries a PE Identifier. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type = 0xc | Length=0x8 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | PE Identifier | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 PE Identifier: 32 bits (unsigned integer) 802 Uniquely identifies the PE in the pool. The PE picks its identifier 803 when it starts up. See Section ???? in ASAP [3] for recommendations 804 on PE identifier generation. 806 3.13. PE Checksum Parameter 808 This parameter defines a TLV that carries a PE Checksum. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type = 0xd | Length=0x6 | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | PE Checksum | Padding | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 PE Checksum: 16 bits (unsigned integer) 820 An overall checksum of all PEs in the current handlespace owned by an 821 ENRP server (which is normally the sender of this TLV). The 822 definition and calculation of this checksum is defined in Section 823 3.11.2 in ENRP [4]. 825 4. Common Message Formats 827 The figure below illustrates the common format for all ASAP and ENRP 828 messages. Each message is formatted with a Message Type field, a 829 message-specific Flag field, a Message Length field, and a Value 830 field. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Message Type | Msg Flags | Message Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 : : 838 : Message Value : 839 : : 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Message Type: 8 bits (unsigned integer) 844 This field identifies the type of information contained in the 845 Message Value field. It takes a value from 0 to 254. The value of 846 255 is reserved for future use as an extension field. 848 Message Types are encoded such that the highest-order two bits 849 specify the action that must be taken if the message receiver does 850 not recognize the Message Type. 852 00 Stop processing this message and discard it. 854 01 Stop processing this message and discard it, and report the 855 unrecognized message in an 'Unrecognized Message' error (see 856 Section 3.10.3). 858 10 reserved. 860 11 reserved. 862 Message Flags: 8 bits 864 The usage of these bits depends on the message type as given by the 865 Message Type. Unless otherwise specified, they are set to zero on 866 transmit and are ignored on receipt. 868 Message Length: 16 bits (unsigned integer) 870 This value represents the size of the message in bytes including the 871 Message Type, Message Flags, Message Length, and Message Value 872 fields. Therefore, if the Message Value field is zero-length, the 873 Length field will be set to 4. 875 Note, the value in Message Length field will NOT cover any padding at 876 the end of this message. 878 Message Value: variable length 880 The Message Value field contains the actual information to be 881 transferred in the message. The usage and format of this field is 882 dependent on the Message Type. 884 The total length of a message (including Type, Length and Value 885 fields) MUST be a multiple of 4 bytes. If the length of the message 886 is not a multiple of 4 bytes, the sender MUST pad the message with 887 all zero bytes and this padding is not included in the message length 888 field. The sender should never pad with more than 3 bytes. The 889 receiver MUST ignore the padding bytes. 891 5. Security Considerations 893 This document contains common parameter formats only. As such it 894 specifies no new security constraints on either ENRP or ASAP. 895 Details on ENRP and ASAP security constraints are addressed in ENRP 896 [4] and ASAP [3] . 898 6. Normative References 900 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 901 BCP 9, RFC 2026, October 1996. 903 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 904 Levels", BCP 14, RFC 2119, March 1997. 906 [3] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 907 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 908 (work in progress), July 2005. 910 [4] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 911 Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", 912 draft-ietf-rserpool-enrp-12 (work in progress), July 2005. 914 Authors' Addresses 916 Randall R. Stewart 917 Cisco Systems, Inc. 918 4875 Forest Drive 919 Suite 200 920 Columbia, SC 29206 921 USA 923 Phone: 924 Email: rrs@cisco.com 926 Qiaobing Xie 927 Motorola, Inc. 928 1501 W. Shure Drive, #2309 929 Arlington Heights, IL 60004 930 USA 932 Phone: 933 Email: qxie1@email.mot.com 935 Maureen Stillman 936 Nokia 937 127 W. State Street 938 Ithaca, NY 14850 939 USA 941 Phone: 942 Email: maureen.stillman@nokia.com 944 Michael Tuexen 945 Muenster Univ. of Applied Sciences 946 Stegerwaldstr. 39 947 48565 Steinfurt 948 Germany 950 Email: tuexen@fh-muenster.de 952 Full Copyright Statement 954 Copyright (C) The Internet Society (2006). 956 This document is subject to the rights, licenses and restrictions 957 contained in BCP 78, and except as set forth therein, the authors 958 retain all their rights. 960 This document and the information contained herein are provided on an 961 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 962 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 963 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 964 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 965 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 966 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 968 Intellectual Property 970 The IETF takes no position regarding the validity or scope of any 971 Intellectual Property Rights or other rights that might be claimed to 972 pertain to the implementation or use of the technology described in 973 this document or the extent to which any license under such rights 974 might or might not be available; nor does it represent that it has 975 made any independent effort to identify any such rights. Information 976 on the procedures with respect to rights in RFC documents can be 977 found in BCP 78 and BCP 79. 979 Copies of IPR disclosures made to the IETF Secretariat and any 980 assurances of licenses to be made available, or the result of an 981 attempt made to obtain a general license or permission for the use of 982 such proprietary rights by implementers or users of this 983 specification can be obtained from the IETF on-line IPR repository at 984 http://www.ietf.org/ipr. 986 The IETF invites any interested party to bring to its attention any 987 copyrights, patents or patent applications, or other proprietary 988 rights that may cover technology that may be required to implement 989 this standard. Please address the information to the IETF at 990 ietf-ipr@ietf.org. 992 Acknowledgment 994 Funding for the RFC Editor function is provided by the IETF 995 Administrative Support Activity (IASA).