idnits 2.17.1 draft-ietf-rserpool-common-param-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 5) being 60 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 16 instances of lines with control characters in the document. ** The abstract seems to contain references ([ENRP], [ASAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (May 2, 2002) is 8030 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) == Missing Reference: 'TBD' is mentioned on line 733, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. 'ENRP') -- Possible downref: Non-RFC (?) normative reference: ref. 'ASAP' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. R. Stewart 3 INTERNET-DRAFT Cisco Systems Inc. 4 Q. Xie 5 Motorola, Inc. 7 expires in six months May 2, 2002 9 Aggregate Server Access Protocol and 10 Endpoint Name Resolution Protocol 11 Common Parameters 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Aggregate Server Access Protocol (ASAP) in conjunction with the 31 Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high 32 availability data transfer mechanism over IP networks. 34 Both protocols work together and so share many common parameters 35 used in message formats. This document details the common message 36 parameters shared between the two protocols. This document provides 37 parameter formats only, for procedures and message composition 38 please refer to the respective [ASAP] and [ENRP] documents. 40 Table Of Contents 42 1. Introduction...............................................2 43 1.1 Conventions...............................................2 44 2. Parameters in General......................................2 45 3. ENRP-ASAP Common Parameters................................3 46 3.1 IPv4 Address Parameter....................................4 47 3.2 IPv6 Address Parameter ...................................5 48 3.3 SCTP Transport Parameter..................................5 49 3.4 TCP Transport Parameter...................................6 50 3.5 UDP Transport Parameter...................................6 51 3.6. Pool Member Selection Policy Parameter...................7 52 3.6.1 Round Robin Policy......................................8 53 3.6.2 Least Used Policy.......................................8 54 3.6.3 Least Used with Degradation Policy......................8 55 3.6.4 Weighted Round Robin Policy.............................9 56 3.7 Pool Handle Parameter.....................................9 57 3.8 Pool Element Parameter....................................9 58 3.9 Pool Element Handle Parameter.............................11 59 3.10 Server Information Parameter.............................11 60 3.11 Operation Error Parameter................................12 61 3.11.1 Unrecognized Parameter Error...........................13 62 3.11.2 Unrecognized Message Error.............................14 63 3.11.3 Authorization Failure Error............................14 64 3.11.4 Invalid Values Error...................................14 65 3.11.5 Non-unique PE Identifier Error.........................15 66 3.11.6 Pooling Policy Inconsistent Error......................15 67 4. Common Message Formats.....................................15 68 5. Security Considerations....................................17 69 6. References.................................................17 70 7. Acknowledgments............................................17 71 8. Authors' Addresses.........................................17 73 1. Introduction 75 Aggregate Server Access Protocol (ASAP) in conjunction with the 76 Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high 77 availability data transfer mechanism over IP networks. 79 Both protocols work together and so share many common parameters 80 used in message formats. This document details the common message 81 parameters shared between the two protocols. This document provides 82 parameter formats only, for procedures and message composition 83 please refer to the respective [ASAP] and [ENRP] documents. 85 1.1 Conventions 87 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 88 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 89 they appear in this document, are to be interpreted as described in 90 [RFC2119]. 92 2. Parameters in General 94 All parameters parameters described below MUST be in Network Byte 95 Order (a.k.a. Big Endian, i.e., the most significant byte first) 96 during transmission. For fields with a length bigger than 4 octets, 97 a number in a pair of parentheses may follow the field name to 98 indicate the length of the field in number of octets. 100 Please note that messages in both ENRP and ASAP are often 101 composed of multiple parameters. These parameters may also 102 be nested. In such a case a nested parameter will include 103 the length of the padding between the nested parameters 104 but not the last padding. 106 3 ENRP-ASAP Common Parameters 108 Parameters are defined in the following Type-length-value (TLV) 109 format: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Parameter Type | Parameter Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 : : 117 : Parameter Value : 118 : : 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Parameter Type: 16 bits (unsigned integer) 123 The Type field is a 16 bit identifier of the type of parameter. 124 It takes a value of 0 to 65534. 126 The value of 65535 is reserved for IETF-defined extensions. 127 Values other than those defined in specific ENRP parameter 128 description are reserved for use by IETF. 130 Parameter Length: 16 bits (unsigned integer) 132 The Parameter Length field contains the size of the parameter in 133 bytes, including the Parameter Type, Parameter Length, and 134 Parameter Value fields. Thus, a parameter with a zero-length 135 Parameter Value field would have a Length field of 4. The 136 Parameter Length does not include any padding bytes that may 137 appear at the end of this parameter. 139 Parameter Value: variable-length. 141 The Parameter Value field contains the actual information to be 142 transferred in the parameter. 144 The total length of a parameter (including Type, Parameter Length and 145 Value fields) MUST be a multiple of 4 bytes. If the length of the 146 parameter is not a multiple of 4 bytes, the sender pads the Parameter 147 at the end (i.e., after the Parameter Value field) with all zero 148 bytes. The length of this padding is not included in the parameter 149 length field. A sender SHOULD NOT pad with more than 3 bytes. The 150 receiver MUST ignore the padding bytes. 152 (Editor's note: clarify further that any padding inside in the 153 parameter, such as the padding in sub-param is included in the 154 total length) 156 The Parameter Types are encoded such that the highest-order two bits 157 specify the action that must be taken if the processing endpoint does 158 not recognize the Parameter Type. 160 00 - Stop processing this ENRP or ASAP message and discard it, do 161 not process any further parameters within it. 163 01 - Stop processing this ENRP or ASAP message and discard it, do 164 not process any further parameters within it, and report the 165 unrecognized parameter in an 'Unrecognized Parameter' error. 167 10 - Skip this parameter and continue processing. 169 11 - Skip this parameter and continue processing, but report the 170 unrecognized parameter in an 'Unrecognized Parameter' error 171 (see Section 3.11?). 173 The values of parameter types are defined as follows: 175 Value Parameter Type 176 ----- ---------- 177 0x0 - (reserved by IETF) 178 0x1 - IPv4 Address 179 0x2 - IPv6 Address 180 0x3 - SCTP Transport 181 0x4 - TCP Transport 182 0x5 - UDP Transport 183 0x6 - Pool Member Selection Policy 184 0x7 - Pool Handle 185 0x8 - Pool Element 186 0x9 - Pool Element Handle 187 0xa - Server Information 188 0xb - Operation Error 189 others - (reserved by IETF) 191 3.1 IPv4 Address Parameter 193 This parameter defines a TLV that carries an IPv4 address. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type = 0x1 | Length = 0x8 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | IPv4 Address | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 IPv4 Address: 32 bits (unsigned integer) 205 Contains an IPv4 address. It is binary encoded. 207 3.2 IPv6 Address Parameter 209 This parameter defines a TLV that carries an IPv6 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 = 0x2 | Length = 20 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 | IPv6 Address | 218 | | 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 IPv6 Address: 128 bit (unsigned integer) 224 Contains an IPv6 address. It is binary encoded. 226 3.3 SCTP Transport Parameter 228 This parameter defines a TLV that describes a user transport using 229 SCTP protocol. 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 = 0x3 | Length = variable | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | SCTP port | (reserved) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 : IPv4 or IPv6 Address #1 : 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 : : 241 : ... : 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 : IPv4 or IPv6 Address #n : 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Length: 16 bits (unsigned integer) 248 Indicates the entire length of the parameter in number of 249 octets, including the Type, Length, SCTP port, reserved fields, 250 and all IP address parameters present. 252 SCTP port: 16 bits (unsigned integer) 254 The SCTP port number signed to this SCTP user transport. 256 IPv4 or IPv6 Address #1 - #n: 258 Each indicates an IPv4 or IPv6 address parameter (as defined 259 above in sections 3.1 and 3.2) assigned to this SCTP user 260 transport. At least one IP address parameter MUST be present in 261 an SCTP transport parameter. 263 3.4 TCP Transport Parameter 265 This parameter defines a TLV that describes a user transport using 266 TCP protocol. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type = 0x4 | Length = variable | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | TCP port | (reserved) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 : IPv4 or IPv6 Address : 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Length: 16 bits (unsigned integer) 280 Indicates the entire length of the parameter in number of 281 octets, including the Type, Length, TCP port, reserved fields, 282 and IP address parameter. 284 TCP port: 16 bits (unsigned integer) 286 The TCP port number signed to this TCP user transport. 288 IPv4 or IPv6 Address: 290 Indicates an IPv4 or IPv6 address parameter (as defined above in 291 sections 3.1 and 3.2) assigned to this TCP user 292 transport. Unlike in an SCTP transport, only one IP address 293 parameter can be present in a TCP transport parameter. 295 3.5 UDP Transport Parameter 297 This parameter defines a TLV that describes a user transport using 298 UDP 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 = 0x5 | Length = variable | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | UDP port | (reserved) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : IPv4 or IPv6 Address : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Length: 16 bits (unsigned integer) 312 Indicates the entire length of the parameter in number of 313 octets, including the Type, Length, UDP port, reserved fields, 314 and IP address parameter. 316 UDP port: 16 bits (unsigned integer) 318 The UDP port number signed to this UDP user transport. 320 IPv4 or IPv6 Address: 322 Indicates an IPv4 or IPv6 address parameter (as defined above in 323 sections 3.1 and 3.2) assigned to this UDP user 324 transport. Unlike in an SCTP transport, only one IP address 325 parameter can be present in a UDP transport parameter. 327 3.6. Pool Member Selection Policy Parameter 329 This parameter defines a pool member selection policy. RSERPOOL 330 supports multiple pool member selection polices and also allows 331 definition of new selection polices in the future. 333 The enforcement rules and handling procedures of all the policies 334 are defined in Section xxxxx in [ASAP]. 336 All pool member selection policies, both present and future, MUST 337 use the following general parameter format: 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 = 0x6 | Length = variable | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Policy Type | Policy-specific Data.... 345 +-+-+-+-+-+-+-+-+------------------------------------------------ 347 Length: 16 bits (unsigned integer) 349 Indicates the entire length of the parameter in number of 350 octets, including the Type, Length, Policy Type fields, 351 and the Policy-specific Data. 353 Note, the value in Length field will NOT cover any padding at 354 the end of the parameter, if there is one. 356 Policy Type: 8 bits (unsigned integer) 358 Specifies the type of selection policy. 360 Currently defined policy types are: 362 Value Policy 363 ----- --------- 364 0x0 (reserved by IETF) 365 0x1 Round Robin 366 0x2 Least Used 367 0x3 Least Used with Degradation (a.k.a. dog pile) 368 0x4 Weighted Round Robin 369 others (reserved by IETF) 371 Policy-specific Data: 373 The structure and fields for each presently defined policy types 374 are described in detail in the following subsections. The 375 enforcement rules and handling procedures of these policies 376 are defined in Section xxxxx in [ASAP]. 378 3.6.1 Round Robin Policy 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Param Type = 0x6 | Length = 0x8 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Policy=0x1 | (reserved) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 388 Reserved: 24 bits 390 MUST be set to 0's by sender and ignored by the receiver. 392 3.6.2 Least Used Policy 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Param Type = 0x6 | Length = 0x8 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Policy=0x2 | Load | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 402 Load: 24 bits (signed integer) 404 [TBD] 406 3.6.3 Least Used with Degradation Policy 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Param Type = 0x6 | Length = 0x8 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Policy=0x3 | Load | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 416 Load: 24 bits (signed integer) 418 [TBD] 420 3.6.4 Weighted Round Robin Policy 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Param Type = 0x6 | Length = 0x8 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Policy=0x4 | Weight | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 430 Weight: 24 bits (signed integer) 432 [TBD] 434 3.7 Pool Handle Parameter 436 This parameter holds a pool handle (i.e., a pool name). 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 0x7 | Length=variable | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 : : 444 : Pool Handle string : 445 : : 446 : : 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Length: 16 bits (unsigned integer) 451 Indicates the entire length of the parameter in number of 452 octets, including the Type, Length, and Pool Handle string. 454 Note, the value in Length field will NOT cover any padding at 455 the end of the parameter. 457 Pool Handle: 459 Defined as a NULL terminated ASCII string. 461 3.8 Pool Element Parameter 463 This parameter is used in multiple ENRP messages to represent an 464 ASAP endpoint (i.e., a PE in a pool) and the associated 465 information, such as its transport address(es), selection policy, 466 and other operational or status information of the PE. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type = 0x8 | Length=variable | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | PE Identifier | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Registration Life | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 : User Transport param #1 : 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 : User Transport param #2 : 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 : : 482 : ..... : 483 : : 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 : User Transport param #k : 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 : Member Selection Policy param : 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Length: 16 bits (unsigned integer) 492 Indicates the entire length of the parameter in number of 493 octets, including the Type, Length, PE Identifier, Registration 494 Life, all User Transports, and Member Selection Policy 495 parameters. 497 Note, the value in Length field will NOT cover any padding at 498 the end of this Pool Element parameter. 500 PE Identifier: 32 bits (unsigned integer) 502 Uniquely identifies the PE in the pool. The PE picks its 503 identifier when it starts up. See Section ???? in [ASAP] for 504 recommendations on PE identifier generation. 506 Registration Life: 32 bits (signed integer) 508 Indicates the life time of the registration in number of 509 seconds. A value of -1 indicates infinite life time. 511 User Transport #1-#k: 513 Each of the User Transport parameters in a PE parameter can be 514 either an SCTP, TCP, or UDP type transport parameter (see 515 sections 3.3, 3.4, 3.5). A PE MUST have at least 1 User 516 Transport and MAY have multiple User Transports. When multiple 517 transports are present, they MAY be of mixed types (i.e., SCTP, 518 TCP, and UDP). 520 Member Selection Policy: 522 Contains one of the defined member selection policy parameters 523 (see section 3.6). 525 3.9 Pool Element Handle Parameter 527 This parameter is used to encode a logical handler that points to 528 an individual PE in a specific pool. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type = 0x9 | Length=variable | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 : Pool Handle Parameter : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 : PE's User Transport : 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Length: 16 bits (unsigned integer) 542 Indicates the entire length of the parameter in number of 543 octets. 545 Note, the value in Length field will NOT cover any padding at 546 the end of the parameter. 548 Pool Handle: 550 Specifies the pool to which the PE belongs. 552 PE's User Transport: 554 Indicates the user transport (or one of the user transports) of 555 the PE. This can be either an SCTP, TCP, or UDP type transport. 557 3.10 Server Information Parameter 559 This parameter is used in ENRP to pass basic information of an ENRP 560 server. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type = 0xa | Length=variable | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Server ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |M| (reserved) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : Server Transport : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Length: 16 bits (unsigned integer) 575 Indicates the entire length of the parameter in number of 576 octets. 578 Note, the value in Length field will NOT cover any padding at 579 the end of the parameter. 581 Server ID: 32 bit (unsiged integer) 583 This is the ID of the ENRP server, as defined in Section 4.2.1? 584 in [ENRP]. 586 Multicast Flag (M): 1 bit 588 If set to '1', indicates the ENRP server is allowed to use 589 multicast for communications. If set to '0', multicast is not 590 used by the server. 592 Reserved: 31 bits 594 MUST be set to 0's by sender and ignored by the receiver. 596 Server Transport: 598 This is an SCTP Transport Parameter, as defined in Section 3.3?, 599 that contains the network access address(es), SCTP port number, 600 etc. of the ENRP server. 602 3.11 Operation Error Parameter 604 This parameter is used in both ENPR and ASAP for a message sender 605 to report an error(s) to a message receiver. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type = 0xb | Length=variable | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 : : 613 : one or more Error Causes : 614 : : 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Length: 16 bits (unsigned integer) 619 Indicates the entire length of the parameter in number of 620 octets. 622 Note, the value in Length field will NOT cover any padding at 623 the end of the parameter. 625 Error causes are defined as variable-length parameters using the 626 format described in 3.2.1, i.e.: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Cause Code | Cause Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 : Cause-specific Information : 634 : : 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Cause Code: 16 bits (unsigned integer) 639 Defines the type of error condition being reported. 641 Cause Code 642 Value Cause Code 643 --------- ---------------- 644 0x0 (reserved by IETF) 645 0x1 Unrecognized Parameter 646 0x2 Unrecognized Message 647 0x3 Authorization Failure 648 0x4 Invalid Values 649 0x5 Non-unique PE Identifier 650 0x6 Pooling Policy Inconsistent 651 other values (reserved by IETF) 653 Cause Length: 16 bits (unsigned integer) 655 Set to the size of the parameter in bytes, including the Cause 656 Code, Cause Length, and Cause-Specific Information fields, but 657 not including any padding at the end of this error cause TLV. 659 Cause-specific Information: variable length 661 This field carries the details of the error condition. 663 The following subsections (3.11.1 - 3.11.6) define specific error 664 causes. 666 3.11.1 Unrecognized Parameter Error 668 This error cause is used by a receiver to report an unrecognized 669 parameter found in a received message to the message sender. 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Cause Code = 0x1 | Cause Length = variable | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 : : 677 : Offending Parameter TLV : 678 : : 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Offending Parameter TLV: 682 The complete TLV of the parameter that the receiver of the 683 message fails to recognize. 685 3.11.2 Unrecognized Message Error 687 This error cause is used by a receiver to report an unrecognized 688 message type to the message sender. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Cause Code = 0x2 | Cause Length = variable | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 : : 696 : Offending Message TLV : 697 : : 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Offending Message TLV: 702 The complete TLV of the receive message whose type the receiver 703 of the message fails to recognize. 705 3.11.3 Authorization Failure Error 707 This error cause is used by a message receiver to report to the 708 message sender that the received message has failed the 709 authorization check. 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Cause Code = 0x3 | Cause Length = variable | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 : : 717 : [TBD] 718 : : 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 3.11.4 Invalid Values Error 723 This error cause is used by a message receiver to report to the 724 message sender that the received message has one or more fields 725 that contains an invalid value. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Cause Code = 0x4 | Cause Length = variable | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 : : 733 : [TBD] 734 : : 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 3.11.5 Non-unique PE Identifier Error 739 This error cause is used by an ENRP server to report a collission 740 between two PE identifers (i.e., two PEs try to register with the 741 same PE identifer). 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Cause Code = 0x5 | Cause Length = 0x8 | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Bad PE Identifer | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Bad PE Identifer: 753 This is the value of the PE identifer which is found colliding 754 with an existing PE identifer. 756 3.11.6 Pooling Policy Inconsistent Error 758 This error cause is used by an ENRP server to report an 759 inconsistancy between the selection policy of a registering PE and 760 the current overall pool policy. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Cause Code = 0x2 | Cause Length = variable | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 : : 768 : Offending Policy TLV : 769 : : 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Offending Policy TLV: 774 The complete TLV of the selection policy parameter (see Section 775 3.6?) that is found in conflict with the current pool policy. 777 4. Common Message Formats 779 The figure below illustrates the common format for all ASAP and 780 ENRP messages. Each message is formatted with a Message Type field, 781 a message-specific Flag field, a Message Length field, and a Value 782 field. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Message Type | Msg Flags | Message Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 : : 790 : Message Value : 791 : : 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Message Type: 8 bits (unsigned integer) 796 This field identifies the type of information contained in the 797 Message Value field. It takes a value from 0 to 254. The value 798 of 255 is reserved for future use as an extension field. 800 Message Types are encoded such that the highest-order two bits 801 specify the action that must be taken if the message receiver 802 does not recognize the Message Type. 804 00 - Stop processing this message and discard it. 806 01 - Stop processing this message and discard it, and report the 807 unrecognized message in an 'Unrecognized Message' error 808 (see Section 3.11). 810 10 - reserved. 812 11 - reserved. 814 Message Flags: 8 bits 816 The usage of these bits depends on the message type as given by 817 the Message Type. Unless otherwise specified, they are set to 818 zero on transmit and are ignored on receipt. 820 Message Length: 16 bits (unsigned integer) 822 This value represents the size of the message in bytes including 823 the Message Type, Message Flags, Message Length, and Message 824 Value fields. Therefore, if the Message Value field is 825 zero-length, the Length field will be set to 4. The Message 826 Length field does not count any padding. 828 Note, the value in Message Length field will NOT cover any 829 padding at the end of this message. 831 Message Value: variable length 833 The Message Value field contains the actual information to be 834 transferred in the message. The usage and format of this field 835 is dependent on the Message Type. 837 The total length of a message (including Type, Length and Value 838 fields) MUST be a multiple of 4 bytes. If the length of the 839 message is not a multiple of 4 bytes, the sender MUST pad the 840 message with all zero bytes and this padding is not included in the 841 message length field. The sender should never pad with more than 3 842 bytes. The receiver MUST ignore the padding bytes. 844 5. Security Considerations 846 This document contains common parameter formats only. As such 847 it specifies no new security constraints on either ENRP or 848 ASAP. Details on ENRP and ASAP security constraints are a 849 addressed in [ENRP] and [ASAP]. 851 6. References 853 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 854 3", BCP 9, RFC 2026, October 1996. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", 860 draft-ietf-rserpool-enrp-01.txt, work in progress. 862 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 863 (ASAP)", , work in progress. 865 7. Acknowledgments 867 The authors wish to thank John Loughney, Lyndon Ong, and Maureen 868 Stillman and many others for their invaluable comments. 870 8. Authors' Addresses 872 Randall R. Stewart Tel: +1-815-477-2127 873 Cisco Systems, Inc. EMail: rrs@cisco.com 874 8725 West Higgins Road 875 Suite 300 876 Chicago, Ill 60631 878 Qiaobing Xie Phone: +1-847-632-3028 879 Motorola, Inc. EMail: qxie1@email.mot.com 880 1501 W. Shure Drive, #2309 881 Arlington Heights, IL 60004 882 USA 883 Expires in six months from May 2, 2002