idnits 2.17.1 draft-ietf-rserpool-common-param-08.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 951. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 667 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 (February 18, 2005) is 6999 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ASAP' on line 541 == Unused Reference: '1' is defined on line 880, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '3') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Stewart 2 Internet-Draft Cisco Systems, Inc. 3 Expires: August 22, 2005 Q. Xie 4 Motorola, Inc. 5 M. Stillman 6 Nokia 7 M. Tuexen 8 February 18, 2005 10 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 11 Redundancy Protocol (ENRP) Parameters 12 draft-ietf-rserpool-common-param-08.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 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 26 Internet-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 August 22, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 12 68 3.7 Pool Handle Parameter . . . . . . . . . . . . . . . . . . 12 69 3.8 Pool Element Parameter . . . . . . . . . . . . . . . . . . 13 70 3.9 Server Information Parameter . . . . . . . . . . . . . . . 14 71 3.10 Operation Error Parameter . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 17 76 3.10.5 Non-unique PE Identifier Error . . . . . . . . . . . . 17 77 3.10.6 Inconsistent Pool Policy Error . . . . . . . . . . . . 17 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 Unknown Poor Handle Error . . . . . . . . . . . . . 18 82 3.11 Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 18 83 3.12 PE Identifier Parameter . . . . . . . . . . . . . . . . . 19 84 3.13 PE Checksum Parameter . . . . . . . . . . . . . . . . . . 19 85 4. Common Message Formats . . . . . . . . . . . . . . . . . . . . 20 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 87 6. Normative References . . . . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 89 Intellectual Property and Copyright Statements . . . . . . . . 24 91 1. Introduction 93 Aggregate Server Access Protocol (ASAP) [3] in conjunction with the 94 Endpoint Handlespace Redundancy Protocol (ENRP) [4] 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 [3] and ENRP [4] 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 Parameter Length: 16 bits (unsigned integer) 187 The Parameter Length field contains the size of the parameter in 188 bytes, including the Parameter Type, Parameter Length, and Parameter 189 Value fields. Thus, a parameter with a zero-length Parameter Value 190 field would have a Length field of 4. 192 The total length of a parameter (including Type, Parameter Length and 193 Value fields) MUST be a multiple of 4 bytes. If the length of the 194 parameter is not a multiple of 4 bytes, the sender MUST pad the 195 parameter at the end (i.e., after the Parameter Value field) with all 196 zero bytes. The length of this padding is not included in the 197 Parameter Length field. A sender MUST NOT pad with more than 3 198 bytes. The receiver MUST ignore the padding bytes. 200 (Editor's note: clarify further that any padding inside in the 201 parameter, such as the padding in sub-param is included in the total 202 length) 204 Parameter Value: variable-length. 206 The Parameter Value field contains the actual information to be 207 transferred in the parameter. 209 3.1 IPv4 Address Parameter 211 This parameter defines a TLV that carries an IPv4 address. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type = 0x1 | Length = 0x8 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | IPv4 Address | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 IPv4 Address: 32 bits (unsigned integer) 223 Contains an IPv4 address. It is binary encoded. 225 3.2 IPv6 Address Parameter 227 This parameter defines a TLV that carries an IPv6 address. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type = 0x2 | Length = 0x14 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 | IPv6 Address | 236 | | 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 IPv6 Address: 128 bit (unsigned integer) 242 Contains an IPv6 address. It is binary encoded. 244 3.3 SCTP Transport Parameter 246 This parameter defines a TLV that describes a user transport using 247 SCTP protocol. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = 0x3 | Length = variable | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | SCTP port | Transport Use | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 : IPv4 or IPv6 Address #1 : 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 : : 259 : ... : 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 : IPv4 or IPv6 Address #n : 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Length: 16 bits (unsigned integer) 266 Indicates the entire length of the parameter in number of octets, 267 including the Type, Length, SCTP port, reserved fields, and all IP 268 address parameters present. 270 SCTP port: 16 bits (unsigned integer) 272 The SCTP port number signed to this SCTP user transport. 274 Transport use: 16 bits (unsigned integer) 276 This field represents how the pool element intends this transport 277 address to be used. The field MUST be populated with one of the 278 following values: 280 Type | Value 281 ------------------+---------------- 282 DATA ONLY | 0x0000 283 DATA plus CONTROL | 0x0001 285 IPv4 or IPv6 Address #1 - #n: 287 Each indicates an IPv4 or IPv6 address parameter (as defined above in 288 Section 3.1 and Section 3.2) assigned to this SCTP user transport. 289 An SCTP Transport parameter may have a mixed list of IPv4 and IPv6 290 addresses and at least one IP address parameter MUST be present in an 291 SCTP transport parameter. 293 3.4 TCP Transport Parameter 295 This parameter defines a TLV that describes a user transport using 296 TCP protocol. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = 0x4 | Length = variable | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | TCP port | Transport Use | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 : IPv4 or IPv6 Address : 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Length: 16 bits (unsigned integer) 310 Indicates the entire length of the parameter in number of octets, 311 including the Type, Length, TCP port, reserved fields, and IP address 312 parameter. 314 TCP port: 16 bits (unsigned integer) 316 The TCP port number signed to this TCP user transport. 318 Transport use: 16 bits (unsigned integer) 320 This field represents how the pool element intends this transport 321 address to be used. The field MUST be populated with one of the 322 following values: 324 Type | Value 325 ------------------+---------------- 326 DATA ONLY | 0x0000 327 DATA plus CONTROL | 0x0001 329 IPv4 or IPv6 Address: 331 Indicates an IPv4 or IPv6 address parameter (as defined above in 332 Section 3.1 and Section 3.2) assigned to this TCP user transport. 333 Unlike in an SCTP transport, only one IP address parameter can be 334 present in a TCP transport parameter. 336 3.5 UDP Transport Parameter 338 This parameter defines a TLV that describes a user transport using 339 UDP protocol. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type = 0x5 | Length = variable | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | UDP port | (reserved) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 : IPv4 or IPv6 Address : 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Length: 16 bits (unsigned integer) 353 Indicates the entire length of the parameter in number of octets, 354 including the Type, Length, UDP port, reserved fields, and IP address 355 parameter. 357 UDP port: 16 bits (unsigned integer) 359 The UDP port number signed to this UDP user transport. 361 IPv4 or IPv6 Address: 363 Indicates an IPv4 or IPv6 address parameter (as defined above in 364 Section 3.1 and Section 3.2) assigned to this UDP user transport. 365 Unlike in an SCTP transport, only one IP address parameter can be 366 present in a UDP transport parameter. 368 Note: A UDP port MUST NOT be used for control information. For this 369 reason, no Transport Use field is provided. UDP MUST always be 370 treated as a "Data Only" type transport use. 372 3.6 Pool Member Selection Policy Parameter 374 This parameter defines a pool member selection policy. RSERPOOL 375 supports multiple pool member selection policies and also allows 376 definition of new selection policies in the future. 378 The enforcement rules and handling procedures of all the policies are 379 defined in Section xxxxx in ASAP [3]. 381 All pool member selection policies, both present and future, MUST use 382 the following general parameter format: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type = 0x6 | Length = variable | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Policy Type | Policy-specific Data.... 390 +-+-+-+-+-+-+-+-+------------------------------------------------ 392 Length: 16 bits (unsigned integer) 394 Indicates the entire length of the parameter in number of octets, 395 including the Type, Length, Policy Type, and the Policy-specific Data 396 fields. 398 Note, the Length field value will NOT include any padding at the end 399 of the parameter. 401 Policy Type: 8 bits (unsigned integer) 403 Specifies the type of selection policy. 405 Currently defined policy types are: 407 Value Policy 408 ----- --------- 409 0x0 (reserved by IETF) 410 0x1 Round Robin 411 0x2 Least Used 412 0x3 Least Used with Degradation (a.k.a. dog pile) 413 0x4 Weighted Round Robin 414 others (reserved by IETF) 416 Policy-specific Data: 418 The structure and fields for each presently defined policy types are 419 described in detail in the following subsections. The enforcement 420 rules and handling procedures of these policies are defined in 421 Section xxxxx in ASAP [3]. 423 3.6.1 Round Robin Policy 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Param Type = 0x6 | Length = 0x8 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Policy=0x1 | (reserved) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 433 Reserved: 24 bits 435 MUST be set to 0's by sender and ignored by the receiver. 437 3.6.2 Least Used Policy 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Param Type = 0x6 | Length = 0x8 | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Policy=0x2 | Load | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 447 Load: 24 bits (signed integer) 449 (TBD) 451 3.6.3 Least Used with Degradation Policy 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Param Type = 0x6 | Length = 0x8 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Policy=0x3 | Load | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 461 Load: 24 bits (signed integer) 463 (TBD) 465 3.6.4 Weighted Round Robin Policy 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Param Type = 0x6 | Length = 0x8 | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Policy=0x4 | Weight | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 475 Load: 24 bits (signed integer) 477 (TBD) 479 3.7 Pool Handle Parameter 481 This parameter holds a pool handle. 483 0 1 2 3 484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type = 0x7 | Length=variable | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 : : 489 : Pool Handle : 490 : : 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Length: 16 bits (unsigned integer) 495 Indicates the entire length of the parameter in number of octets, 496 including the Type, Length, and Pool Handle string. 498 Note, the value in Length field will NOT cover any padding at the end 499 of the parameter. 501 Pool Handle: 503 defined as a sequence of (Length - 4) bytes. 505 3.8 Pool Element Parameter 507 This parameter is used in multiple ENRP messages to represent an ASAP 508 endpoint (i.e., a PE in a pool) and the associated information, such 509 as its transport address, selection policy, and other operational or 510 status information of the PE. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type = 0x8 | Length=variable | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | PE Identifier | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Home ENRP Server Identifier | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Registration Life | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 : User Transport param : 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 : Member Selection Policy param : 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 : ASAP Transport param : 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Length: 16 bits (unsigned integer) 531 Indicates the entire length of the parameter in number of octets, 532 including the Type, Length, PE Identifier, Registration Life, User 533 Transport, and Member Selection Policy parameters. 535 Note, the value in Length field will NOT cover any padding at the end 536 of this Pool Element parameter. 538 PE Identifier: 32 bits (unsigned integer) 540 Uniquely identifies the PE in the pool. The PE picks its identifier 541 when it starts up. See Section ???? in [ASAP] for recommendations on 542 PE identifier generation. 544 Home ENRP Server Identifier: 32 bits (unsigned integer) 546 Indicates the current home ENRP server of this PE. Set to all 0's if 547 the PE's home ENRP server is undetermined. 549 Registration Life: 32 bits (signed integer) 551 Indicates the life time of the registration in number of seconds. A 552 value of -1 indicates infinite life time. 554 User Transport: 556 This can be either an SCTP, TCP, or UDP type transport parameter (see 557 Section 3.3, Section 3.4, Section 3.5). A PE MUST have one and only 558 one User Transport. 560 Member Selection Policy: 562 Contains one of the defined member selection policy parameters (see 563 Section 3.6). 565 ASAP Transport: 567 This indicates the ASAP transport address of the PE and MUST be an 568 SCTP type transport parameter (see Section 3.3). 570 3.9 Server Information Parameter 572 This parameter is used in ENRP to pass basic information of an ENRP 573 server. 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 | Type = 0x9 | Length=variable | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Server ID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |M| (reserved) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 : Server Transport : 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Length: 16 bits (unsigned integer) 589 Indicates the entire length of the parameter in number of octets. 591 Note, the value in Length field will NOT cover any padding at the end 592 of the parameter. 594 Server ID: 32 bit (unsigned integer) 596 This is the ID of the ENRP server, as defined in Section xxxxxx in 597 ENRP [4] . 599 Multicast Flag (M): 1 bit 601 If set to '1', indicates the ENRP server is allowed to use multicast 602 for communications. If set to '0', multicast is not used by the 603 server. 605 Reserved: 31 bits 607 MUST be set to 0's by sender and ignored by the receiver. 609 Server Transport: 611 This is an SCTP Transport Parameter, as defined in Section 3.3 that 612 contains the network access address(es), SCTP port number, etc. of 613 the ENRP server. 615 3.10 Operation Error Parameter 617 This parameter is used in both ENPR and ASAP for a message sender to 618 report an error(s) to a message receiver. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type = 0xa | Length=variable | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 : : 626 : one or more Error Causes : 627 : : 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Length: 16 bits (unsigned integer) 632 Indicates the entire length of the parameter in number of octets. 634 Note, the value in Length field will NOT cover any padding at the end 635 of the parameter. 637 Error causes are defined as variable-length parameters using the 638 following format: 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Cause Code | Cause Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 : : 646 : Cause-specific Information : 647 : : 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Cause Code: 16 bits (unsigned integer) 652 Defines the type of error condition being reported. 654 Cause Code 655 Value Cause Code 656 --------- ---------------- 657 0 Unspecified Error 658 1 Unrecognized Parameter 659 2 Unrecognized Message 660 3 Invalid Values 661 4 Non-unique PE Identifier 662 5 Inconsistent Pooling Policy 663 6 Lack of Resources 664 7 Inconsistent Transport Type 665 8 Inconsistent Data/Control Configuration 666 9 Unknown Poor Handle 667 other values reserved by IETF 669 Cause Length: 16 bits (unsigned integer) 671 Set to the size of the parameter in bytes, including the Cause Code, 672 Cause Length, and Cause-Specific Information fields, but not 673 including any padding at the end of this error cause TLV. 675 Cause-specific Information: variable length 677 This field carries the details of the error condition. 679 The following subsections (Section 3.10.1 - Section 3.10.9) define 680 specific error causes. 682 3.10.1 Unspecified Error 684 This error cause is used to report an unspecified error by the 685 sender. There is no cause specific information. 687 3.10.2 Unrecognized Parameter Error 689 This error cause is used to report an unrecognized parameter. The 690 unrecognized parameter TLV is included as cause specific information. 692 3.10.3 Unrecognized Message Error 694 This error cause is used to report an unrecognized message. The 695 unrecognized message TLV is included as cause specific information. 697 3.10.4 Invalid Values Error 699 This error cause is used to report one or more invalid values found 700 in a received parameter. The offending TLV that contains the invalid 701 value(s) is included as cause specific information. 703 3.10.5 Non-unique PE Identifier Error 705 This error cause is used by an ENRP server to indicate to a 706 registering PE that the PE Identifier it chooses has already been 707 used by another PE in the pool. There is no cause specific 708 information. 710 3.10.6 Inconsistent Pool Policy Error 712 This error cause is used by an ENRP server to indicate to a 713 registering PE that the Pool Policy it chooses does not match the 714 overall policy of the pool. A Pool Member Selection Policy TLV (see 715 Section 3.6) that indicates the overall pool policy is included as 716 cause specific information. 718 3.10.7 Lack of Resources Error 720 This error cause is used to indicate that the sender does not have 721 certain resources to perform a requested function. There is no cause 722 specific information. 724 3.10.8 Inconsistent Transport Type Error 726 This error cause is used by an ENRP server to indicate to a 727 registering PE that the User Transport it chooses does not match the 728 overall user transport of the pool. A Transport TLV that indicates 729 the overall pool user transport type is included as cause specific 730 information. 732 3.10.9 Inconsistent Data/Control Configuration Error 734 This error cause is used by an ENRP server to indicate to a 735 registering PE that the Transport Use field in the User Transport it 736 sent in its registration is inconsistent to the pool's overall 737 data/control channel configuration. There is no cause specific 738 information. 740 3.10.10 Unknown Poor Handle Error 742 This error cause is used by an ENRP server to indicate to a PE or PU 743 that the requested pool is unknown by the server. There is no cause 744 specific information. 746 3.11 Cookie Parameter 748 This parameter defines a TLV that carries a Cookie. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type = 0xb | Length=variable | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 : : 756 : Cookie : 757 : : 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Length: 16 bits (unsigned integer) 762 Indicates the entire length of the parameter in number of bytes, 763 including the Type, Length, and Cookie. 765 Cookie: variable length 766 The Cookie is an arbitrary byte string of (Length - 4) bytes. 768 3.12 PE Identifier Parameter 770 This parameter defines a TLV that carries a PE Identifier. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type = 0xc | Length=0x8 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | PE Identifier | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 PE Identifier: 32 bits (unsigned integer) 782 Uniquely identifies the PE in the pool. The PE picks its identifier 783 when it starts up. See Section ???? in ASAP [3] for recommendations 784 on PE identifier generation. 786 3.13 PE Checksum Parameter 788 This parameter defines a TLV that carries a PE Checksum. 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Type = 0xd | Length=0x8 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | PE Checksum | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 PE Checksum: 32 bits (unsigned integer) 800 An overall checksum of all PEs in the current handlespace owned by an 801 ENRP server (which is normally the sender of this TLV). The 802 definition and calculation of this checksum is defined in Section 803 ???? in ENRP [4]. 805 4. Common Message Formats 807 The figure below illustrates the common format for all ASAP and ENRP 808 messages. Each message is formatted with a Message Type field, a 809 message-specific Flag field, a Message Length field, and a Value 810 field. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Message Type | Msg Flags | Message Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 : : 818 : Message Value : 819 : : 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Message Type: 8 bits (unsigned integer) 824 This field identifies the type of information contained in the 825 Message Value field. It takes a value from 0 to 254. The value of 826 255 is reserved for future use as an extension field. 828 Message Types are encoded such that the highest-order two bits 829 specify the action that must be taken if the message receiver does 830 not recognize the Message Type. 832 00 Stop processing this message and discard it. 834 01 Stop processing this message and discard it, and report the 835 unrecognized message in an 'Unrecognized Message' error (see 836 Section 3.10.3). 838 10 reserved. 840 11 reserved. 842 Message Flags: 8 bits 844 The usage of these bits depends on the message type as given by the 845 Message Type. Unless otherwise specified, they are set to zero on 846 transmit and are ignored on receipt. 848 Message Length: 16 bits (unsigned integer) 850 This value represents the size of the message in bytes including the 851 Message Type, Message Flags, Message Length, and Message Value 852 fields. Therefore, if the Message Value field is zero-length, the 853 Length field will be set to 4. 855 Note, the value in Message Length field will NOT cover any padding at 856 the end of this message. 858 Message Value: variable length 860 The Message Value field contains the actual information to be 861 transferred in the message. The usage and format of this field is 862 dependent on the Message Type. 864 The total length of a message (including Type, Length and Value 865 fields) MUST be a multiple of 4 bytes. If the length of the message 866 is not a multiple of 4 bytes, the sender MUST pad the message with 867 all zero bytes and this padding is not included in the message length 868 field. The sender should never pad with more than 3 bytes. The 869 receiver MUST ignore the padding bytes. 871 5. Security Considerations 873 This document contains common parameter formats only. As such it 874 specifies no new security constraints on either ENRP or ASAP. 875 Details on ENRP and ASAP security constraints are addressed in ENRP 876 [4] and ASAP [3] . 878 6. Normative References 880 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 881 BCP 9, RFC 2026, October 1996. 883 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 884 Levels", BCP 14, RFC 2119, March 1997. 886 [3] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 887 Server Access Protocol (ASAP)", 888 Internet-Draft draft-ietf-rserpool-asap-11, February 2005. 890 [4] Xie, Q., Stewart, R., Stillman, M., Tuexen, M. and A. Silverton, 891 "Endpoint Handlespace Redundancy Protocol (ENRP)", 892 Internet-Draft draft-ietf-rserpool-enrp-11, February 2005. 894 Authors' Addresses 896 Randall R. Stewart 897 Cisco Systems, Inc. 898 4875 Forest Drive 899 Suite 200 900 Columbia, SC 29206 901 USA 903 Phone: 904 Email: rrs@cisco.com 906 Qiaobing Xie 907 Motorola, Inc. 908 1501 W. Shure Drive, #2309 909 Arlington Heights, IL 60004 910 USA 912 Phone: 913 Email: qxie1@email.mot.com 914 Maureen Stillman 915 Nokia 916 127 W. State Street 917 Ithaca, NY 14850 918 USA 920 Phone: 921 Email: maureen.stillman@nokia.com 923 Michael Tuexen 924 Germany 926 Phone: 927 Email: tuexen@fh-muenster.de 929 Intellectual Property Statement 931 The IETF takes no position regarding the validity or scope of any 932 Intellectual Property Rights or other rights that might be claimed to 933 pertain to the implementation or use of the technology described in 934 this document or the extent to which any license under such rights 935 might or might not be available; nor does it represent that it has 936 made any independent effort to identify any such rights. Information 937 on the procedures with respect to rights in RFC documents can be 938 found in BCP 78 and BCP 79. 940 Copies of IPR disclosures made to the IETF Secretariat and any 941 assurances of licenses to be made available, or the result of an 942 attempt made to obtain a general license or permission for the use of 943 such proprietary rights by implementers or users of this 944 specification can be obtained from the IETF on-line IPR repository at 945 http://www.ietf.org/ipr. 947 The IETF invites any interested party to bring to its attention any 948 copyrights, patents or patent applications, or other proprietary 949 rights that may cover technology that may be required to implement 950 this standard. Please address the information to the IETF at 951 ietf-ipr@ietf.org. 953 Disclaimer of Validity 955 This document and the information contained herein are provided on an 956 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 957 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 958 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 959 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 960 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 961 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 963 Copyright Statement 965 Copyright (C) The Internet Society (2005). This document is subject 966 to the rights, licenses and restrictions contained in BCP 78, and 967 except as set forth therein, the authors retain all their rights. 969 Acknowledgment 971 Funding for the RFC Editor function is currently provided by the 972 Internet Society.