idnits 2.17.1 draft-ietf-rserpool-common-param-06.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 939. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 955), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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.) ** There are 77 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 659 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 (June 9, 2004) is 7260 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 538 == Unused Reference: '1' is defined on line 867, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-09 ** 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-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '4') Summary: 11 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 Expires: December 8, 2004 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 June 9, 2004 11 Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution 12 Protocol (ENRP) Parameters 13 draft-ietf-rserpool-common-param-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 8, 2004. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This document details the parameters of the Aggregate Server Access 47 Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) 48 protocols defined within the Reliable Server Pooling (RSERPOOL) 49 architecture. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Parameters in General . . . . . . . . . . . . . . . . . . . 4 56 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . . 5 57 3.1 IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 6 58 3.2 IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 59 3.3 SCTP Transport Parameter . . . . . . . . . . . . . . . . . 7 60 3.4 TCP Transport Parameter . . . . . . . . . . . . . . . . . 9 61 3.5 UDP Transport Parameter . . . . . . . . . . . . . . . . . 9 62 3.6 Pool Member Selection Policy Parameter . . . . . . . . . . 10 63 3.6.1 Round Robin Policy . . . . . . . . . . . . . . . . . . 11 64 3.6.2 Least Used Policy . . . . . . . . . . . . . . . . . . 12 65 3.6.3 Least Used with Degradation Policy . . . . . . . . . . 12 66 3.6.4 Weighted Round Robin Policy . . . . . . . . . . . . . 12 67 3.7 Pool Handle Parameter . . . . . . . . . . . . . . . . . . 12 68 3.8 Pool Element Parameter . . . . . . . . . . . . . . . . . . 13 69 3.9 Server Information Parameter . . . . . . . . . . . . . . . 14 70 3.10 Operation Error Parameter . . . . . . . . . . . . . . . 15 71 3.10.1 Unspecified Error . . . . . . . . . . . . . . . . . 17 72 3.10.2 Unrecognized Parameter Error . . . . . . . . . . . . 17 73 3.10.3 Unrecognized Message Error . . . . . . . . . . . . . 17 74 3.10.4 Invalid Values Error . . . . . . . . . . . . . . . . 17 75 3.10.5 Non-unique PE Identifier Error . . . . . . . . . . . 17 76 3.10.6 Inconsistent Pool Policy Error . . . . . . . . . . . 17 77 3.10.7 Lack of Resources Error . . . . . . . . . . . . . . 17 78 3.10.8 Inconsistent Transport Type Error . . . . . . . . . 17 79 3.10.9 Inconsistent Data/Control Configuration Error . . . 18 80 3.11 Cookie Parameter . . . . . . . . . . . . . . . . . . . . 18 81 3.12 PE Identifier Parameter . . . . . . . . . . . . . . . . 18 82 3.13 PE Checksum Parameter . . . . . . . . . . . . . . . . . 19 83 4. Common Message Formats . . . . . . . . . . . . . . . . . . . 20 84 5. Security Considerations . . . . . . . . . . . . . . . . . . 22 85 6. Normative References . . . . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 87 Intellectual Property and Copyright Statements . . . . . . . 24 89 1. Introduction 91 Aggregate Server Access Protocol (ASAP) [3] in conjunction with the 92 Endpoint Name Resolution Protocol (ENRP) [4] provides a high 93 availability data transfer mechanism over IP networks. 95 Both protocols work together and so share many common parameters used 96 in message formats. This document details the common message 97 parameters shared between the two protocols. This document provides 98 parameter formats only, for procedures and message composition please 99 refer to the respective ASAP [3] and ENRP [4] documents. 101 1.1 Conventions 103 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 104 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 105 they appear in this document, are to be interpreted as described in 106 RFC2119 [2]. 108 2. Parameters in General 110 All parameters described below MUST be in Network Byte Order (a.k.a. 111 Big Endian, i.e., the most significant byte first) during 112 transmission. 114 Please note that messages in both ENRP and ASAP are often composed of 115 multiple parameters. These parameters may also be nested. In such a 116 case a nested parameter will include the length of the padding 117 between the nested parameters but not the last padding. 119 3. ENRP-ASAP Common Parameters 121 Parameters are defined in the following Type-Length-Value (TLV) 122 format: 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Parameter Type | Parameter Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 : : 130 : Parameter Value : 131 : : 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Parameter Type: 16 bits (unsigned integer) 136 The Type field is a 16 bit identifier of the type of parameter. It 137 takes a value of 0 to 65534. 139 The value of 65535 is reserved for IETF-defined extensions. Values 140 other than those defined in specific ENRP parameter description are 141 reserved by IETF. (Additional types, when needed, will be defined in 142 the future through appropriate IETF/IANA procedures.) 144 The Parameter Types are encoded such that the highest-order two bits 145 specify the action that must be taken if the processing endpoint does 146 not recognize the Parameter Type. 148 00 Stop processing this ENRP or ASAP message and discard it, do not 149 process any further parameters within it. 151 01 Stop processing this ENRP or ASAP message and discard it, do not 152 process any further parameters within it, and report the 153 unrecognized parameter in an 'Unrecognized Parameter' error (see 154 Section 3.10). 156 10 Skip this parameter and continue processing. 158 11 Skip this parameter and continue processing, but report the 159 unrecognized parameter in an 'Unrecognized Parameter' error (see 160 Section 3.10). 162 The values of parameter types are defined as follows: 164 Value Parameter Type 165 ----- ---------- 166 0x0 - (reserved by IETF) 167 0x1 - IPv4 Address 168 0x2 - IPv6 Address 169 0x3 - SCTP Transport 170 0x4 - TCP Transport 171 0x5 - UDP Transport 172 0x6 - Pool Member Selection Policy 173 0x7 - Pool Handle 174 0x8 - Pool Element 175 0x9 - Server Information 176 0xa - Operation Error 177 0xb - Cookie 178 0xc - PE Identifier 179 0xd - PE Checksum 181 others - (reserved by IETF) 183 Parameter Length: 16 bits (unsigned integer) 185 The Parameter Length field contains the size of the parameter in 186 bytes, including the Parameter Type, Parameter Length, and Parameter 187 Value fields. Thus, a parameter with a zero-length Parameter Value 188 field would have a Length field of 4. 190 The total length of a parameter (including Type, Parameter Length and 191 Value fields) MUST be a multiple of 4 bytes. If the length of the 192 parameter is not a multiple of 4 bytes, the sender MUST pad the 193 parameter at the end (i.e., after the Parameter Value field) with all 194 zero bytes. The length of this padding is not included in the 195 Parameter Length field. A sender MUST NOT pad with more than 3 196 bytes. The receiver MUST ignore the padding bytes. 198 (Editor's note: clarify further that any padding inside in the 199 parameter, such as the padding in sub-param is included in the total 200 length) 202 Parameter Value: variable-length. 204 The Parameter Value field contains the actual information to be 205 transferred in the parameter. 207 3.1 IPv4 Address Parameter 209 This parameter defines a TLV that carries an IPv4 address. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type = 0x1 | Length = 0x8 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | IPv4 Address | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 IPv4 Address: 32 bits (unsigned integer) 221 Contains an IPv4 address. It is binary encoded. 223 3.2 IPv6 Address Parameter 225 This parameter defines a TLV that carries an IPv6 address. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type = 0x2 | Length = 0x14 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 | IPv6 Address | 234 | | 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 IPv6 Address: 128 bit (unsigned integer) 240 Contains an IPv6 address. It is binary encoded. 242 3.3 SCTP Transport Parameter 244 This parameter defines a TLV that describes a user transport using 245 SCTP protocol. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x3 | Length = variable | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | SCTP port | Transport Use | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 : IPv4 or IPv6 Address #1 : 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 : : 257 : ... : 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 : IPv4 or IPv6 Address #n : 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Length: 16 bits (unsigned integer) 264 Indicates the entire length of the parameter in number of octets, 265 including the Type, Length, SCTP port, reserved fields, and all IP 266 address parameters present. 268 SCTP port: 16 bits (unsigned integer) 270 The SCTP port number signed to this SCTP user transport. 272 Transport use: 16 bits (unsigned integer) 274 This field represents how the pool element intends this transport 275 address to be used. The field MUST be populated with one of the 276 following values: 278 Type | Value 279 ------------------+---------------- 280 DATA ONLY | 0x0000 281 DATA plus CONTROL | 0x0001 283 IPv4 or IPv6 Address #1 - #n: 285 Each indicates an IPv4 or IPv6 address parameter (as defined above in 286 Section 3.1 and Section 3.2) assigned to this SCTP user transport. 287 An SCTP Transport parameter may have a mixed list of IPv4 and IPv6 288 addresses and at least one IP address parameter MUST be present in an 289 SCTP transport parameter. 291 3.4 TCP Transport Parameter 293 This parameter defines a TLV that describes a user transport using 294 TCP protocol. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type = 0x4 | Length = variable | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | TCP port | Transport Use | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 : IPv4 or IPv6 Address : 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Length: 16 bits (unsigned integer) 308 Indicates the entire length of the parameter in number of octets, 309 including the Type, Length, TCP port, reserved fields, and IP address 310 parameter. 312 TCP port: 16 bits (unsigned integer) 314 The TCP port number signed to this TCP user transport. 316 Transport use: 16 bits (unsigned integer) 318 This field represents how the pool element intends this transport 319 address to be used. The field MUST be populated with one of the 320 following values: 322 Type | Value 323 ------------------+---------------- 324 DATA ONLY | 0x0000 325 DATA plus CONTROL | 0x0001 327 IPv4 or IPv6 Address: 329 Indicates an IPv4 or IPv6 address parameter (as defined above in 330 Section 3.1 and Section 3.2) assigned to this TCP user transport. 331 Unlike in an SCTP transport, only one IP address parameter can be 332 present in a TCP transport parameter. 334 3.5 UDP Transport Parameter 336 This parameter defines a TLV that describes a user transport using 337 UDP protocol. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type = 0x5 | Length = variable | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | UDP port | (reserved) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 : IPv4 or IPv6 Address : 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Length: 16 bits (unsigned integer) 351 Indicates the entire length of the parameter in number of octets, 352 including the Type, Length, UDP port, reserved fields, and IP address 353 parameter. 355 UDP port: 16 bits (unsigned integer) 357 The UDP port number signed to this UDP user transport. 359 IPv4 or IPv6 Address: 361 Indicates an IPv4 or IPv6 address parameter (as defined above in 362 Section 3.1 and Section 3.2) assigned to this UDP user transport. 363 Unlike in an SCTP transport, only one IP address parameter can be 364 present in a UDP transport parameter. 366 Note: A UDP port MUST NOT be used for control information. For this 367 reason, no Transport Use field is provided. UDP MUST always be 368 treated as a "Data Only" type transport use. 370 3.6 Pool Member Selection Policy Parameter 372 This parameter defines a pool member selection policy. RSERPOOL 373 supports multiple pool member selection policies and also allows 374 definition of new selection policies in the future. 376 The enforcement rules and handling procedures of all the policies are 377 defined in Section xxxxx in ASAP [3]. 379 All pool member selection policies, both present and future, MUST use 380 the following general parameter format: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type = 0x6 | Length = variable | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Policy Type | Policy-specific Data.... 388 +-+-+-+-+-+-+-+-+------------------------------------------------ 390 Length: 16 bits (unsigned integer) 392 Indicates the entire length of the parameter in number of octets, 393 including the Type, Length, Policy Type, and the Policy-specific Data 394 fields. 396 Note, the Length field value will NOT include any padding at the end 397 of the parameter. 399 Policy Type: 8 bits (unsigned integer) 401 Specifies the type of selection policy. 403 Currently defined policy types are: 405 Value Policy 406 ----- --------- 407 0x0 (reserved by IETF) 408 0x1 Round Robin 409 0x2 Least Used 410 0x3 Least Used with Degradation (a.k.a. dog pile) 411 0x4 Weighted Round Robin 412 others (reserved by IETF) 414 Policy-specific Data: 416 The structure and fields for each presently defined policy types are 417 described in detail in the following subsections. The enforcement 418 rules and handling procedures of these policies are defined in 419 Section xxxxx in ASAP [3]. 421 3.6.1 Round Robin Policy 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Param Type = 0x6 | Length = 0x8 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Policy=0x1 | (reserved) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 431 Reserved: 24 bits 433 MUST be set to 0's by sender and ignored by the receiver. 435 3.6.2 Least Used Policy 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Param Type = 0x6 | Length = 0x8 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Policy=0x2 | Load | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 445 Load: 24 bits (signed integer) 447 (TBD) 449 3.6.3 Least Used with Degradation Policy 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Param Type = 0x6 | Length = 0x8 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Policy=0x3 | Load | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 459 Load: 24 bits (signed integer) 461 (TBD) 463 3.6.4 Weighted Round Robin Policy 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Param Type = 0x6 | Length = 0x8 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Policy=0x4 | Weight | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 473 Load: 24 bits (signed integer) 475 (TBD) 477 3.7 Pool Handle Parameter 479 This parameter holds a pool handle (i.e., a pool name). 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type = 0x7 | Length=variable | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 : : 487 : Pool Handle : 488 : : 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Length: 16 bits (unsigned integer) 493 Indicates the entire length of the parameter in number of octets, 494 including the Type, Length, and Pool Handle string. 496 Note, the value in Length field will NOT cover any padding at the end 497 of the parameter. 499 Pool Handle: 501 defined as a sequence of (Length - 4) bytes. 503 3.8 Pool Element Parameter 505 This parameter is used in multiple ENRP messages to represent an ASAP 506 endpoint (i.e., a PE in a pool) and the associated information, such 507 as its transport address, selection policy, and other operational or 508 status information of the PE. 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 = 0x8 | Length=variable | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | PE Identifier | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Home ENRP Server Identifier | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Registration Life | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 : User Transport param : 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 : Member Selection Policy param : 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Length: 16 bits (unsigned integer) 528 Indicates the entire length of the parameter in number of octets, 529 including the Type, Length, PE Identifier, Registration Life, User 530 Transport, and Member Selection Policy parameters. 532 Note, the value in Length field will NOT cover any padding at the end 533 of this Pool Element parameter. 535 PE Identifier: 32 bits (unsigned integer) 537 Uniquely identifies the PE in the pool. The PE picks its identifier 538 when it starts up. See Section ???? in [ASAP] for recommendations on 539 PE identifier generation. 541 Home ENRP Server Identifier: 32 bits (unsigned integer) 543 Indicates the current home ENRP server of this PE. Set to all 0's if 544 the PE's home ENRP server is undetermined. 546 Registration Life: 32 bits (signed integer) 548 Indicates the life time of the registration in number of seconds. A 549 value of -1 indicates infinite life time. 551 User Transport: 553 This can be either an SCTP, TCP, or UDP type transport parameter (see 554 Section 3.3, Section 3.4, Section 3.5). A PE MUST have one and only 555 one User Transport. 557 Member Selection Policy: 559 Contains one of the defined member selection policy parameters (see 560 Section 3.6). 562 3.9 Server Information Parameter 564 This parameter is used in ENRP to pass basic information of an ENRP 565 server. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type = 0x9 | Length=variable | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Server ID | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |M| (reserved) | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 : Server Transport : 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Length: 16 bits (unsigned integer) 582 Indicates the entire length of the parameter in number of octets. 584 Note, the value in Length field will NOT cover any padding at the end 585 of the parameter. 587 Server ID: 32 bit (unsigned integer) 589 This is the ID of the ENRP server, as defined in Section xxxxxx in 590 ENRP [4] . 592 Multicast Flag (M): 1 bit 594 If set to '1', indicates the ENRP server is allowed to use multicast 595 for communications. If set to '0', multicast is not used by the 596 server. 598 Reserved: 31 bits 600 MUST be set to 0's by sender and ignored by the receiver. 602 Server Transport: 604 This is an SCTP Transport Parameter, as defined in Section 3.3 that 605 contains the network access address(es), SCTP port number, etc. of 606 the ENRP server. 608 3.10 Operation Error Parameter 610 This parameter is used in both ENPR and ASAP for a message sender to 611 report an error(s) to a message receiver. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type = 0xa | Length=variable | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 : : 619 : one or more Error Causes : 620 : : 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Length: 16 bits (unsigned integer) 625 Indicates the entire length of the parameter in number of octets. 627 Note, the value in Length field will NOT cover any padding at the end 628 of the parameter. 630 Error causes are defined as variable-length parameters using the 631 following format: 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Cause Code | Cause Length | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 : : 639 : Cause-specific Information : 640 : : 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Cause Code: 16 bits (unsigned integer) 645 Defines the type of error condition being reported. 647 Cause Code 648 Value Cause Code 649 --------- ---------------- 650 0 Unspecified Error 651 1 Unrecognized Parameter 652 2 Unrecognized Message 653 3 Invalid Values 654 4 Non-unique PE Identifier 655 5 Inconsistent Pooling Policy 656 6 Lack of Resources 657 7 Inconsistent Transport Type 658 8 Inconsistent Data/Control Configuration 659 other values reserved by IETF 661 Cause Length: 16 bits (unsigned integer) 663 Set to the size of the parameter in bytes, including the Cause Code, 664 Cause Length, and Cause-Specific Information fields, but not 665 including any padding at the end of this error cause TLV. 667 Cause-specific Information: variable length 669 This field carries the details of the error condition. 671 The following subsections (Section 3.10.1 - Section 3.10.9) define 672 specific error causes. 674 3.10.1 Unspecified Error 676 This error cause is used to report an unspecified error by the 677 sender. There is no cause specific information. 679 3.10.2 Unrecognized Parameter Error 681 This error cause is used to report an unrecognized parameter. The 682 unrecognized parameter TLV is included as cause specific information. 684 3.10.3 Unrecognized Message Error 686 This error cause is used to report an unrecognized message. The 687 unrecognized message TLV is included as cause specific information. 689 3.10.4 Invalid Values Error 691 This error cause is used to report one or more invalid values found 692 in a received parameter. The offending TLV that contains the invalid 693 value(s) is included as cause specific information. 695 3.10.5 Non-unique PE Identifier Error 697 This error cause is used by an ENRP server to indicate to a 698 registering PE that the PE Identifier it chooses has already been 699 used by another PE in the pool. There is no cause specific 700 information. 702 3.10.6 Inconsistent Pool Policy Error 704 This error cause is used by an ENRP server to indicate to a 705 registering PE that the Pool Policy it chooses does not match the 706 overall policy of the pool. A Pool Member Selection Policy TLV (see 707 Section 3.6) that indicates the overall pool policy is included as 708 cause specific information. 710 3.10.7 Lack of Resources Error 712 This error cause is used to indicate that the sender does not have 713 certain resources to perform a requested function. There is no cause 714 specific information. 716 3.10.8 Inconsistent Transport Type Error 718 This error cause is used by an ENRP server to indicate to a 719 registering PE that the User Transport it chooses does not match the 720 overall user transport of the pool. A Transport TLV that indicates 721 the overall pool user transport type is included as cause specific 722 information. 724 3.10.9 Inconsistent Data/Control Configuration Error 726 This error cause is used by an ENRP server to indicate to a 727 registering PE that the Transport Use field in the User Transport it 728 sent in its registration is inconsistent to the pool's overall data/ 729 control channel configuration. There is no cause specific 730 information. 732 3.11 Cookie Parameter 734 This parameter defines a TLV that carries a Cookie. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type = 0xb | Length=variable | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 : : 742 : Cookie : 743 : : 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Length: 16 bits (unsigned integer) 748 Indicates the entire length of the parameter in number of bytes, 749 including the Type, Length, and Cookie. 751 Cookie: variable length 753 The Cookie is an arbitrary byte string of (Length - 4) bytes. 755 3.12 PE Identifier Parameter 757 This parameter defines a TLV that carries a PE Identifier. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type = 0xc | Length=0x8 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | PE Identifier | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 PE Identifier: 32 bits (unsigned integer) 769 Uniquely identifies the PE in the pool. The PE picks its identifier 770 when it starts up. See Section ???? in ASAP [3] for recommendations 771 on PE identifier generation. 773 3.13 PE Checksum Parameter 775 This parameter defines a TLV that carries a PE Checksum. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type = 0xd | Length=0x8 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | PE Checksum | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 PE Checksum: 32 bits (unsigned integer) 787 An overall checksum of all PEs in the current namespace owned by an 788 ENRP server (which is normally the sender of this TLV). The 789 definition and calculation of this checksum is defined in Section 790 ???? in ENRP [4]. 792 4. Common Message Formats 794 The figure below illustrates the common format for all ASAP and ENRP 795 messages. Each message is formatted with a Message Type field, a 796 message-specific Flag field, a Message Length field, and a Value 797 field. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Message Type | Msg Flags | Message Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 : : 805 : Message Value : 806 : : 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Message Type: 8 bits (unsigned integer) 811 This field identifies the type of information contained in the 812 Message Value field. It takes a value from 0 to 254. The value of 813 255 is reserved for future use as an extension field. 815 Message Types are encoded such that the highest-order two bits 816 specify the action that must be taken if the message receiver does 817 not recognize the Message Type. 819 00 Stop processing this message and discard it. 821 01 Stop processing this message and discard it, and report the 822 unrecognized message in an 'Unrecognized Message' error (see 823 Section 3.10.3). 825 10 reserved. 827 11 reserved. 829 Message Flags: 8 bits 831 The usage of these bits depends on the message type as given by the 832 Message Type. Unless otherwise specified, they are set to zero on 833 transmit and are ignored on receipt. 835 Message Length: 16 bits (unsigned integer) 837 This value represents the size of the message in bytes including the 838 Message Type, Message Flags, Message Length, and Message Value 839 fields. Therefore, if the Message Value field is zero-length, the 840 Length field will be set to 4. 842 Note, the value in Message Length field will NOT cover any padding at 843 the end of this message. 845 Message Value: variable length 847 The Message Value field contains the actual information to be 848 transferred in the message. The usage and format of this field is 849 dependent on the Message Type. 851 The total length of a message (including Type, Length and Value 852 fields) MUST be a multiple of 4 bytes. If the length of the message 853 is not a multiple of 4 bytes, the sender MUST pad the message with 854 all zero bytes and this padding is not included in the message length 855 field. The sender should never pad with more than 3 bytes. The 856 receiver MUST ignore the padding bytes. 858 5. Security Considerations 860 This document contains common parameter formats only. As such it 861 specifies no new security constraints on either ENRP or ASAP. 862 Details on ENRP and ASAP security constraints are addressed in ENRP 863 [4] and ASAP [3] . 865 6 Normative References 867 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 868 9, RFC 2026, October 1996. 870 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 871 Levels", BCP 14, RFC 2119, March 1997. 873 [3] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 874 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 875 (work in progress), June 2004. 877 [4] Xie, Q., Stewart, R. and M. Stillman, "Endpoint Name Resolution 878 Protocol (ENRP)", draft-ietf-rserpool-enrp-08 (work in 879 progress), June 2004. 881 Authors' Addresses 883 Randall R. Stewart 884 Cisco Systems, Inc. 885 8725 West Higgins Road 886 Suite 300 887 Chicago, IL 60631 888 USA 890 Phone: +1-815-477-2127 891 EMail: rrs@cisco.com 893 Qiaobing Xie 894 Motorola, Inc. 895 1501 W. Shure Drive, #2309 896 Arlington Heights, IL 60004 897 USA 899 Phone: +1-847-632-3028 900 EMail: qxie1@email.mot.com 901 Maureen Stillman 902 Nokia 903 127 W. State Street 904 Ithaca, NY 14850 905 USA 907 Phone: +1-607-273-0724 908 EMail: maureen.stillman@nokia.com 910 Michael Tuexen 912 Germany 914 Phone: 915 EMail: tuexen@fh-muenster.de 917 Intellectual Property Statement 919 The IETF takes no position regarding the validity or scope of any 920 Intellectual Property Rights or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; nor does it represent that it has 924 made any independent effort to identify any such rights. Information 925 on the procedures with respect to rights in RFC documents can be 926 found in BCP 78 and BCP 79. 928 Copies of IPR disclosures made to the IETF Secretariat and any 929 assurances of licenses to be made available, or the result of an 930 attempt made to obtain a general license or permission for the use of 931 such proprietary rights by implementers or users of this 932 specification can be obtained from the IETF on-line IPR repository at 933 http://www.ietf.org/ipr. 935 The IETF invites any interested party to bring to its attention any 936 copyrights, patents or patent applications, or other proprietary 937 rights that may cover technology that may be required to implement 938 this standard. Please address the information to the IETF at 939 ietf-ipr@ietf.org. 941 Disclaimer of Validity 943 This document and the information contained herein are provided on an 944 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 945 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 946 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 947 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 948 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 949 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 951 Copyright Statement 953 Copyright (C) The Internet Society (2004). This document is subject 954 to the rights, licenses and restrictions contained in BCP 78, and 955 except as set forth therein, the authors retain all their rights. 957 Acknowledgment 959 Funding for the RFC Editor function is currently provided by the 960 Internet Society.