idnits 2.17.1 draft-ietf-rserpool-common-param-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 653 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 (May 14, 2003) is 7645 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 764 == Unused Reference: '1' is defined on line 842, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 848, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. '3') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '4') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '5') Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: November 12, 2003 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Siemens AG 10 May 14, 2003 12 Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution 13 Protocol (ENRP) Parameters 14 draft-ietf-rserpool-common-param-04.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 12, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document details the parameters of the Aggregate Server Access 45 Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) 46 protocols defined within the Reliable Server Pooling (RSERPOOL) 47 architecture. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Parameters in General . . . . . . . . . . . . . . . . . . 4 54 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . 5 55 3.1 IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 6 56 3.2 IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 57 3.3 SCTP Transport Parameter . . . . . . . . . . . . . . . . . 7 58 3.4 TCP Transport Parameter . . . . . . . . . . . . . . . . . 8 59 3.5 UDP Transport Parameter . . . . . . . . . . . . . . . . . 9 60 3.6 Pool Member Selection Policy Parameter . . . . . . . . . . 10 61 3.6.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 12 62 3.6.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 12 63 3.6.3 Least Used with Degradation Policy . . . . . . . . . . . . 12 64 3.6.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 13 65 3.7 Pool Handle Parameter . . . . . . . . . . . . . . . . . . 13 66 3.8 Pool Element Parameter . . . . . . . . . . . . . . . . . . 13 67 3.9 Server Information Parameter . . . . . . . . . . . . . . . 15 68 3.10 Operation Error Parameter . . . . . . . . . . . . . . . . 16 69 3.10.1 Unspecified Error . . . . . . . . . . . . . . . . . . . . 17 70 3.10.2 Unrecognized Parameter Error . . . . . . . . . . . . . . . 17 71 3.10.3 Unrecognized Message Error . . . . . . . . . . . . . . . . 17 72 3.10.4 Invalid Values Error . . . . . . . . . . . . . . . . . . . 17 73 3.10.5 Non-unique PE Identifier Error . . . . . . . . . . . . . . 18 74 3.10.6 Inconsistent Pool Policy Error . . . . . . . . . . . . . . 18 75 3.10.7 Lack of Resources Error . . . . . . . . . . . . . . . . . 18 76 3.10.8 Inconsistent Transport Type Error . . . . . . . . . . . . 18 77 3.10.9 Inconsistent Data/Control Configuration Error . . . . . . 18 78 3.11 Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 18 79 3.12 PE Identifier Parameter . . . . . . . . . . . . . . . . . 19 80 4. Common Message Formats . . . . . . . . . . . . . . . . . . 20 81 5. Security Considerations . . . . . . . . . . . . . . . . . 22 82 Normative References . . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23 84 Intellectual Property and Copyright Statements . . . . . . 25 86 1. Introduction 88 Aggregate Server Access Protocol (ASAP) [4] in conjunction with the 89 Endpoint Name Resolution Protocol (ENRP) [5] provides a high 90 availability data transfer mechanism over IP networks. 92 Both protocols work together and so share many common parameters used 93 in message formats. This document details the common message 94 parameters shared between the two protocols. This document provides 95 parameter formats only, for procedures and message composition please 96 refer to the respective ASAP [4] and ENRP [5] documents. 98 1.1 Conventions 100 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 101 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 102 they appear in this document, are to be interpreted as described in 103 RFC2119 [2]. 105 2. Parameters in General 107 All parameters described below MUST be in Network Byte Order (a.k.a. 108 Big Endian, i.e., the most significant byte first) during 109 transmission. 111 Please note that messages in both ENRP and ASAP are often composed of 112 multiple parameters. These parameters may also be nested. In such a 113 case a nested parameter will include the length of the padding 114 between the nested parameters but not the last padding. 116 3. ENRP-ASAP Common Parameters 118 Parameters are defined in the following Type-Length-Value (TLV) 119 format: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Parameter Type | Parameter Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 : : 127 : Parameter Value : 128 : : 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Parameter Type: 16 bits (unsigned integer) 133 The Type field is a 16 bit identifier of the type of parameter. It 134 takes a value of 0 to 65534. 136 The value of 65535 is reserved for IETF-defined extensions. Values 137 other than those defined in specific ENRP parameter description are 138 reserved by IETF. (Additional types, when needed, will be defined in 139 the future through appropriate IETF/IANA procedures.) 141 The Parameter Types are encoded such that the highest-order two bits 142 specify the action that must be taken if the processing endpoint does 143 not recognize the Parameter Type. 145 00 Stop processing this ENRP or ASAP message and discard it, do not 146 process any further parameters within it. 148 01 Stop processing this ENRP or ASAP message and discard it, do not 149 process any further parameters within it, and report the 150 unrecognized parameter in an 'Unrecognized Parameter' error (see 151 Section 3.10). 153 10 Skip this parameter and continue processing. 155 11 Skip this parameter and continue processing, but report the 156 unrecognized parameter in an 'Unrecognized Parameter' error (see 157 Section 3.10). 159 The values of parameter types are defined as follows: 161 Value Parameter Type 162 ----- ---------- 163 0x0 - (reserved by IETF) 164 0x1 - IPv4 Address 165 0x2 - IPv6 Address 166 0x3 - SCTP Transport 167 0x4 - TCP Transport 168 0x5 - UDP Transport 169 0x6 - Pool Member Selection Policy 170 0x7 - Pool Handle 171 0x8 - Pool Element 172 0x9 - Server Information 173 0xa - Operation Error 174 0xb - Cookie 175 0xc - PE Identifier 177 others - (reserved by IETF) 179 Parameter Length: 16 bits (unsigned integer) 181 The Parameter Length field contains the size of the parameter in 182 bytes, including the Parameter Type, Parameter Length, and Parameter 183 Value fields. Thus, a parameter with a zero-length Parameter Value 184 field would have a Length field of 4. 186 The total length of a parameter (including Type, Parameter Length and 187 Value fields) MUST be a multiple of 4 bytes. If the length of the 188 parameter is not a multiple of 4 bytes, the sender MUST pad the 189 parameter at the end (i.e., after the Parameter Value field) with all 190 zero bytes. The length of this padding is not included in the 191 Parameter Length field. A sender MUST NOT pad with more than 3 192 bytes. The receiver MUST ignore the padding bytes. 194 (Editor's note: clarify further that any padding inside in the 195 parameter, such as the padding in sub-param is included in the total 196 length) 198 Parameter Value: variable-length. 200 The Parameter Value field contains the actual information to be 201 transferred in the parameter. 203 3.1 IPv4 Address Parameter 205 This parameter defines a TLV that carries an IPv4 address. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type = 0x1 | Length = 0x8 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | IPv4 Address | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 IPv4 Address: 32 bits (unsigned integer) 217 Contains an IPv4 address. It is binary encoded. 219 3.2 IPv6 Address Parameter 221 This parameter defines a TLV that carries an IPv6 address. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type = 0x2 | Length = 0x14 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 | IPv6 Address | 230 | | 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 IPv6 Address: 128 bit (unsigned integer) 236 Contains an IPv6 address. It is binary encoded. 238 3.3 SCTP Transport Parameter 240 This parameter defines a TLV that describes a user transport using 241 SCTP protocol. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type = 0x3 | Length = variable | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | SCTP port | Transport Use | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 : IPv4 or IPv6 Address #1 : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 : : 253 : ... : 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 : IPv4 or IPv6 Address #n : 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Length: 16 bits (unsigned integer) 260 Indicates the entire length of the parameter in number of octets, 261 including the Type, Length, SCTP port, reserved fields, and all IP 262 address parameters present. 264 SCTP port: 16 bits (unsigned integer) 266 The SCTP port number signed to this SCTP user transport. 268 Transport use: 16 bits (unsigned integer) 270 This field represents how the pool element intends this transport 271 address to be used. The field MUST be populated with one of the 272 following values: 274 Type | Value 275 ------------------+---------------- 276 DATA ONLY | 0x0000 277 DATA plus CONTROL | 0x0001 279 IPv4 or IPv6 Address #1 - #n: 281 Each indicates an IPv4 or IPv6 address parameter (as defined above in 282 Section 3.1 and Section 3.2) assigned to this SCTP user transport. An 283 SCTP Transport parameter may have a mixed list of IPv4 and IPv6 284 addresses and at least one IP address parameter MUST be present in an 285 SCTP transport parameter. 287 3.4 TCP Transport Parameter 288 This parameter defines a TLV that describes a user transport using 289 TCP protocol. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type = 0x4 | Length = variable | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TCP port | Transport Use | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 : IPv4 or IPv6 Address : 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Length: 16 bits (unsigned integer) 303 Indicates the entire length of the parameter in number of octets, 304 including the Type, Length, TCP port, reserved fields, and IP address 305 parameter. 307 TCP port: 16 bits (unsigned integer) 309 The TCP port number signed to this TCP user transport. 311 Transport use: 16 bits (unsigned integer) 313 This field represents how the pool element intends this transport 314 address to be used. The field MUST be populated with one of the 315 following values: 317 Type | Value 318 ------------------+---------------- 319 DATA ONLY | 0x0000 320 DATA plus CONTROL | 0x0001 322 IPv4 or IPv6 Address: 324 Indicates an IPv4 or IPv6 address parameter (as defined above in 325 Section 3.1 and Section 3.2) assigned to this TCP user transport. 326 Unlike in an SCTP transport, only one IP address parameter can be 327 present in a TCP transport parameter. 329 3.5 UDP Transport Parameter 331 This parameter defines a TLV that describes a user transport using 332 UDP protocol. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type = 0x5 | Length = variable | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | UDP port | (reserved) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 : IPv4 or IPv6 Address : 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Length: 16 bits (unsigned integer) 346 Indicates the entire length of the parameter in number of octets, 347 including the Type, Length, UDP port, reserved fields, and IP address 348 parameter. 350 UDP port: 16 bits (unsigned integer) 352 The UDP port number signed to this UDP user transport. 354 IPv4 or IPv6 Address: 356 Indicates an IPv4 or IPv6 address parameter (as defined above in 357 Section 3.1 and Section 3.2) assigned to this UDP user transport. 358 Unlike in an SCTP transport, only one IP address parameter can be 359 present in a UDP transport parameter. 361 Note: A UDP port MUST NOT be used for control information. For this 362 reason, no Transport Use field is provided. UDP MUST always be 363 treated as a "Data Only" type transport use. 365 3.6 Pool Member Selection Policy Parameter 367 This parameter defines a pool member selection policy. RSERPOOL 368 supports multiple pool member selection policies and also allows 369 definition of new selection policies in the future. 371 The enforcement rules and handling procedures of all the policies are 372 defined in Section xxxxx in ASAP [4]. 374 All pool member selection policies, both present and future, MUST use 375 the following general parameter format: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type = 0x6 | Length = variable | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Policy Type | Policy-specific Data.... 383 +-+-+-+-+-+-+-+-+------------------------------------------------ 385 Length: 16 bits (unsigned integer) 387 Indicates the entire length of the parameter in number of octets, 388 including the Type, Length, Policy Type, and the Policy-specific Data 389 fields. 391 Note, the Length field value will NOT include any padding at the end 392 of the parameter. 394 Policy Type: 8 bits (unsigned integer) 396 Specifies the type of selection policy. 398 Currently defined policy types are: 400 Value Policy 401 ----- --------- 402 0x0 (reserved by IETF) 403 0x1 Round Robin 404 0x2 Least Used 405 0x3 Least Used with Degradation (a.k.a. dog pile) 406 0x4 Weighted Round Robin 407 others (reserved by IETF) 409 Policy-specific Data: 411 The structure and fields for each presently defined policy types are 412 described in detail in the following subsections. The enforcement 413 rules and handling procedures of these policies are defined in 414 Section xxxxx in ASAP [4]. 416 3.6.1 Round Robin Policy 418 0 1 2 3 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Param Type = 0x6 | Length = 0x8 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Policy=0x1 | (reserved) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 426 Reserved: 24 bits 428 MUST be set to 0's by sender and ignored by the receiver. 430 3.6.2 Least Used Policy 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Param Type = 0x6 | Length = 0x8 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Policy=0x2 | Load | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 440 Load: 24 bits (signed integer) 442 (TBD) 444 3.6.3 Least Used with Degradation Policy 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Param Type = 0x6 | Length = 0x8 | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Policy=0x3 | Load | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 454 Load: 24 bits (signed integer) 456 (TBD) 458 3.6.4 Weighted Round Robin Policy 460 0 1 2 3 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Param Type = 0x6 | Length = 0x8 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Policy=0x4 | Weight | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 468 Load: 24 bits (signed integer) 470 (TBD) 472 3.7 Pool Handle Parameter 474 This parameter holds a pool handle (i.e., a pool name). 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type = 0x7 | Length=variable | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 : : 482 : Pool Handle : 483 : : 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Length: 16 bits (unsigned integer) 488 Indicates the entire length of the parameter in number of octets, 489 including the Type, Length, and Pool Handle string. 491 Note, the value in Length field will NOT cover any padding at the end 492 of the parameter. 494 Pool Handle: 496 defined as a sequence of (Length - 4) bytes. 498 3.8 Pool Element Parameter 500 This parameter is used in multiple ENRP messages to represent an ASAP 501 endpoint (i.e., a PE in a pool) and the associated information, such 502 as its transport address, selection policy, and other operational or 503 status information of the PE. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = 0x8 | Length=variable | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | PE Identifier | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Home ENRP Server Identifier | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Registration Life | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : User Transport param : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 : Member Selection Policy param : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Length: 16 bits (unsigned integer) 523 Indicates the entire length of the parameter in number of octets, 524 including the Type, Length, PE Identifier, Registration Life, User 525 Transport, and Member Selection Policy parameters. 527 Note, the value in Length field will NOT cover any padding at the end 528 of this Pool Element parameter. 530 PE Identifier: 32 bits (unsigned integer) 532 Uniquely identifies the PE in the pool. The PE picks its identifier 533 when it starts up. See Section ???? in [ASAP] for recommendations on 534 PE identifier generation. 536 Home ENRP Server Identifier: 32 bits (unsigned integer) 538 Indicates the current home ENRP server of this PE. Set to all 0's if 539 the PE's home ENRP server is undetermined. 541 Registration Life: 32 bits (signed integer) 543 Indicates the life time of the registration in number of seconds. A 544 value of -1 indicates infinite life time. 546 User Transport: 548 This can be either an SCTP, TCP, or UDP type transport parameter (see 549 Section 3.3, Section 3.4, Section 3.5). A PE MUST have one and only 550 one User Transport. 552 Member Selection Policy: 554 Contains one of the defined member selection policy parameters (see 555 Section 3.6). 557 3.9 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 = 0x9 | Length=variable | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Server ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |M| (reserved) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : Server Transport : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Length: 16 bits (unsigned integer) 576 Indicates the entire length of the parameter in number of octets. 578 Note, the value in Length field will NOT cover any padding at the end 579 of the parameter. 581 Server ID: 32 bit (unsiged integer) 583 This is the ID of the ENRP server, as defined in Section xxxxxx in 584 ENRP [5] . 586 Multicast Flag (M): 1 bit 588 If set to '1', indicates the ENRP server is allowed to use multicast 589 for communications. If set to '0', multicast is not used by the 590 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 that 599 contains the network access address(es), SCTP port number, etc. of 600 the ENRP server. 602 3.10 Operation Error Parameter 604 This parameter is used in both ENPR and ASAP for a message sender to 605 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 = 0xa | 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 octets. 621 Note, the value in Length field will NOT cover any padding at the end 622 of the parameter. 624 Error causes are defined as variable-length parameters using the 625 following format: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Cause Code | Cause Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 0 Unspecified Error 645 1 Unrecognized Parameter 646 2 Unrecognized Message 647 3 Invalid Values 648 4 Non-unique PE Identifier 649 5 Inconsistent Pooling Policy 650 6 Lack of Resources 651 7 Inconsistent Transport Type 652 8 Inconsistent Data/Control Configuration 653 other values reserved by IETF 655 Cause Length: 16 bits (unsigned integer) 657 Set to the size of the parameter in bytes, including the Cause Code, 658 Cause Length, and Cause-Specific Information fields, but not 659 including any padding at the end of this error cause TLV. 661 Cause-specific Information: variable length 663 This field carries the details of the error condition. 665 The following subsections (Section 3.10.1 - Section 3.10.9) define 666 specific error causes. 668 3.10.1 Unspecified Error 670 This error cause is used to report an unspecified error by the 671 sender. There is no cause specific information. 673 3.10.2 Unrecognized Parameter Error 675 This error cause is used to report an unrecognized parameter. The 676 unrecognized parameter TLV is included as cause specific information. 678 3.10.3 Unrecognized Message Error 680 This error cause is used to report an unrecognized message. The 681 unrecognized message TLV is included as cause specific information. 683 3.10.4 Invalid Values Error 685 This error cause is used to report one or more invalid values found 686 in a received parameter. The offending TLV that contains the invalid 687 value(s) is included as cause specific information. 689 3.10.5 Non-unique PE Identifier Error 691 This error cause is used by an ENRP server to indicate to a 692 registering PE that the PE Identifier it chooses has already been 693 used by another PE in the pool. There is no cause specific 694 information. 696 3.10.6 Inconsistent Pool Policy Error 698 This error cause is used by an ENRP server to indicate to a 699 registering PE that the Pool Policy it chooses does not match the 700 overall policy of the pool. A Pool Member Selection Policy TLV (see 701 Section Section 3.6) that indicates the overall pool policy is 702 included as cause specific information. 704 3.10.7 Lack of Resources Error 706 This error cause is used to indicate that the sender does not have 707 certain resources to perform a requested function. There is no cause 708 specific information. 710 3.10.8 Inconsistent Transport Type Error 712 This error cause is used by an ENRP server to indicate to a 713 registering PE that the User Transport it chooses does not match the 714 overall user transport of the pool. A Transport TLV that indicates 715 the overall pool user transport type is included as cause specific 716 information. 718 3.10.9 Inconsistent Data/Control Configuration Error 720 This error cause is used by an ENRP server to indicate to a 721 registering PE that the Transport Use field in the User Transport it 722 sent in its registration is inconsistent to the pool's overall data/ 723 control channel configuration. There is no cause specific 724 information. 726 3.11 Cookie Parameter 728 This parameter defines a TLV that carries a Cookie. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Type = 0xb | Length=variable | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 : : 736 : Cookie : 737 : : 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Length: 16 bits (unsigned integer) 742 Indicates the entire length of the parameter in number of bytes, 743 including the Type, Length, and Cookie. 745 Cookie: variable length 747 The Cookie is an arbitrary byte string of (Length - 4) bytes. 749 3.12 PE Identifier Parameter 751 This parameter defines a TLV that carries a PE Identifier. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Type = 0xc | Length=0x8 | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | PE Identifier | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 PE Identifier: 32 bits (unsigned integer) 763 Uniquely identifies the PE in the pool. The PE picks its identifier 764 when it starts up. See Section ???? in [ASAP] for recommendations on 765 PE identifier generation. 767 4. Common Message Formats 769 The figure below illustrates the common format for all ASAP and ENRP 770 messages. Each message is formatted with a Message Type field, a 771 message-specific Flag field, a Message Length field, and a Value 772 field. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Message Type | Msg Flags | Message Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 : : 780 : Message Value : 781 : : 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Message Type: 8 bits (unsigned integer) 786 This field identifies the type of information contained in the 787 Message Value field. It takes a value from 0 to 254. The value of 788 255 is reserved for future use as an extension field. 790 Message Types are encoded such that the highest-order two bits 791 specify the action that must be taken if the message receiver does 792 not recognize the Message Type. 794 00 Stop processing this message and discard it. 796 01 Stop processing this message and discard it, and report the 797 unrecognized message in an 'Unrecognized Message' error (see 798 Section Section 3.10.3). 800 10 reserved. 802 11 reserved. 804 Message Flags: 8 bits 806 The usage of these bits depends on the message type as given by the 807 Message Type. Unless otherwise specified, they are set to zero on 808 transmit and are ignored on receipt. 810 Message Length: 16 bits (unsigned integer) 812 This value represents the size of the message in bytes including the 813 Message Type, Message Flags, Message Length, and Message Value 814 fields. Therefore, if the Message Value field is zero-length, the 815 Length field will be set to 4. 817 Note, the value in Message Length field will NOT cover any padding at 818 the end of this message. 820 Message Value: variable length 822 The Message Value field contains the actual information to be 823 transferred in the message. The usage and format of this field is 824 dependent on the Message Type. 826 The total length of a message (including Type, Length and Value 827 fields) MUST be a multiple of 4 bytes. If the length of the message 828 is not a multiple of 4 bytes, the sender MUST pad the message with 829 all zero bytes and this padding is not included in the message length 830 field. The sender should never pad with more than 3 bytes. The 831 receiver MUST ignore the padding bytes. 833 5. Security Considerations 835 This document contains common parameter formats only. As such it 836 specifies no new security constraints on either ENRP or ASAP. Details 837 on ENRP and ASAP security constraints are addressed in ENRP [5] and 838 ASAP [4] . 840 Normative References 842 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 843 9, RFC 2026, October 1996. 845 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 846 Levels", BCP 14, RFC 2119, March 1997. 848 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 849 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 850 "Stream Control Transmission Protocol", RFC 2960, October 2000. 852 [4] Stewart, R., Xie, Q. and M. Stillman, "Aggregate Server Access 853 Protocol (ASAP)", draft-ietf-rserpool-common-param-01 (work in 854 progress), May 2002. 856 [5] Xie, Q., Stewart, R. and M. Stillman, "Endpoint Name Resolution 857 Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in 858 progress), May 2002. 860 Authors' Addresses 862 Randall R. Stewart 863 Cisco Systems, Inc. 864 8725 West Higgins Road 865 Suite 300 866 Chicago, IL 60631 867 USA 869 Phone: +1-815-477-2127 870 EMail: rrs@cisco.com 872 Qiaobing Xie 873 Motorola, Inc. 874 1501 W. Shure Drive, #2309 875 Arlington Heights, IL 60004 876 USA 878 Phone: +1-847-632-3028 879 EMail: qxie1@email.mot.com 880 Maureen Stillman 881 Nokia 882 127 W. State Street 883 Ithaca, NY 14850 884 USA 886 Phone: +1-607-273-0724 887 EMail: maureen.stillman@nokia.com 889 Michael Tuexen 890 Siemens AG 892 Germany 894 Phone: 895 EMail: tuexen@fh-muenster.de 897 Intellectual Property Statement 899 The IETF takes no position regarding the validity or scope of any 900 intellectual property or other rights that might be claimed to 901 pertain to the implementation or use of the technology described in 902 this document or the extent to which any license under such rights 903 might or might not be available; neither does it represent that it 904 has made any effort to identify any such rights. Information on the 905 IETF's procedures with respect to rights in standards-track and 906 standards-related documentation can be found in BCP-11. Copies of 907 claims of rights made available for publication and any assurances of 908 licenses to be made available, or the result of an attempt made to 909 obtain a general license or permission for the use of such 910 proprietary rights by implementors or users of this specification can 911 be obtained from the IETF Secretariat. 913 The IETF invites any interested party to bring to its attention any 914 copyrights, patents or patent applications, or other proprietary 915 rights which may cover technology that may be required to practice 916 this standard. Please address the information to the IETF Executive 917 Director. 919 Full Copyright Statement 921 Copyright (C) The Internet Society (2003). All Rights Reserved. 923 This document and translations of it may be copied and furnished to 924 others, and derivative works that comment on or otherwise explain it 925 or assist in its implementation may be prepared, copied, published 926 and distributed, in whole or in part, without restriction of any 927 kind, provided that the above copyright notice and this paragraph are 928 included on all such copies and derivative works. However, this 929 document itself may not be modified in any way, such as by removing 930 the copyright notice or references to the Internet Society or other 931 Internet organizations, except as needed for the purpose of 932 developing Internet standards in which case the procedures for 933 copyrights defined in the Internet Standards process must be 934 followed, or as required to translate it into languages other than 935 English. 937 The limited permissions granted above are perpetual and will not be 938 revoked by the Internet Society or its successors or assignees. 940 This document and the information contained herein is provided on an 941 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 942 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 943 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 944 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 945 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 Acknowledgement 949 Funding for the RFC Editor function is currently provided by the 950 Internet Society.