idnits 2.17.1 draft-ietf-rserpool-common-param-02.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.) ** The abstract seems to contain references ([4], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 635 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 (October 1, 2002) is 7878 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 697 == Unused Reference: '1' is defined on line 776, 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 (~~), 7 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: April 1, 2003 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Siemens AG 10 October 1, 2002 12 Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution 13 Protocol (ENRP) common parameters document 14 draft-ietf-rserpool-common-param-02.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 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 1, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 Aggregate Server Access Protocol (ASAP) [4] in conjunction with the 46 Endpoint Name Resolution Protocol (ENRP) [5] provides a high 47 availability data transfer mechanism over IP networks. 49 Both protocols work together and so share many common parameters used 50 in message formats. This document details the common message 51 parameters shared between the two protocols. This document provides 52 parameter formats only, for procedures and message composition please 53 refer to the respective ASAP [4] and ENRP [5] documents. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Parameters in General . . . . . . . . . . . . . . . . . . 4 60 3. ENRP-ASAP Common Parameters . . . . . . . . . . . . . . . 5 61 3.1 IPv4 Address Parameter . . . . . . . . . . . . . . . . . . 6 62 3.2 IPv6 Address Parameter . . . . . . . . . . . . . . . . . . 7 63 3.3 SCTP Transport Parameter . . . . . . . . . . . . . . . . . 7 64 3.4 TCP Transport Parameter . . . . . . . . . . . . . . . . . 8 65 3.5 UDP Transport Parameter . . . . . . . . . . . . . . . . . 9 66 3.6 Pool Member Selection Policy Parameter . . . . . . . . . . 10 67 3.6.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 11 68 3.6.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 11 69 3.6.3 Least Used with Degradation Policy . . . . . . . . . . . . 11 70 3.6.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 12 71 3.7 Pool Handle Parameter . . . . . . . . . . . . . . . . . . 12 72 3.8 Pool Element Parameter . . . . . . . . . . . . . . . . . . 12 73 3.9 Server Information Parameter . . . . . . . . . . . . . . . 14 74 3.10 Operation Error Parameter . . . . . . . . . . . . . . . . 15 75 3.10.1 Unrecognized Parameter Error . . . . . . . . . . . . . . . 16 76 3.10.2 Unrecognized Message Error . . . . . . . . . . . . . . . . 16 77 3.11 Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 16 78 3.12 PE Identifier Parameter . . . . . . . . . . . . . . . . . 17 79 4. Common Message Formats . . . . . . . . . . . . . . . . . . 18 80 5. Security Considerations . . . . . . . . . . . . . . . . . 20 81 Normative References . . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 21 83 Full Copyright Statement . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 Aggregate Server Access Protocol (ASAP) [4] in conjunction with the 88 Endpoint Name Resolution Protocol (ENRP) [5] provides a high 89 availability data transfer mechanism over IP networks. 91 Both protocols work together and so share many common parameters used 92 in message formats. This document details the common message 93 parameters shared between the two protocols. This document provides 94 parameter formats only, for procedures and message composition please 95 refer to the respective ASAP [4] and ENRP [5] documents. 97 1.1 Conventions 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 101 they appear in this document, are to be interpreted as described in 102 RFC2119 [2]. 104 2. Parameters in General 106 All parameters described below MUST be in Network Byte Order (a.k.a. 107 Big Endian, i.e., the most significant byte first) during 108 transmission. For fields with a length bigger than 4 octets, a 109 number in a pair of parentheses may follow the field name to indicate 110 the length of the field in number of octets. 112 Please note that messages in both ENRP and ASAP are often composed of 113 multiple parameters. These parameters may also be nested. In such a 114 case a nested parameter will include the length of the padding 115 between the nested parameters but not the last padding. 117 3. ENRP-ASAP Common Parameters 119 Parameters are defined in the following Type-length-value (TLV) 120 format: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Parameter Type | Parameter Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 : : 128 : Parameter Value : 129 : : 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Parameter Type: 16 bits (unsigned integer) 134 The Type field is a 16 bit identifier of the type of parameter. It 135 takes a value of 0 to 65534. 137 The value of 65535 is reserved for IETF-defined extensions. Values 138 other than those defined in specific ENRP parameter description are 139 reserved for use by IETF. 141 Parameter Length: 16 bits (unsigned integer) 143 The Parameter Length field contains the size of the parameter in 144 bytes, including the Parameter Type, Parameter Length, and Parameter 145 Value fields. Thus, a parameter with a zero-length Parameter Value 146 field would have a Length field of 4. The Parameter Length does not 147 include any padding bytes that may appear at the end of this 148 parameter. 150 Parameter Value: variable-length. 152 The Parameter Value field contains the actual information to be 153 transferred in the parameter. 155 The total length of a parameter (including Type, Parameter Length and 156 Value fields) MUST be a multiple of 4 bytes. If the length of the 157 parameter is not a multiple of 4 bytes, the sender pads the Parameter 158 at the end (i.e., after the Parameter Value field) with all zero 159 bytes. The length of this padding is not included in the parameter 160 length field. A sender SHOULD NOT pad with more than 3 bytes. The 161 receiver MUST ignore the padding bytes. 163 (Editor's note: clarify further that any padding inside in the 164 parameter, such as the padding in sub-param is included in the total 165 length) 167 The Parameter Types are encoded such that the highest-order two bits 168 specify the action that must be taken if the processing endpoint does 169 not recognize the Parameter Type. 171 00 Stop processing this ENRP or ASAP message and discard it, do not 172 process any further parameters within it. 174 01 Stop processing this ENRP or ASAP message and discard it, do not 175 process any further parameters within it, and report the 176 unrecognized parameter in an 'Unrecognized Parameter' error (see 177 Section 3.10). 179 10 Skip this parameter and continue processing. 181 11 Skip this parameter and continue processing, but report the 182 unrecognized parameter in an 'Unrecognized Parameter' error (see 183 Section 3.10). 185 The values of parameter types are defined as follows: 187 Value Parameter Type 188 ----- ---------- 189 0x0 - (reserved by IETF) 190 0x1 - IPv4 Address 191 0x2 - IPv6 Address 192 0x3 - SCTP Transport 193 0x4 - TCP Transport 194 0x5 - UDP Transport 195 0x6 - Pool Member Selection Policy 196 0x7 - Pool Handle 197 0x8 - Pool Element 198 0x9 - Server Information 199 0xa - Operation Error 200 0xb - Cookie 201 0xc - PE Identifier 203 others - (reserved by IETF) 205 3.1 IPv4 Address Parameter 207 This parameter defines a TLV that carries an IPv4 address. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type = 0x1 | Length = 0x8 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | IPv4 Address | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 IPv4 Address: 32 bits (unsigned integer) 219 Contains an IPv4 address. It is binary encoded. 221 3.2 IPv6 Address Parameter 223 This parameter defines a TLV that carries an IPv6 address. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type = 0x2 | Length = 0x14 | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | IPv6 Address | 232 | | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 IPv6 Address: 128 bit (unsigned integer) 238 Contains an IPv6 address. It is binary encoded. 240 3.3 SCTP Transport Parameter 242 This parameter defines a TLV that describes a user transport using 243 SCTP protocol. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type = 0x3 | Length = variable | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | SCTP port | (reserved) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 : IPv4 or IPv6 Address #1 : 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 : : 255 : ... : 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 : IPv4 or IPv6 Address #n : 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Length: 16 bits (unsigned integer) 262 Indicates the entire length of the parameter in number of octets, 263 including the Type, Length, SCTP port, reserved fields, and all IP 264 address parameters present. 266 SCTP port: 16 bits (unsigned integer) 268 The SCTP port number signed to this SCTP user transport. 270 IPv4 or IPv6 Address #1 - #n: 272 Each indicates an IPv4 or IPv6 address parameter (as defined above in 273 Section 3.1 and Section 3.2) assigned to this SCTP user transport. 274 At least one IP address parameter MUST be present in an SCTP 275 transport parameter. 277 3.4 TCP Transport Parameter 279 This parameter defines a TLV that describes a user transport using 280 TCP protocol. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type = 0x4 | Length = variable | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | TCP port | (reserved) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 : IPv4 or IPv6 Address : 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Length: 16 bits (unsigned integer) 293 Indicates the entire length of the parameter in number of octets, 294 including the Type, Length, TCP port, reserved fields, and IP address 295 parameter. 297 TCP port: 16 bits (unsigned integer) 299 The TCP port number signed to this TCP user transport. 301 IPv4 or IPv6 Address: 303 Indicates an IPv4 or IPv6 address parameter (as defined above in 304 Section 3.1 and Section 3.2) assigned to this TCP user transport. 305 Unlike in an SCTP transport, only one IP address parameter can be 306 present in a TCP transport parameter. 308 3.5 UDP Transport Parameter 310 This parameter defines a TLV that describes a user transport using 311 UDP protocol. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type = 0x5 | Length = variable | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | UDP port | (reserved) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 : IPv4 or IPv6 Address : 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Length: 16 bits (unsigned integer) 325 Indicates the entire length of the parameter in number of octets, 326 including the Type, Length, UDP port, reserved fields, and IP address 327 parameter. 329 UDP port: 16 bits (unsigned integer) 331 The UDP port number signed to this UDP user transport. 333 IPv4 or IPv6 Address: 335 Indicates an IPv4 or IPv6 address parameter (as defined above in 336 Section 3.1 and Section 3.2) assigned to this UDP user transport. 337 Unlike in an SCTP transport, only one IP address parameter can be 338 present in a UDP transport parameter. 340 3.6 Pool Member Selection Policy Parameter 342 This parameter defines a pool member selection policy. RSERPOOL 343 supports multiple pool member selection polices and also allows 344 definition of new selection polices in the future. 346 The enforcement rules and handling procedures of all the policies are 347 defined in Section xxxxx in ASAP [4]. 349 All pool member selection policies, both present and future, MUST use 350 the following general parameter format: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type = 0x6 | Length = variable | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Policy Type | Policy-specific Data.... 358 +-+-+-+-+-+-+-+-+------------------------------------------------ 360 Length: 16 bits (unsigned integer) 362 Indicates the entire length of the parameter in number of octets, 363 including the Type, Length, Policy Type fields, and the Policy- 364 specific Data. 366 Note, the value in Length field will NOT cover any padding at the end 367 of the parameter, if there is one. 369 Policy Type: 8 bits (unsigned integer) 371 Specifies the type of selection policy. 373 Currently defined policy types are: 375 Value Policy 376 ----- --------- 377 0x0 (reserved by IETF) 378 0x1 Round Robin 379 0x2 Least Used 380 0x3 Least Used with Degradation (a.k.a. dog pile) 381 0x4 Weighted Round Robin 382 others (reserved by IETF) 384 Policy-specific Data: 386 The structure and fields for each presently defined policy types are 387 described in detail in the following subsections. The enforcement 388 rules and handling procedures of these policies are defined in 389 Section xxxxx in ASAP [4]. 391 3.6.1 Round Robin Policy 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Param Type = 0x6 | Length = 0x8 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Policy=0x1 | (reserved) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 401 Reserved: 24 bits 403 MUST be set to 0's by sender and ignored by the receiver. 405 3.6.2 Least Used Policy 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Param Type = 0x6 | Length = 0x8 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Policy=0x2 | Load | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 415 Load: 24 bits (signed integer) 417 (TBD) 419 3.6.3 Least Used with Degradation Policy 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Param Type = 0x6 | Length = 0x8 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Policy=0x3 | Load | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 429 Load: 24 bits (signed integer) 431 (TBD) 433 3.6.4 Weighted Round Robin Policy 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Param Type = 0x6 | Length = 0x8 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Policy=0x4 | Weight | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 443 Load: 24 bits (signed integer) 445 (TBD) 447 3.7 Pool Handle Parameter 449 This parameter holds a pool handle (i.e., a pool name). 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 | Type = 0x7 | Length=variable | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 : : 457 : Pool Handle : 458 : : 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Length: 16 bits (unsigned integer) 463 Indicates the entire length of the parameter in number of octets, 464 including the Type, Length, and Pool Handle string. 466 Note, the value in Length field will NOT cover any padding at the end 467 of the parameter. 469 Pool Handle: 471 defined as a sequence of (Length - 4) bytes. 473 3.8 Pool Element Parameter 475 This parameter is used in multiple ENRP messages to represent an ASAP 476 endpoint (i.e., a PE in a pool) and the associated information, such 477 as its transport address(es), selection policy, and other operational 478 or status information of the PE. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type = 0x8 | Length=variable | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | PE Identifier | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Home ENRP Server Identifier | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Registration Life | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 : User Transport param #1 : 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 : User Transport param #2 : 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 : : 496 : ..... : 497 : : 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 : User Transport param #k : 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 : Member Selection Policy param : 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Length: 16 bits (unsigned integer) 506 Indicates the entire length of the parameter in number of octets, 507 including the Type, Length, PE Identifier, Registration Life, all 508 User Transports, and Member Selection Policy parameters. 510 Note, the value in Length field will NOT cover any padding at the end 511 of this Pool Element parameter. 513 PE Identifier: 32 bits (unsigned integer) 515 Uniquely identifies the PE in the pool. The PE picks its identifier 516 when it starts up. See Section ???? in [ASAP] for recommendations on 517 PE identifier generation. 519 Home ENRP Server Identifier: 32 bits (unsigned integer) 521 Indicates the current home ENRP server of this PE. Set to all 0's if 522 the PE's home ENRP server is undetermined. 524 Registration Life: 32 bits (signed integer) 526 Indicates the life time of the registration in number of seconds. A 527 value of -1 indicates infinite life time. 529 User Transport #1-#k: 531 Each of the User Transport parameters in a PE parameter can be either 532 an SCTP, TCP, or UDP type transport parameter (see Section 3.3, 533 Section 3.4, Section 3.5). A PE MUST have at least 1 User Transport 534 and MAY have multiple User Transports. When multiple transports are 535 present, they MAY be of mixed types (i.e., SCTP, TCP, and UDP). 537 Member Selection Policy: 539 Contains one of the defined member selection policy parameters (see 540 Section 3.6). 542 3.9 Server Information Parameter 544 This parameter is used in ENRP to pass basic information of an ENRP 545 server. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type = 0x9 | Length=variable | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Server ID | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |M| (reserved) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 : Server Transport : 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Length: 16 bits (unsigned integer) 561 Indicates the entire length of the parameter in number of octets. 563 Note, the value in Length field will NOT cover any padding at the end 564 of the parameter. 566 Server ID: 32 bit (unsiged integer) 568 This is the ID of the ENRP server, as defined in Section xxxxxx in 569 ENRP [5] . 571 Multicast Flag (M): 1 bit 573 If set to '1', indicates the ENRP server is allowed to use multicast 574 for communications. If set to '0', multicast is not used by the 575 server. 577 Reserved: 31 bits 579 MUST be set to 0's by sender and ignored by the receiver. 581 Server Transport: 583 This is an SCTP Transport Parameter, as defined in Section 3.3 that 584 contains the network access address(es), SCTP port number, etc. of 585 the ENRP server. 587 3.10 Operation Error Parameter 589 This parameter is used in both ENPR and ASAP for a message sender to 590 report an error(s) to a message receiver. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type = 0xa | Length=variable | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 : : 598 : one or more Error Causes : 599 : : 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Length: 16 bits (unsigned integer) 604 Indicates the entire length of the parameter in number of octets. 606 Note, the value in Length field will NOT cover any padding at the end 607 of the parameter. 609 Error causes are defined as variable-length parameters using the 610 format described in 3.2.1 of RFC2960 [3], i.e.: 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Cause Code | Cause Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 : : 618 : Cause-specific Information : 619 : : 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Cause Code: 16 bits (unsigned integer) 624 Defines the type of error condition being reported. 626 Cause Code 627 Value Cause Code 628 --------- ---------------- 629 1 Unrecognized Parameter 630 2 Unrecognized Message 631 3 Invalid Values 632 4 Non-unique PE Identifier 633 5 Pooling Policy Inconsistent 634 6 Lack of Resources 635 other values reserved by IETF 637 Cause Length: 16 bits (unsigned integer) 639 Set to the size of the parameter in bytes, including the Cause Code, 640 Cause Length, and Cause-Specific Information fields, but not 641 including any padding at the end of this error cause TLV. 643 Cause-specific Information: variable length 645 This field carries the details of the error condition. 647 The following subsections (Section 3.10.1 - Section 3.10.2) define 648 specific error causes. 650 3.10.1 Unrecognized Parameter Error 652 This error cause is used to report an unrecognized parameter. The 653 unrecognized parameter is included as cause specific information. 655 3.10.2 Unrecognized Message Error 657 This error cause is used to report an unrecognized message. The 658 unrecognized message is included as cause specific information. 660 3.11 Cookie Parameter 662 This parameter defines a TLV that carries a Cookie. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type = 0xb | Length=variable | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 : : 670 : Cookie : 671 : : 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Length: 16 bits (unsigned integer) 675 Indicates the entire length of the parameter in number of bytes, 676 including the Type, Length, and Cookie. 678 Cookie: variable length 680 The Cookie is an arbitrary byte string of (Length - 4) bytes. 682 3.12 PE Identifier Parameter 684 This parameter defines a TLV that carries a PE Identifier. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type = 0xc | Length=0x8 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | PE Identifier | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 PE Identifier: 32 bits (unsigned integer) 696 Uniquely identifies the PE in the pool. The PE picks its identifier 697 when it starts up. See Section ???? in [ASAP] for recommendations on 698 PE identifier generation. 700 4. Common Message Formats 702 The figure below illustrates the common format for all ASAP and ENRP 703 messages. Each message is formatted with a Message Type field, a 704 message-specific Flag field, a Message Length field, and a Value 705 field. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Message Type | Msg Flags | Message Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 : : 713 : Message Value : 714 : : 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Message Type: 8 bits (unsigned integer) 719 This field identifies the type of information contained in the 720 Message Value field. It takes a value from 0 to 254. The value of 721 255 is reserved for future use as an extension field. 723 Message Types are encoded such that the highest-order two bits 724 specify the action that must be taken if the message receiver does 725 not recognize the Message Type. 727 00 Stop processing this message and discard it. 729 01 Stop processing this message and discard it, and report the 730 unrecognized message in an 'Unrecognized Message' error (see 731 Section Section 3.10.2). 733 10 reserved. 735 11 reserved. 737 Message Flags: 8 bits 739 The usage of these bits depends on the message type as given by the 740 Message Type. Unless otherwise specified, they are set to zero on 741 transmit and are ignored on receipt. 743 Message Length: 16 bits (unsigned integer) 745 This value represents the size of the message in bytes including the 746 Message Type, Message Flags, Message Length, and Message Value 747 fields. Therefore, if the Message Value field is zero-length, the 748 Length field will be set to 4. The Message Length field does not 749 count any padding. 751 Note, the value in Message Length field will NOT cover any padding at 752 the end of this message. 754 Message Value: variable length 756 The Message Value field contains the actual information to be 757 transferred in the message. The usage and format of this field is 758 dependent on the Message Type. 760 The total length of a message (including Type, Length and Value 761 fields) MUST be a multiple of 4 bytes. If the length of the message 762 is not a multiple of 4 bytes, the sender MUST pad the message with 763 all zero bytes and this padding is not included in the message length 764 field. The sender should never pad with more than 3 bytes. The 765 receiver MUST ignore the padding bytes. 767 5. Security Considerations 769 This document contains common parameter formats only. As such it 770 specifies no new security constraints on either ENRP or ASAP. 771 Details on ENRP and ASAP security constraints are a addressed in ENRP 772 [5] and ASAP [4] . 774 Normative References 776 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 777 9, RFC 2026, October 1996. 779 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 780 Levels", BCP 14, RFC 2119, March 1997. 782 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 783 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 784 "Stream Control Transmission Protocol", RFC 2960, October 2000. 786 [4] Stewart, R., Xie, Q. and M. Stillman, "Aggregate Server Access 787 Protocol (ASAP)", draft-ietf-rserpool-common-param-01 (work in 788 progress), May 2002. 790 [5] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution 791 Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in 792 progress), May 2002. 794 Authors' Addresses 796 Randall R. Stewart 797 Cisco Systems, Inc. 798 8725 West Higgins Road 799 Suite 300 800 Chicago, IL 60631 801 USA 803 Phone: +1-815-477-2127 804 EMail: rrs@cisco.com 806 Qiaobing Xie 807 Motorola, Inc. 808 1501 W. Shure Drive, #2309 809 Arlington Heights, IL 60004 810 USA 812 Phone: +1-847-632-3028 813 EMail: qxie1@email.mot.com 814 Maureen Stillman 815 Nokia 816 127 W. State Street 817 Ithaca, NY 14850 818 USA 820 Phone: +1-607-273-0724 821 EMail: maureen.stillman@nokia.com 823 Michael Tuexen 824 Siemens AG 825 ICN WN CC SE 7 826 D-81359 Munich 827 Germany 829 Phone: +49 89 722 47210 830 EMail: Michael.Tuexen@siemens.com 832 Full Copyright Statement 834 Copyright (C) The Internet Society (2002). All Rights Reserved. 836 This document and translations of it may be copied and furnished to 837 others, and derivative works that comment on or otherwise explain it 838 or assist in its implementation may be prepared, copied, published 839 and distributed, in whole or in part, without restriction of any 840 kind, provided that the above copyright notice and this paragraph are 841 included on all such copies and derivative works. However, this 842 document itself may not be modified in any way, such as by removing 843 the copyright notice or references to the Internet Society or other 844 Internet organizations, except as needed for the purpose of 845 developing Internet standards in which case the procedures for 846 copyrights defined in the Internet Standards process must be 847 followed, or as required to translate it into languages other than 848 English. 850 The limited permissions granted above are perpetual and will not be 851 revoked by the Internet Society or its successors or assigns. 853 This document and the information contained herein is provided on an 854 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 855 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 856 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 857 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 858 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Acknowledgement 862 Funding for the RFC Editor function is currently provided by the 863 Internet Society.