idnits 2.17.1 draft-ietf-rserpool-common-param-12.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 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 988. 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 == Line 603 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 (July 9, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ASAP' on line 477 == Unused Reference: '1' is defined on line 892, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) == 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 == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-04 Summary: 2 errors (**), 0 flaws (~~), 7 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: Experimental Q. Xie 5 Expires: January 10, 2008 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 July 9, 2007 12 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 13 Redundancy Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-12.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 10, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document details the parameters of the Aggregate Server Access 48 Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) 49 protocols defined within the Reliable Server Pooling (RSERPOOL) 50 architecture. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Parameters in General . . . . . . . . . . . . . . . . . . . . 4 57 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . . . 5 58 3.1. IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 7 59 3.2. IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 60 3.3. 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.7. Pool Handle Parameter . . . . . . . . . . . . . . . . . . 11 65 3.8. Pool Element Parameter . . . . . . . . . . . . . . . . . . 12 66 3.9. Server Information Parameter . . . . . . . . . . . . . . . 13 67 3.10. Operation Error Parameter . . . . . . . . . . . . . . . . 14 68 3.10.1. Unspecified Error . . . . . . . . . . . . . . . . . . 16 69 3.10.2. Unrecognized Parameter Error . . . . . . . . . . . . 16 70 3.10.3. Unrecognized Message Error . . . . . . . . . . . . . 16 71 3.10.4. Invalid Values Error . . . . . . . . . . . . . . . . 16 72 3.10.5. Non-unique PE Identifier Error . . . . . . . . . . . 16 73 3.10.6. Inconsistent Pool Policy Error . . . . . . . . . . . 16 74 3.10.7. Lack of Resources Error . . . . . . . . . . . . . . . 16 75 3.10.8. Inconsistent Transport Type Error . . . . . . . . . . 16 76 3.10.9. Inconsistent Data/Control Configuration Error . . . . 17 77 3.10.10. Rejected due to security considerations . . . . . . . 17 78 3.10.11. Unknown Poor Handle Error . . . . . . . . . . . . . . 17 79 3.11. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 17 80 3.12. PE Identifier Parameter . . . . . . . . . . . . . . . . . 17 81 3.13. PE Checksum Parameter . . . . . . . . . . . . . . . . . . 18 82 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 19 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 5.1. A New Table for RSerPool Parameter Types . . . . . . . . . 21 85 5.2. A New Table for RSerPool Error Causes . . . . . . . . . . 21 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 87 7. Normative References . . . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 Intellectual Property and Copyright Statements . . . . . . . . . . 26 91 1. Introduction 93 Aggregate Server Access Protocol (ASAP) [4] in conjunction with the 94 Endpoint Handlespace Redundancy Protocol (ENRP) [5] provides a high 95 availability data transfer 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 ASAP [4] and ENRP [5] documents. 103 1.1. Conventions 105 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 106 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 107 they appear in this document, are to be interpreted as described in 108 RFC2119 [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Parameter Type: 16 bits (unsigned integer) 138 The Type field is a 16 bit identifier of the type of parameter. It 139 takes a value of 0 to 65534. 141 The value of 65535 is reserved for IETF-defined extensions. Values 142 other than those defined in specific ENRP parameter description are 143 reserved by IETF. (Additional types, when needed, will be defined in 144 the future through appropriate IETF/IANA procedures.) 146 The Parameter Types are encoded such that the highest-order two bits 147 specify the action that must be taken if the processing endpoint does 148 not recognize the Parameter Type. 150 00 Stop processing this ENRP or ASAP message and discard it, do not 151 process any further parameters within it. 153 01 Stop processing this ENRP or ASAP message and discard it, do not 154 process any further parameters within it, and report the 155 unrecognized parameter in an 'Unrecognized Parameter' error (see 156 Section 3.10). 158 10 Skip this parameter and continue processing. 160 11 Skip this parameter and continue processing, but report the 161 unrecognized parameter in an 'Unrecognized Parameter' error (see 162 Section 3.10). 164 The values of parameter types are defined as follows: 166 Value Parameter Type 167 ----- ---------- 168 0x0 - (reserved by IETF) 169 0x1 - IPv4 Address 170 0x2 - IPv6 Address 171 0x3 - SCTP Transport 172 0x4 - TCP Transport 173 0x5 - UDP Transport 174 0x6 - Pool Member Selection Policy 175 0x7 - Pool Handle 176 0x8 - Pool Element 177 0x9 - Server Information 178 0xa - Operation Error 179 0xb - Cookie 180 0xc - PE Identifier 181 0xd - PE Checksum 183 others - (reserved by IETF) 185 Figure 2 187 Parameter Length: 16 bits (unsigned integer) 189 The Parameter Length field contains the size of the parameter in 190 bytes, including the Parameter Type, Parameter Length, and Parameter 191 Value fields. Thus, a parameter with a zero-length Parameter Value 192 field would have a Length field of 4. 194 The total length of a parameter (including Type, Parameter Length and 195 Value fields) MUST be a multiple of 4 bytes. If the length of the 196 parameter is not a multiple of 4 bytes, the sender MUST pad the 197 parameter at the end (i.e., after the Parameter Value field) with all 198 zero bytes. The length of this padding is not included in the 199 Parameter Length field. A sender MUST NOT pad with more than 3 200 bytes. The receiver MUST ignore the padding bytes. 202 (Editor's note: clarify further that any padding inside in the 203 parameter, such as the padding in sub-param is included in the total 204 length) 206 Parameter Value: variable-length. 208 The Parameter Value field contains the actual information to be 209 transferred in the parameter. 211 3.1. IPv4 Address Parameter 213 This parameter defines a TLV that carries an IPv4 address. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type = 0x1 | Length = 0x8 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | IPv4 Address | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 IPv4 Address: 32 bits (unsigned integer) 225 Contains an IPv4 address. It is binary encoded. 227 3.2. IPv6 Address Parameter 229 This parameter defines a TLV that carries an IPv6 address. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type = 0x2 | Length = 0x14 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | IPv6 Address | 238 | | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 IPv6 Address: 128 bit (unsigned integer) 244 Contains an IPv6 address. It is binary encoded. 246 3.3. SCTP Transport Parameter 248 This parameter defines a TLV that describes a user transport using 249 SCTP protocol. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type = 0x3 | Length = variable | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | SCTP port | Transport Use | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 : IPv4 or IPv6 Address #1 : 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 : : 261 : ... : 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 : IPv4 or IPv6 Address #n : 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Length: 16 bits (unsigned integer) 268 Indicates the entire length of the parameter in number of octets, 269 including the Type, Length, SCTP port, reserved fields, and all IP 270 address parameters present. 272 SCTP port: 16 bits (unsigned integer) 274 The SCTP port number signed to this SCTP user transport. 276 Transport use: 16 bits (unsigned integer) 278 This field represents how the pool element intends this transport 279 address to be used. The field MUST be populated with one of the 280 following values: 282 Type | Value 283 ------------------+---------------- 284 DATA ONLY | 0x0000 285 DATA plus CONTROL | 0x0001 287 IPv4 or IPv6 Address #1 - #n: 289 Each indicates an IPv4 or IPv6 address parameter (as defined above in 290 Section 3.1 and Section 3.2) assigned to this SCTP user transport. 291 An SCTP Transport parameter may have a mixed list of IPv4 and IPv6 292 addresses and at least one IP address parameter MUST be present in an 293 SCTP transport parameter. 295 3.4. TCP Transport Parameter 297 This parameter defines a TLV that describes a user transport using 298 TCP protocol. 300 0 1 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = 0x4 | Length = variable | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | TCP port | Transport Use | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : IPv4 or IPv6 Address : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Length: 16 bits (unsigned integer) 312 Indicates the entire length of the parameter in number of octets, 313 including the Type, Length, TCP port, reserved fields, and IP address 314 parameter. 316 TCP port: 16 bits (unsigned integer) 318 The TCP port number signed to this TCP user transport. 320 Transport use: 16 bits (unsigned integer) 322 This field represents how the pool element intends this transport 323 address to be used. The field MUST be populated with one of the 324 following values: 326 Type | Value 327 ------------------+---------------- 328 DATA ONLY | 0x0000 329 DATA plus CONTROL | 0x0001 331 IPv4 or IPv6 Address: 333 Indicates an IPv4 or IPv6 address parameter (as defined above in 334 Section 3.1 and Section 3.2) assigned to this TCP user transport. 335 Unlike in an SCTP transport, only one IP address parameter can be 336 present in a TCP transport parameter. 338 3.5. UDP Transport Parameter 340 This parameter defines a TLV that describes a user transport using 341 UDP protocol. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type = 0x5 | Length = variable | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | UDP port | (reserved) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 : IPv4 or IPv6 Address : 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Length: 16 bits (unsigned integer) 355 Indicates the entire length of the parameter in number of octets, 356 including the Type, Length, UDP port, reserved fields, and IP address 357 parameter. 359 UDP port: 16 bits (unsigned integer) 361 The UDP port number signed to this UDP user transport. 363 IPv4 or IPv6 Address: 365 Indicates an IPv4 or IPv6 address parameter (as defined above in 366 Section 3.1 and Section 3.2) assigned to this UDP user transport. 367 Unlike in an SCTP transport, only one IP address parameter can be 368 present in a UDP transport parameter. 370 Note: A UDP port MUST NOT be used for control information. For this 371 reason, no Transport Use field is provided. UDP MUST always be 372 treated as a "Data Only" type transport use. 374 3.6. Pool Member Selection Policy Parameter 376 This parameter defines a pool member selection policy. RSERPOOL 377 supports multiple pool member selection policies and also allows 378 definition of new selection policies in the future. 380 The enforcement rules and handling procedures of all the policies are 381 defined in Section xxxxx in ASAP [4]. 383 All pool member selection policies, both present and future, MUST use 384 the following general parameter format: 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 | Policy Type | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Policy-specific Data | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Length: 16 bits (unsigned integer) 398 Indicates the entire length of the parameter in number of octets, 399 including the Type, Length, Policy Type, and the Policy-specific Data 400 fields. 402 Note, the Length field value will NOT include any padding at the end 403 of the parameter. 405 Policy Type: 32 bits (unsigned integer) 407 Specifies the type of selection policy. 409 Policy-specific Data: 411 The structure and fields for each presently defined policy types are 412 described in detail in Policies [6]. 414 3.7. Pool Handle Parameter 416 This parameter holds a pool handle. 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 : : 424 : Pool Handle : 425 : : 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Length: 16 bits (unsigned integer) 430 Indicates the entire length of the parameter in number of octets, 431 including the Type, Length, and Pool Handle string. 433 Note, the value in Length field will NOT cover any padding at the end 434 of the parameter. 436 Pool Handle: 438 defined as a sequence of (Length - 4) bytes. 440 3.8. Pool Element Parameter 442 This parameter is used in multiple ENRP messages to represent an ASAP 443 endpoint (i.e., a PE in a pool) and the associated information, such 444 as its transport address, selection policy, and other operational or 445 status information of the PE. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type = 0x8 | Length=variable | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | PE Identifier | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Home ENRP Server Identifier | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Registration Life | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 : User Transport param : 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 : Member Selection Policy param : 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 : ASAP Transport param : 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Length: 16 bits (unsigned integer) 467 Indicates the entire length of the parameter in number of octets, 468 including the Type, Length, PE Identifier, Registration Life, User 469 Transport, and Member Selection Policy parameters. 471 Note, the value in Length field will NOT cover any padding at the end 472 of this Pool Element parameter. 474 PE Identifier: 32 bits (unsigned integer) 476 Uniquely identifies the PE in the pool. The PE picks its identifier 477 when it starts up. See Section ???? in [ASAP] for recommendations on 478 PE identifier generation. 480 Home ENRP Server Identifier: 32 bits (unsigned integer) 481 Indicates the current home ENRP server of this PE. Set to all 0's if 482 the PE's home ENRP server is undetermined. 484 Registration Life: 32 bits (signed integer) 486 Indicates the life time of the registration in number of seconds. A 487 value of -1 indicates infinite life time. 489 User Transport: 491 This can be either an SCTP, TCP, or UDP type transport parameter (see 492 Section 3.3, Section 3.4, Section 3.5). A PE MUST have one and only 493 one User Transport. 495 Member Selection Policy: 497 Contains one of the defined member selection policy parameters (see 498 Section 3.6). 500 ASAP Transport: 502 This indicates the ASAP transport address of the PE and MUST be an 503 SCTP type transport parameter (see Section 3.3). 505 3.9. Server Information Parameter 507 This parameter is used in ENRP to pass basic information of an ENRP 508 server. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type = 0x9 | Length=variable | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Server ID | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |M| (reserved) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 : Server Transport : 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Length: 16 bits (unsigned integer) 524 Indicates the entire length of the parameter in number of octets. 526 Note, the value in Length field will NOT cover any padding at the end 527 of the parameter. 529 Server ID: 32 bit (unsigned integer) 531 This is the ID of the ENRP server, as defined in Section xxxxxx in 532 ENRP [5] . 534 Multicast Flag (M): 1 bit 536 If set to '1', indicates the ENRP server is allowed to use multicast 537 for communications. If set to '0', multicast is not used by the 538 server. 540 Reserved: 31 bits 542 MUST be set to 0's by sender and ignored by the receiver. 544 Server Transport: 546 This is an SCTP Transport Parameter, as defined in Section 3.3 that 547 contains the network access address(es), SCTP port number, etc. of 548 the ENRP server. 550 3.10. Operation Error Parameter 552 This parameter is used in both ENPR and ASAP for a message sender to 553 report an error(s) to a message receiver. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type = 0xa | Length=variable | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 : : 561 : one or more Error Causes : 562 : : 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Length: 16 bits (unsigned integer) 567 Indicates the entire length of the parameter in number of octets. 569 Note, the value in Length field will NOT cover any padding at the end 570 of the parameter. 572 Error causes are defined as variable-length parameters using the 573 following format: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Cause Code | Cause Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 : : 581 : Cause-specific Information : 582 : : 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Cause Code: 16 bits (unsigned integer) 587 Defines the type of error condition being reported. 589 Cause Code 590 Value Cause Code 591 --------- ---------------- 592 0 Unspecified Error 593 1 Unrecognized Parameter 594 2 Unrecognized Message 595 3 Invalid Values 596 4 Non-unique PE Identifier 597 5 Inconsistent Pooling Policy 598 6 Lack of Resources 599 7 Inconsistent Transport Type 600 8 Inconsistent Data/Control Configuration 601 9 Unknown Poor Handle 602 10 Rejected due to security considerations. 603 other values reserved by IETF 605 Figure 16 607 Cause Length: 16 bits (unsigned integer) 609 Set to the size of the parameter in bytes, including the Cause Code, 610 Cause Length, and Cause-Specific Information fields, but not 611 including any padding at the end of this error cause TLV. 613 Cause-specific Information: variable length 615 This field carries the details of the error condition. 617 The following subsections (Section 3.10.1 - Section 3.10.9) define 618 specific error causes. 620 3.10.1. Unspecified Error 622 This error cause is used to report an unspecified error by the 623 sender. There is no cause specific information. 625 3.10.2. Unrecognized Parameter Error 627 This error cause is used to report an unrecognized parameter. The 628 unrecognized parameter TLV is included as cause specific information. 630 3.10.3. Unrecognized Message Error 632 This error cause is used to report an unrecognized message. The 633 unrecognized message TLV is included as cause specific information. 635 3.10.4. Invalid Values Error 637 This error cause is used to report one or more invalid values found 638 in a received parameter. The offending TLV that contains the invalid 639 value(s) is included as cause specific information. 641 3.10.5. Non-unique PE Identifier Error 643 This error cause is used by an ENRP server to indicate to a 644 registering PE that the PE Identifier it chooses has already been 645 used by another PE in the pool. There is no cause specific 646 information. 648 3.10.6. Inconsistent Pool Policy Error 650 This error cause is used by an ENRP server to indicate to a 651 registering PE that the Pool Policy it chooses does not match the 652 overall policy of the pool. A Pool Member Selection Policy TLV (see 653 Section 3.6) that indicates the overall pool policy is included as 654 cause specific information. 656 3.10.7. Lack of Resources Error 658 This error cause is used to indicate that the sender does not have 659 certain resources to perform a requested function. There is no cause 660 specific information. 662 3.10.8. Inconsistent Transport Type Error 664 This error cause is used by an ENRP server to indicate to a 665 registering PE that the User Transport it chooses does not match the 666 overall user transport of the pool. A Transport TLV that indicates 667 the overall pool user transport type is included as cause specific 668 information. 670 3.10.9. Inconsistent Data/Control Configuration Error 672 This error cause is used by an ENRP server to indicate to a 673 registering PE that the Transport Use field in the User Transport it 674 sent in its registration is inconsistent to the pool's overall data/ 675 control channel configuration. There is no cause specific 676 information. 678 3.10.10. Rejected due to security considerations 680 This error cause is used by any endpoint to indicate a rejection of a 681 request due to a failure in security credentials or authorizations. 683 3.10.11. Unknown Poor Handle Error 685 This error cause is used by an ENRP server to indicate to a PE or PU 686 that the requested pool is unknown by the server. There is no cause 687 specific information. 689 3.11. Cookie Parameter 691 This parameter defines a TLV that carries a Cookie. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type = 0xb | Length=variable | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 : : 699 : Cookie : 700 : : 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Length: 16 bits (unsigned integer) 705 Indicates the entire length of the parameter in number of bytes, 706 including the Type, Length, and Cookie. 708 Cookie: variable length 710 The Cookie is an arbitrary byte string of (Length - 4) bytes. 712 3.12. PE Identifier Parameter 714 This parameter defines a TLV that carries a PE Identifier. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type = 0xc | Length=0x8 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | PE Identifier | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 PE Identifier: 32 bits (unsigned integer) 726 Uniquely identifies the PE in the pool. The PE picks its identifier 727 when it starts up. See Section ???? in ASAP [4] for recommendations 728 on PE identifier generation. 730 3.13. PE Checksum Parameter 732 This parameter defines a TLV that carries a PE Checksum. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type = 0xd | Length=0x6 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | PE Checksum | Padding | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 PE Checksum: 16 bits (unsigned integer) 744 An overall checksum of all PEs in the current handlespace owned by an 745 ENRP server (which is normally the sender of this TLV). The 746 definition and calculation of this checksum is defined in Section 747 3.11.2 in ENRP [5]. 749 4. Common Message Formats 751 The figure below illustrates the common format for all ASAP and ENRP 752 messages. Each message is formatted with a Message Type field, a 753 message-specific Flag field, a Message Length field, and a Value 754 field. 756 0 1 2 3 757 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Message Type | Msg Flags | Message Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 : : 762 : Message Value : 763 : : 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Message Type: 8 bits (unsigned integer) 768 This field identifies the type of information contained in the 769 Message Value field. It takes a value from 0 to 254. The value of 770 255 is reserved for future use as an extension field. 772 Message Types are encoded such that the highest-order two bits 773 specify the action that must be taken if the message receiver does 774 not recognize the Message Type. 776 00 Stop processing this message and discard it. 778 01 Stop processing this message and discard it, and report the 779 unrecognized message in an 'Unrecognized Message' error (see 780 Section 3.10.3). 782 10 reserved. 784 11 reserved. 786 Message Flags: 8 bits 788 The usage of these bits depends on the message type as given by the 789 Message Type. Unless otherwise specified, they are set to zero on 790 transmit and are ignored on receipt. 792 Message Length: 16 bits (unsigned integer) 794 This value represents the size of the message in bytes including the 795 Message Type, Message Flags, Message Length, and Message Value 796 fields. Therefore, if the Message Value field is zero-length, the 797 Length field will be set to 4. 799 Note, the value in Message Length field will NOT cover any padding at 800 the end of this message. 802 Message Value: variable length 804 The Message Value field contains the actual information to be 805 transferred in the message. The usage and format of this field is 806 dependent on the Message Type. 808 The total length of a message (including Type, Length and Value 809 fields) MUST be a multiple of 4 bytes. If the length of the message 810 is not a multiple of 4 bytes, the sender MUST pad the message with 811 all zero bytes and this padding is not included in the message length 812 field. The sender should never pad with more than 3 bytes. The 813 receiver MUST ignore the padding bytes. 815 5. IANA Considerations 817 [NOTE to RFC-Editor: 819 "RFCXXXX" is to be replaced by the RFC number you assign this 820 document. 822 ] 824 This document (RFCXXX) is the reference for all registrations 825 described in this section. All registrations need to be listed on an 826 RSerPool specific page. 828 5.1. A New Table for RSerPool Parameter Types 830 RSerPool Parameter Types have to be maintained by IANA. Thirteen 831 initial values should be assigned by IANA as described in Figure 2. 832 This requires a new table "RSerPool Parameter Types": 834 Type Message Name Reference 835 ----- ------------------------- --------- 836 0x0 (reserved by IETF) RFCXXXX 837 0x1 IPv4 Address RFCXXXX 838 0x2 IPv6 Address RFCXXXX 839 0x3 SCTP Transport RFCXXXX 840 0x4 TCP Transport RFCXXXX 841 0x5 UDP Transport RFCXXXX 842 0x6 Pool Member Selection Policy RFCXXXX 843 0x7 Pool Handle RFCXXXX 844 0x8 Pool Element RFCXXXX 845 0x9 Server Information RFCXXXX 846 0xa Operation Error RFCXXXX 847 0xb Cookie RFCXXXX 848 0xc PE Identifier RFCXXXX 849 0xd PE Checksum RFCXXXX 850 others (reserved by IETF) RFCXXXX 852 For registering at IANA an RSerPool Parameter Type in this table a 853 request has to be made to assign such a number. This number must be 854 unique. The "Specification Required" policy of RFC2434 [3] MUST be 855 applied. 857 5.2. A New Table for RSerPool Error Causes 859 RSerPool Error Causes have to be maintained by IANA. Eleven initial 860 values should be assigned by IANA as described in Figure 16. This 861 requires a new table "RSerPool Error Causes": 863 Cause Cause Name Reference 864 ----- ------------------------- --------- 865 0 Unspecified Error RFCXXXX 866 1 Unrecognized Parameter RFCXXXX 867 2 Unrecognized Message RFCXXXX 868 3 Invalid Values RFCXXXX 869 4 Non-unique PE Identifier RFCXXXX 870 5 Inconsistent Pooling Policy RFCXXXX 871 6 Lack of Resources RFCXXXX 872 7 Inconsistent Transport Type RFCXXXX 873 8 Inconsistent Data/Control Configuration RFCXXXX 874 9 Unknown Poor Handle RFCXXXX 875 10 Rejected due to security considerations RFCXXXX 876 others (reserved by IETF) RFCXXXX 878 For registering at IANA an RSerPool Error Cause in this table a 879 request has to be made to assign such a number. This number must be 880 unique. The "Specification Required" policy of RFC2434 [3] MUST be 881 applied. 883 6. Security Considerations 885 This document contains common parameter formats only. As such it 886 specifies no new security constraints on either ENRP or ASAP. 887 Details on ENRP and ASAP security constraints are addressed in ENRP 888 [5] and ASAP [4] . 890 7. Normative References 892 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 893 BCP 9, RFC 2026, October 1996. 895 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 896 Levels", BCP 14, RFC 2119, March 1997. 898 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 899 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 901 [4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 902 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 903 (work in progress), July 2005. 905 [5] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 906 Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", 907 draft-ietf-rserpool-enrp-12 (work in progress), July 2005. 909 [6] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", 910 draft-ietf-rserpool-policies-04 (work in progress), March 2007. 912 Authors' Addresses 914 Randall R. Stewart 915 Cisco Systems, Inc. 916 4875 Forest Drive 917 Suite 200 918 Columbia, SC 29206 919 USA 921 Phone: 922 Email: rrs@cisco.com 924 Qiaobing Xie 925 Motorola, Inc. 926 1501 W. Shure Drive, #2309 927 Arlington Heights, IL 60004 928 USA 930 Phone: 931 Email: qxie1@email.mot.com 933 Maureen Stillman 934 Nokia 935 127 W. State Street 936 Ithaca, NY 14850 937 USA 939 Phone: 940 Email: maureen.stillman@nokia.com 942 Michael Tuexen 943 Muenster Univ. of Applied Sciences 944 Stegerwaldstr. 39 945 48565 Steinfurt 946 Germany 948 Email: tuexen@fh-muenster.de 950 Full Copyright Statement 952 Copyright (C) The IETF Trust (2007). 954 This document is subject to the rights, licenses and restrictions 955 contained in BCP 78, and except as set forth therein, the authors 956 retain all their rights. 958 This document and the information contained herein are provided on an 959 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 960 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 961 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 962 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 963 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 964 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 966 Intellectual Property 968 The IETF takes no position regarding the validity or scope of any 969 Intellectual Property Rights or other rights that might be claimed to 970 pertain to the implementation or use of the technology described in 971 this document or the extent to which any license under such rights 972 might or might not be available; nor does it represent that it has 973 made any independent effort to identify any such rights. Information 974 on the procedures with respect to rights in RFC documents can be 975 found in BCP 78 and BCP 79. 977 Copies of IPR disclosures made to the IETF Secretariat and any 978 assurances of licenses to be made available, or the result of an 979 attempt made to obtain a general license or permission for the use of 980 such proprietary rights by implementers or users of this 981 specification can be obtained from the IETF on-line IPR repository at 982 http://www.ietf.org/ipr. 984 The IETF invites any interested party to bring to its attention any 985 copyrights, patents or patent applications, or other proprietary 986 rights that may cover technology that may be required to implement 987 this standard. Please address the information to the IETF at 988 ietf-ipr@ietf.org. 990 Acknowledgment 992 Funding for the RFC Editor function is provided by the IETF 993 Administrative Support Activity (IASA).