idnits 2.17.1 draft-ietf-rserpool-asap-07.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 are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([4], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When a ASAP endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP endpoint of the sender will select the receiver for each outbound message by round-Robining through all the registered PEs in that Pool, in an attempt to achieve an even distribution of outbound messages. Note that in a large server pool, the ENRP server MAY NOT send back all PEs to the ASAP client. In this case the client or PU will be performing a round robin policy on a subset of the entire Pool. -- 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 15, 2003) is 7652 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: 'TBD' on line 1199 == Unused Reference: '1' is defined on line 1569, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '4') (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. '5') == 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. '6') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-sctp is -05, but you're referring to -06. ** Obsolete normative reference: RFC 1750 (ref. '9') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 13, 2003 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 May 15, 2003 11 Aggregate Server Access Protocol (ASAP) 12 draft-ietf-rserpool-asap-07.txt 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. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 13, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 Aggregate Server Access Protocol (ASAP) in conjunction with the 43 Endpoint Name Resolution Protocol (ENRP) [6] provides a high 44 availability data transfer mechanism over IP networks. ASAP uses a 45 name-based addressing model which isolates a logical communication 46 endpoint from its IP address(es), thus effectively eliminating the 47 binding between the communication endpoint and its physical IP 48 address(es) which normally constitutes a single point of failure. 50 In addition, ASAP defines each logical communication destination as a 51 pool, providing full transparent support for server-pooling and load 52 sharing. It also allows dynamic system scalability - members of a 53 server pool can be added or removed at any time without interrupting 54 the service. 56 ASAP is designed to take full advantage of the network level 57 redundancy provided by the Stream Transmission Control Protocol 58 (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool 59 Elements (PE) and Pool Users (PU) MUST have an accompanying 60 transports mapping document. Note that ASAP messages passed between 61 PE's and ENRP servers MUST use SCTP. 63 The high availability server pooling is gained by combining two 64 protocols, namely ASAP and ENRP, in which ASAP provides the user 65 interface for name to address translation, load sharing management, 66 and fault management while ENRP defines the high availability name 67 translation service. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2 Organization of this document . . . . . . . . . . . . . . 7 74 1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 75 1.3.1 Extent of the Namespace . . . . . . . . . . . . . . . . . 7 76 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 77 2. Message Definitions . . . . . . . . . . . . . . . . . . . 8 78 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 79 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 80 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9 81 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9 82 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10 83 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10 84 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11 85 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11 86 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12 87 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 13 88 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13 89 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 14 90 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14 91 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14 92 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 15 93 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15 94 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 95 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 96 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 97 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 98 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 99 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 100 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 101 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 102 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22 103 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22 104 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 105 3.9 Business Card handling procedures . . . . . . . . . . . . 23 106 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 24 107 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 24 108 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 24 109 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 25 110 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 25 111 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 25 112 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 26 113 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 27 114 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 28 115 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 29 116 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 29 117 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 31 118 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 31 119 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 120 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 32 121 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 33 122 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 33 123 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 34 124 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 34 125 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 35 126 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 35 127 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 35 128 6. Security Considerations . . . . . . . . . . . . . . . . . 36 129 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37 130 Normative References . . . . . . . . . . . . . . . . . . . 38 131 Informational References (non-normative) . . . . . . . . . 39 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 133 Intellectual Property and Copyright Statements . . . . . . 40 135 1. Introduction 137 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] 138 provides a high availability data transfer mechanism over IP 139 networks. ASAP uses a name-based addressing model which isolates a 140 logical communication endpoint from its IP address(es), thus 141 effectively eliminating the binding between the communication 142 endpoint and its physical IP address(es) which normally constitutes a 143 single point of failure. 145 When multiple receiver instances exist under the same name, a.k.a, a 146 server pool, ASAP will select one Pool Element (PE), based on the 147 current load sharing policy indicated by the server pool, and deliver 148 the message to the selected PE. 150 While delivering the message, ASAP monitors the reachability of the 151 selected PE. If it is found unreachable, before notifying the sender 152 of the failure, ASAP can automatically select another PE (if one 153 exists) under that pool and attempt to deliver the message to that 154 PE. In other words, ASAP is capable of transparent fail-over amongst 155 instances of a server pool. 157 ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a 158 high availability name space. ASAP is responsible for the 159 abstraction of the underlying transport technologies, load 160 distribution management, fault management, as well as the 161 presentation to the upper layer (i.e., the ASAP user) a unified 162 primitive interface. 164 When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP 165 can seamlessly incorporate the link-layer redundancy provided by the 166 SCTP. 168 This document defines the ASAP portion of the high availability 169 server pool. ASAP depends on the services of a high availability name 170 space a.k.a. ENRP [6]. 172 1.1 Definitions 174 This document uses the following terms: 176 ASAP User: Either a PE or PU that uses ASAP. 178 Operation scope: The part of the network visible to Pool Users by a 179 specific instance of the reliable server pooling protocols. 181 Server pool (or Pool): A collection of servers providing the same 182 application functionality. 184 Pool handle (or pool name): A logical pointer to a pool. Each server 185 pool will be identifiable in the operation scope of the system by 186 a unique pool handle or "name". 188 Pool Element (PE): A server entity having registered to a pool. 190 Pool User (PU): A server Pool User. 192 Pool Element handle (PE handle): A logical pointer to a particular 193 Pool Element in a pool, 195 ENRP server: A server program running on a host that manages the name 196 space collectively with its peer ENRP servers and replies to the 197 service requests from any Pool User or Pool Element. 199 Home ENRP server: The ENRP server to which a Pool Element currently 200 uses. A PU or PE normally chooses the ENRP server on their local 201 host as the home ENRP server (if one exists). A PU or PE should 202 only have one home ENRP server at any given time. Having a "home" 203 ENRP server helps provide a mechanism to minimize the number of 204 associations a given PE will have. 206 ENRP client channel: The communication channel through which an ASAP 207 User (either a PE or PU) requests ENRP namespace service. The 208 client channel is usually defined by the transport address of the 209 home server and a well known port number. The channel MAY make use 210 of multi-cast or a named list of ENRP servers. 212 ENRP server channel: Defined by a well known multicast IP address and 213 a well known port number, OR a well known list of transport 214 addresses for a group of ENRP servers spanning an operational 215 scope. All ENRP servers in an operation scope can communicate with 216 one another through this channel via either multicast OR direct 217 point to point SCTP associations. 219 ENRP name domain: Defined by the combination of the ENRP client 220 channel and the ENRP server channel in the operation scope. 222 Network Byte Order: Most significant byte first, a.k.a Big Endian. 224 Transport address: A Transport Address is traditionally defined by 225 Network Layer address, Transport Layer protocol and Transport 226 Layer port number. In the case of SCTP running over IP, a 227 transport address is defined by the combination of an IP address 228 and an SCTP port number (where SCTP is the Transport protocol). 230 1.2 Organization of this document 232 Section 2 details ASAP message formats. In Section 3 we give the 233 detailed ASAP procedures for the ASAP implementer. And in Section 4 234 we give the details of the ASAP interface, focusing on the 235 communication primitives between the applications above ASAP and ASAP 236 itself, and the communications primitives between ASAP and SCTP (or 237 other transport layer). Also included in this discussion is relevant 238 timers and configurable parameters as appropriate. Section 5 provides 239 threshold and protocol variables. 241 1.3 Scope of ASAP 243 The requirements for high availability and scalability do not imply 244 requirements on shared state and data. ASAP does not provide 245 transaction failover. If a host or application fails during 246 processing of a transaction this transaction may be lost. Some 247 services may provide a way to handle the failure, but this is not 248 guaranteed. ASAP MAY provide hooks to assist an application in 249 building a mechanism to share state but ASAP in itself will NOT share 250 any state. 252 1.3.1 Extent of the Namespace 254 The scope of the ASAP/ENRP is NOT Internet wide. The namespace is 255 neither hierarchical nor arbitrarily large like DNS. We propose a 256 flat peer-to-peer model. Pools of servers will exist in different 257 administrative domains. For example, suppose we want to use ASAP/ 258 ENRP. First, the PU may use DNS to contact an ENRP server. Suppose a 259 PU in North America wishes to contact the server pool in Japan 260 instead of North America. The PU would use DNS to get the list of IP 261 addresses of the Japanese server pool domain, that is, the ENRP 262 client channel in Japan. From there the PU would query the ENRP 263 server and then directly contact the PE(s) of interest. 265 1.4 Conventions 267 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 268 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 269 they appear in this document, are to be interpreted as described in 270 RFC2119 [2]. 272 2. Message Definitions 274 All messages as well as their fields described below shall be in 275 Network Byte Order during transmission. For fields with a length 276 bigger than 4 octets, a number in a pair of parentheses may follow 277 the field name to indicate the length of the field in number of 278 octets. 280 2.1 ASAP Parameter Formats 282 The basic message format and all parameter formats can be found in 283 ENRP-ASAP [5]. Note also that ALL ASAP messages exchanged between an 284 ENRP server and a PE MUST use SCTP as transport, while ASAP messages 285 exchanged between an ENRP server and a PU MUST use either SCTP or TCP 286 as transport. PE to PU data traffic MAY use any transport protocol 287 specified by the PE during registration. 289 2.2 ASAP Messages 291 This section details the individual messages used by ASAP. These 292 messages are composed of a standard message format found in Section 4 293 of ENRP-ASAP [5]. The parameter descriptions may also be found in 294 Section 3 of ENRP-ASAP [5]. 296 The following ASAP message types are defined in this section: 298 Type Message Name 299 ----- ------------------------- 300 0x00 - (reserved by IETF) 301 0x01 - Registration 302 0x02 - Deregistration 303 0x03 - Registration Response 304 0x04 - Deregistration Response 305 0x05 - Name Resolution 306 0x06 - Name Resolution Response 307 0x07 - Endpoint Keep Alive 308 0x08 - Endpoint Keep Alive Acknowledgement 309 0x09 - Endpoint Unreachable 310 0x0a - Server Announce 311 0x0b - Cookie 312 0x0c - Cookie-Echo 313 0x0d - Business Card 314 0x0e - Peer Error 316 2.2.1 REGISTRATION message 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 : Pool Handle Parameter : 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 : Pool Element Parameter : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 The pool handle parameter field specifies the name to be registered. 329 The PE Parameter field MUST be filled in by the registrant endpoint 330 to declare its transport address, server pooling policy and value, 331 and other operation preferences. Note that the registration message 332 MUST use SCTP and the IP address(es) of the PE registered within the 333 Pool Element Parameter MUST be a subset of the addresses of the SCTP 334 association in respective of the transport protocol registered by the 335 PE. 337 2.2.2 DEREGISTRATION message 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 = 0x2 |0|0|0|0|0|0|0|0| Message Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 : Pool Handle Parameter : 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 : PE Identifier Parameter : 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 349 The PE sending the DEREGISTRATION shall fill in the pool handle and 350 the PE identifier parameter in order to allow the ENRP server to 351 verify the identity of the endpoint. Note that deregistration is NOT 352 allowed by proxy, in other words a PE may only deregister itself. 354 2.2.3 REGISTRATION_RESPONSE message 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type = 0x3 |0|0|0|0|0|0|0|R| Message Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 : Pool Handle Parameter : 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 : PE Identifier Parameter : 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 : Operational Error (optional) : 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 R (Reject) flag 370 When set to '1', indicate that the ENRP server that sent this message 371 has rejected the registration. Otherwise, the registration is 372 granted. 374 Operational Error 376 This optional TLV parameter is included if an error or some atypical 377 events occurred during the registration process. When the 'R' flag is 378 set to '1', this TLV, if present, indicates the cause of the 379 rejection. When the 'R' flag is set to '0', this TLV, if present, 380 serves as a warning to the registering PE, informing it that some of 381 its registration values may have been modified or overruled by the 382 ENRP server (e.g., the selection policy type overruled). If the 383 registration was successful and there is no warning this parameter is 384 not included. 386 2.2.4 DEREGISTRATION_RESPONSE message 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 : Pool Handle Parameter : 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 : PE Identifier Parameter : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 : Operational Error (optional) : 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Operational Error 401 This optional TLV parameter is included if an error occurred during 402 the deregistration process. If the deregistration was successful this 403 parameter is not included. 405 2.2.5 NAME_RESOLUTION message 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 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 : Pool Handle Parameter : 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 This message is sent to a ENRP server to request translation of the 416 Pool Handle to a list of Pool Elements. If sent from a PE the SCTP 417 association used for registration SHOULD be used. 419 2.2.6 NAME_RESOLUTION_RESPONSE message 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 | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 : Pool Handle Parameter : 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 : Overall PE Selection Policy (optional) : 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 : Pool Element Parameter 1 (optional) : 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 : ... : 433 : : 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 : Pool Element Parameter N (optional) : 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 : Operational Error (optional) : 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Overall PE Selection Policy: 442 This TLV is a PE selection policy parameter and can be present when 443 the response is positive. It indicates the overall selection policy 444 of the pool. If not present, round-robin is assumed. This TLV is not 445 present when the response is negative (i.e., a rejection). 447 Note, any load policy parameter inside the Pool Element Parameter (if 448 present) MUST be ignored, and MUST NOT be used to determine the 449 overall pool policy. 451 Pool Element Parameters 453 When the response is positive, an array of PE TLVs are included, 454 indicating the current PEs and their information in the named pool. 455 In a positive response, at least one PE TLV MUST be present. When the 456 response is negative, no PE TLVs are included. 458 Operational Error 460 The presence of this TLV indicates that the response is negative 461 (i.e., the name resolution request was rejected by the ENRP server). 462 The cause code in this TLV (if present) will indicate the reason the 463 name resolution request was rejected (e.g., the requested pool handle 464 was not found). 466 2.2.7 ENDPOINT_KEEP_ALIVE message 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 = 0x7 |0|0|0|0|0|0|0|0| Message Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 : Pool Handle Parameter : 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 This message is sent to a PE by the ENRP server has a "health" check. 477 If the transport level Heart Beat mechanism is insufficient (usually 478 this means that time outs are set for too long or heartbeats are not 479 frequent enough), this adds heartbeat messages with the goal of 480 determining health status in a more timely fashion. 482 Using ASAP keepalive also has additional value to the reliability of 483 fault detection when SCTP stack is in the kernel. In such a case, 484 while SCTP level heartbeat monitors the end-to-end connectivity 485 between the two SCTP stacks, ASAP keepalive monitors the end-to-end 486 liveliness of the ASAP layer above it. 488 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 : Pool Handle Parameter : 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 : PE Identifier Parameter : 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 This message is sent by the PE to the ENRP server has an 501 acknowledgment to the ENDPOINT_KEEP_ALIVE message. 503 2.2.9 ENDPOINT_UNREACHABLE message 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 = 0x09 |0|0|0|0|0|0|0|0| Message Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 : Pool Handle Parameter : 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 : PE Identifier Parameter : 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 A PE or PU will send this message to an ENRP server to report the 516 unreachability of the specified PE. 518 2.2.10 SERVER_ANNOUNCE message 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 : Transport param #1 : 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 : Transport param #2 : 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 : : 530 : ..... : 531 : : 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 : Transport param #n : 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 This message is sent by an ENRP server such that PUs and PEs know the 537 transport layer information necessary to connect to the ENRP server. 538 The transport parameters are optional and only TCP and SCTP transport 539 parameters are allowed. 541 2.2.11 COOKIE message 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 : Cookie Parameter : 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 This message is sent by a PE to a PU. It may only be sent when a 552 control channel exists between the PE and PU. 554 2.2.12 COOKIE_ECHO message 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 : Cookie Parameter : 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 This message is sent by a PU to a PE in case of a failover. The 565 Cookie Parameter is one received latest from the failed PE. 567 2.2.13 BUSINESS_CARD message 569 This message is sent by a PU to a PE or from a PE to a PU. This 570 parameter MUST NOT be sent if a control channel does NOT exists 571 between the PE and PU. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Type = 0xd |0|0|0|0|0|0|0|0| Message Length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 : Pool Handle Parameter : 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 : Pool Element Parameter-1 : 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 : .. : 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 : Pool Element Parameter-N : 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 The sender of this message lists both the Pool that the sender 588 belongs to and a preferred list of failover candidates. 590 2.2.14 PEER_ERROR message 592 This message is used to report an operation error. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type = 0xe |0|0|0|0|0|0|0|0| Message Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 : Operation Error Parameter : 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 3. Procedures 604 This section will focus on the methods and procedures used by an 605 internal ASAP endpoint. Appropriate timers and recovery actions for 606 failure detection and management are also discussed. 608 3.1 Registration 610 When a PE wishes to join its server pool it MUST use the procedures 611 outlined in this section to register. Often the registration will be 612 triggered by a user request primitive (discussed in Section 4.1). The 613 ASAP endpoint MUST register using an SCTP association between the 614 ASAP endpoint and the ENRP server. If the ASAP endpoint has not 615 established its Home ENRP server it MUST follow the procedures 616 specified in Section 3.6 to establish its Home ENRP server. 618 Once the ASAP endpoint has established its Home ENRP server the 619 following procedures MUST be followed to register: 621 R1) The SCTP endpoint used to communicate with the ENRP server MUST 622 be bound to all IP addresses that will be used by the PE 623 (irregardless of what protocol will be used to service user 624 requests to the PE). 626 R2) The ASAP endpoint MUST formulate a Registration message as 627 defined in Section 2.2.1 In formulating the message the ASAP 628 endpoint MUST: 630 R2.1) Fill in the Pool Handle to specify which server pool the 631 ASAP endpoint wishes to join. 633 R2.2) Fill in a PE identifier using a good quality randomly 634 generated number (RFC1750 [9] provides some information on 635 randomness guidelines). 637 R2.3) Fill in the registration life time parameter with the number 638 of seconds that this registration is good for. Note a PE that 639 wishes to continue service MUST re-register after the 640 registration expires. 642 R2.4) Fill in a User Transport Parameter for the type of transport 643 and the data/control channel usage the PE is willing to 644 support. Note, to join an existing server pool, the PE MUST 645 follow the overall transport type and overall data/control 646 channel usage of the pool. Otherwise, the registration may be 647 rejected by the ENRP server. 649 R2.5) Fill in the preferred Member selection policy. 651 R3) Send the Registration request to the Home ENRP server using SCTP. 653 R4) Start a T2-registration timer. 655 If the T2-registration timer expires before receiving a 656 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 657 received from the SCTP layer, the ASAP endpoint shall start the 658 Server Hunt procedure (see Section 3.6) in an attempt to get service 659 from a different ENRP server. After establishing a new Home ENRP 660 server the ASAP endpoint SHOULD restart the registration procedure. 662 At the reception of the registration response, the ASAP endpoint MUST 663 stop the T2-Registration timer. If the response indicated success, 664 then the PE is now registered and will be considered an available 665 member of the server pool. If the registration response indicates a 666 failure, the ASAP endpoint must either re-attempt registration after 667 correcting the error or return a failure indication to the ASAP 668 endpoints upper layer. The ASAP endpoint MUST NOT re-attempt 669 registration without correcting the error condition. 671 The registration response may also indicate that the registration is 672 accepted with a warning, often indicating that the ENRP server might 673 have made modifications to the value of some registration attribute 674 or attributes (such as policy type, transport usage, etc.). When this 675 happens, the PE SHOULD immediately notify its upper layer about the 676 registration modifications. This gives the upper layer a chance, for 677 example, to withdraw itself from the pool if such modifications are 678 unacceptable for its operation. 680 At any time a registered PE MAY wish to re-register to either update 681 its member selection policy value or registration expiration time. 682 When re-registering the PE MUST use the same PE identifier. 684 After successful registration the PE MUST start a T4-reregistration 685 timer. At its expiration a re-registration SHOULD be made starting at 686 step R1 including (at completion) restarting the T4-reregistration 687 timer. 689 Note that an implementation SHOULD keep a record of the number of 690 registration attempts it makes in a local variable. If repeated 691 registration time-outs or failures occurs and the local count exceeds 692 the Threshold 'max-reg-attempt' the implementation SHOULD report the 693 error to its upper layer and stop attempting registration. 695 3.2 Deregistration 696 In the event the PE wishes to deregister from its server pool 697 (normally via an upper layer requests see Section 4.2) it SHOULD use 698 the following procedures. Note that an alternate method of 699 deregistration is to NOT re-register and to allow the registration 700 lift time to expire. 702 When deregistering the PE SHOULD use the same SCTP association with 703 its Home ENRP server that was used for registration. To deregister 704 the ASAP endpoint MUST take the following actions: 706 D1) Fill in the Pool Handle parameter of the Deregistration message ( 707 Section 2.2.2) using the same Pool Handle parameter sent during 708 registration. 710 D2) Fill in the PE Identifier. The identifier MUST be the same one 711 used during registration. 713 D3) Send the deregistration message to the Home ENRP server using the 714 SCTP association. 716 D4) Start a T3-Deregistration timer. 718 If the T3-Deregistration timer expires before receiving a 719 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 720 received from the SCTP layer, the ASAP endpoint shall start the 721 Server Hunt procedure (see Section 3.6) in an attempt to get service 722 from a different ENRP server. After establishing a new Home ENRP 723 server the ASAP endpoint SHOULD restart the deregistration procedure. 725 At the reception of the deregistration response, the ASAP endpoint 726 MUST stop the T3-deregistration timer. 728 Note that after a successful deregistration the PE MAY still receive 729 requests for some period of time. The PE MAY wish to still remain 730 active and service these requests or may wish to ignore these 731 requests and exit. 733 3.3 Name resolution 735 At any time a PE or PU may wish to resolve a name. This usually will 736 occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or 737 requests a cache population (Section 4.3) but may occur for other 738 reasons (e.g. the internal ASAP PE wishes to know its peers for 739 sending a message to all of them). When an Endpoint (PE or PU) wishes 740 to resolve a name it MUST take the following actions: 742 NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool 743 Handle to be resolved. 745 NR2) If the endpoint does not have a Home ENRP server start the ENRP 746 Server Hunt procedures specified in Section 3.6 to obtain one. 747 Otherwise proceed to step NR3. 749 NR3) Send the NAME_RESOLUTION message to the Home ENRP server using 750 SCTP. 752 NR4) Start a T1-ENRPrequest timer. 754 If the T1-ENRPrequest timer expires before receiving a response 755 message, or a SEND.FAILURE notification is received from the SCTP 756 layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see 757 Section 3.6) in an attempt to get service from a different ENRP 758 server. After establishing a new Home ENRP server the ASAP endpoint 759 SHOULD restart the name resolution procedure. 761 At the reception of the response message (i.e., a 762 NAME_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-ENRPrequest 763 timer. After stopping the T1 timer the endpoint SHOULD process the 764 name response as appropriate (e.g. populate a local cache, give the 765 response to the ASAP user, and/or use the response to send the ASAP 766 users message). 768 Note that some ASAP endpoints MAY use a cache to minimize the number 769 of name resolutions made. If such a cache is used it SHOULD: 771 C1) Be consulted before requesting a name resolution. 773 C2) Have a stale timeout time associated with the cache so that even 774 in the event of a cache-hit, if the cache is "stale" it will cause 775 a new name_resolution to be issued to update the cache. 777 C3) In the case of a "stale" cache the implementation may in parallel 778 request an update and answer the request or block the user and 779 wait for an updated cache before proceeding with the users 780 request. 782 C4) If the cache is NOT stale, the endpoint SHOULD NOT make a 783 name_resolution request but instead use the entry from the cache. 785 3.4 Endpoint keep alive 787 Periodically an ENRP server may choose to "audit" a PE. It does this 788 by sending a ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). Upon 789 reception of an ENDPOINT_KEEP_ALIVE message the following actions 790 MUST be taken: 792 KA1) The PE must verify that the Pool Handle is correct and matches 793 the Pool Handle sent in its earlier Registration. If the Pool 794 Handle does not match silently discard the message. 796 KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: 798 KA2.1) Filling in the Pool Handle Parameter with the PE's Pool 799 Handle. 801 KA2.2) Fill in the PE Identifier that was used with this PE for 802 registration. 804 KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the 805 appropriate SCTP association for that ENRP server. 807 KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the 808 new home ENRP server. 810 3.5 Reporting unreachable endpoints 812 Occasionally an ASAP endpoint may realize that a PE is unreachable. 813 This may occur by a specific SCTP error realized by the ASAP endpoint 814 or via a ASAP user report via the Transport.Failure Primitive 815 (Section 4.9.2). In either case the ASAP endpoint SHOULD report the 816 unavailability of the PE by sending a ENDPOINT_UNREACHABLE message to 817 its home ENRP server. The Endpoint should fill in the Pool Handle and 818 PE identifier of the unreachable endpoint. If the sender is a PE the 819 message MUST be sent via SCTP to the Endpoints Home ENRP server. 821 Note: when processing a Transport.Failure Primitive (Section 4.9.2) 822 the ASAP endpoint MUST NOT send a unreachable report unless the ASAP 823 endpoint as sent at least one message to the PE specified by the 824 primitive. 826 3.6 ENRP server hunt procedures 828 Each PU and PE manages a list of transport addresses of ENRP servers. 830 If the multicast capabilities are used an ENRP server MUST send 831 periodically every T6-Serverannounce a SERVER_ANNOUNE message 832 (Section 2.2.10) including all the transport addresses available for 833 ASAP communication to the multicast channel. 835 If a SERVER_ANNOUNCE message is received by a PU or PE it SHOULD 836 insert all new included transport address in its list of ENRP server 837 addresses and start a T7-ENRPoutdate timer for each address. For all 838 already known addresses the T7-ENRPoutdate timers MUST be restarted. 839 If no transport parameters are included in the SERVER_ANNOUNCE 840 message the source IP address and the IANA registered ASAP port 841 number are used instead. It is also assumed that the transport 842 protocol used is SCTP. If a T7-ENRP timer for a transport address 843 expires the corresponding address is deleted from the list of 844 transport addresses. 846 If no multicast capabilities are used each PU and PE MUST have a 847 configured list of transport addresses of ENRP servers. 849 At its startup, or when it fails to send to (i.e., timed-out on a 850 service request) with its current home ENRP server, a PE or PU shall 851 establish its Home ENRP server, i.e. setup a TCP connection or SCTP 852 association with an ENRP server. 854 To establish a new association or connection the following rules MUST 855 be followed: 857 SH1) The PE or PU SHOULD try to establish an association or 858 connection with no more than three ENRP server addresses. An 859 endpoint MUST NOT try to establish more than three association or 860 connections at any single time. 862 SH2) The endpoint shall start a T5-Serverhunt timer. 864 SH3) If the endpoint establishes an association or connection it MUST 865 stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the 866 T5-Serverhunt value to its initial value and then proceed to step 867 SH6. 869 SH4) If an association or connection establishment fails the endpoint 870 SHOULD try to establish an association or connection by using a 871 different transport address. 873 SH5) If the T5-Serverhunt timer expires the following should be 874 performed: 876 SH5.1) The endpoint MUST double the value of the T5-Serverhunt 877 timer. 879 SH5.2) The endpoint SHOULD stop the establishment of associations 880 and connections. 882 SH5.2) The endpoint SHOULD repeat trying to establish an 883 association or connection by proceeding to step SH1. It SHOULD 884 attempt to select a different set of transport addresses to 885 connect to. 887 SH6) The PE or PU shall pick one of the ENRP servers that it was able 888 to establish an association or connection with, and send all its 889 subsequent the namespace service requests to this new home ENRP 890 server. 892 3.7 Handle ASAP to ENRP Communication Failures 894 Three types of failure may occur when the ASAP endpoint at an 895 endpoint tries to communicate with the ENRP server: 897 A) SCTP send failure 899 B) T1-ENRPrequest timer expiration 901 C) Registration failure 903 Registration failure is discussed in Section 3.1 905 3.7.1 SCTP Send Failure 907 This indicates that the SCTP layer failed to deliver a message sent 908 to the ENRP server. In other words, the ENRP server is currently 909 unreachable. 911 In such a case, the ASAP endpoint should not re-send the failed 912 message. Instead, it should discard the failed message and start the 913 ENRP server hunt procedure as described in Section 3.6 915 3.7.2 T1-ENRPrequest Timer Expiration 917 When a T1-ENRPrequest timer expires, the ASAP should re-send the 918 original request to the ENRP server and re-start the T1-ENRPrequest 919 timer. In parallel, a SERVER_HUNT message should be issued per 920 Section 3.6 922 This should be repeated up to 'max-request-retransmit' times. After 923 that, an Error.Report notification should be generated to inform the 924 ASAP user and the ENRP request message associated with the timer 925 should be discarded. Note that if an alternate ENRP server responds 926 the ASAP endpoint SHOULD adopt the responding ENRP server as its new 927 "home" server and resend the request to the new "home" server. 929 3.8 Cookie handling procedures 931 Whenever a PE wants and a control channel exists it can send a Cookie 932 Message to the PU via the control channel. The ASAP layer at the PU 933 stores the Cookie parameter and discards an older one if it is 934 present. 936 If the ASAP layer detects a failure and initiates a failover to a 937 different PE, the ASAP layer sends the last received Cookie parameter 938 in a Cookie Echo message to the new PE. The upper layer may be 939 involved in the failover procedure. 941 This cookie mechanism can be used as a simple method for state 942 sharing. Therefore a cookie should be signed by the sending PE and 943 this should be verified by the receiving PE. The details of this are 944 out of scope of this document. It is only important that the PU 945 stores always the last received Cookie Parameter and sends that back 946 unmodified in case of a PE failure. 948 3.9 Business Card handling procedures 950 When communication begins between a PU and a PE (i.e. the first 951 message is sent from the PU to the PE) the ASAP layer in the PU 952 SHOULD send a Business card IF the sender is also registered as a PE. 953 A PE may also send back to a PU a business card as well. A Business 954 card MUST NOT be sent if a control channel does NOT exist between the 955 PU and PE. After communication as been established between a PE and 956 PU at any time either entity may update its failover distribution by 957 sending a new Business Card. 959 The business card serves two purposes (for both endpoints PU and PE). 960 First it lists the endpoints pool handle. For a PU contacting a PE 961 this is essential so that the PE may also gain the full benefits of 962 ASAP if the PU is also a PE. Secondly the business card tells the 963 receiver a failover order that is recommended to follow. This may 964 facilitate rendezvous between PE's as well as some control of load 965 redistribution upon the failure of any given PE. 967 Upon receipt of a Business Card Message (see Section 2.2.13) the 968 receiver SHOULD: 970 BC1) Unpack the business card, and if no entry exists in the 971 translation cache and one exists, populate the new Pool Handle 972 into the cache and request a NAME.RESOLUTION of the pool handle. 974 BC2) Create a list for this PE of preferred failover order so that in 975 the event of a failure the preferred list will be used to guide 976 the ASAP endpoint in the selection of an alternate PE. 978 4. The ASAP Interfaces 980 This chapter will focus primarily on the primitives and notifications 981 that form the interface between the ASAP-user and ASAP and that 982 between ASAP and its lower layer transport protocol (e.g., SCTP). 984 Note, the following primitive and notification descriptions are shown 985 for illustrative purposes. We believe that including these 986 descriptions in this document is important to the understanding of 987 the operation of many aspects of ASAP. But an ASAP implementation is 988 not required to use the exact syntax described in this section. 990 An ASAP User passes primitives to the ASAP sub-layer to request 991 certain actions. Upon the completion of those actions or upon the 992 detection of certain events, the ASAP will notify the ASAP user. 994 4.1 Registration.Request Primitive 996 Format: registration.request(poolHandle, 997 User Transport parameter(s)) 999 The poolHandle parameter contains a NULL terminated ASCII string of 1000 fixed length. The optional User Transport parameter(s) indicate 1001 specific transport parameters and types to register with. If this 1002 optional parameter is left off, then the SCTP endpoint used to 1003 communicate with the ENRP server is used as the default User 1004 Transport parameter. Note that any IP address contained within a User 1005 Transport parameter MUST be a bound IP address in the SCTP endpoint 1006 used to communicate with the ENRP server. 1008 The ASAP user invokes this primitive to add itself to the namespace, 1009 thus becoming a Pool Element of a pool. The ASAP user must register 1010 itself with the ENRP server by using this primitive before other ASAP 1011 users using the namespace can send message(s) to this ASAP user by 1012 Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3). 1014 In response to the registration primitive, the ASAP endpoint will 1015 send a REGISTRATION message to the home ENRP server (See Section 1016 2.2.1 and Section 3.1), and start a T2-registration timer. 1018 4.2 Deregistration.Request Primitive 1020 Format: deregistration.request(poolHandle) 1022 The ASAP PE invokes this primitive to remove itself from the Server 1023 Pool. This should be used as a part of the graceful shutdown process 1024 by the application. 1026 A DEREGISTRATION message will be sent by ASAP endpoint to the home 1027 ENRP server (see Section 2.2.2 and Section 3.2). 1029 4.3 Cache.Populate.Request Primitive 1031 Format: cache.populate.request([Pool-Handle | 1032 Pool-Element-Handle]) 1034 If the address type is a Pool handle and a local name translation 1035 cache exists, the ASAP endpoint should initiate a mapping information 1036 query by sending a NAME.RESOLUTION message on the Pool handle and 1037 update it local cache when the response comes back from the ENRP 1038 server. 1040 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 1041 from the Pool-Element-Handle and the NAME.RESOLUTION message is sent 1042 to the ENRP server for resolution. When the response message returns 1043 from the ENRP server the local cache is updated. 1045 Note that if the ASAP service does NOT support a local cache this 1046 primitive performs NO action. 1048 4.4 Cache.Purge.Request Primitive 1050 Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) 1052 If the user passes a Pool handle and local name translation cache 1053 exists, the ASAP endpoint should remove the mapping information on 1054 the Pool handle from its local cache. If the user passes a 1055 Pool-Element-Handle then the Pool handle within is used for the 1056 cache.purge.request. 1058 Note that if the ASAP service does NOT support a local cache this 1059 primitive performs NO action. 1061 4.5 Data.Send.Request Primitive 1063 Format: data.send.request(destinationAddress, typeOfAddress, 1064 message, sizeOfMessage, Options); 1066 This primitive requests ASAP to send a message to some specified Pool 1067 or Pool Element within the current Operational scope. 1069 Depending on the address type used for the send request, the senders 1070 ASAP endpoint may perform address translation and Pool Element 1071 selection before sending the message out. This also MAY dictate the 1072 creation of a local transport endpoint in order to meet the required 1073 transport type. 1075 The data.send.request primitive can take different forms of address 1076 types as described in the following sections. 1078 4.5.1 Sending to a Pool Handle 1080 In this case the destinationAddress and typeOfAddress together 1081 indicates a pool handle. 1083 This is the simplest form of send.data.request primitive. By default, 1084 this directs ASAP to send the message to one of the Pool Elements in 1085 the specified pool. 1087 Before sending the message out to the pool, the senders ASAP endpoint 1088 MUST first perform a pool handle to address translation. It may also 1089 need to perform Pool Element selection if multiple Pool Elements 1090 exist in the pool. 1092 If the senders ASAP implementation does not support a local cache of 1093 the mapping information or if it does not have the mapping 1094 information on the pool in its local cache, it will transmit a 1095 NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the 1096 current home ENRP server, and MUST hold the outbound message in queue 1097 while awaiting the response from the ENRP server (any further send 1098 request to this pool before the ENRP server responds SHOULD also be 1099 queued). 1101 Once the necessary mapping information arrives from the ENRP server, 1102 the senders ASAP will: 1104 A) map the pool handle into a list of transport addresses of the 1105 destination PE(s), 1107 B) if multiple PEs exist in the pool, ASAP will choose one of them 1108 and transmit the message to it. In that case, the choice of the PE 1109 is made by ASAP endpoint of the sender based on the server pooling 1110 policy as discussed in Section 4.5.2 1112 C) Optionally create any transport endpoint that may be needed to 1113 communicate with the PE selected. 1115 D) if no transport association or connection exists towards the 1116 destination PE, ASAP will establish any needed transport state, 1118 E) send out the queued message(s) to the appropriate transport 1119 connection using the appropriate send mechanism (e.g. for SCTP the 1120 SEND primitive in RFC2960 [4] would be used), and, 1122 F) if the local cache is implemented, append/update the local cache 1123 with the mapping information received in the ENRP server's 1124 response. Also, record the local transport information (e.g. the 1125 SCTP association id) if any new transport state was created. 1127 For more on the ENRP server request procedures see ENRP [6]. 1129 Optionally, the ASAP endpoint of the sender may return a Pool Element 1130 handle of the selected PE to the application after sending the 1131 message. This PE handle can then be used for future transmissions to 1132 that same PE (see Section 4.5.3). 1134 Section 3.7 defines the fail-over procedures for cases where the 1135 selected PE is found unreachable. 1137 4.5.2 Pool Element Selection 1139 Each time an ASAP user sends a message to a pool that contains more 1140 than one PE, the senders ASAP endpoint must select one of the PEs in 1141 the pool as the receiver of the current message. The selection is 1142 done according to the current server pooling policy of the pool to 1143 which the message is sent. 1145 Note, no selection is needed if the ASAP_SEND_TOALL option is set 1146 (see Section 4.5.5). 1148 Together with the server pooling policy, each PE can also specify a 1149 Policy Value for itself at the registration time. The meaning of the 1150 policy value depends on the current server pooling policy of the 1151 group. A PE can also change its policy value whenever it desires, by 1152 re-registering itself with the namespace with a new policy value. 1153 Re-registration shall be done by simply sending another REGISTRATION 1154 to its home ENRP server (See Section 2.2.1). 1156 Four basic server pooling policies are defined in ASAP, namely the 1157 Round Robin, Least Used, Least Used Degrading and Weighted Round 1158 Robin. The following sections describes each of these policies. 1160 4.5.2.1 Round Robin Policy 1162 When a ASAP endpoint sends messages by Pool Handle and Round-Robin is 1163 the current policy of that Pool, the ASAP endpoint of the sender will 1164 select the receiver for each outbound message by round-Robining 1165 through all the registered PEs in that Pool, in an attempt to achieve 1166 an even distribution of outbound messages. Note that in a large 1167 server pool, the ENRP server MAY NOT send back all PEs to the ASAP 1168 client. In this case the client or PU will be performing a round 1169 robin policy on a subset of the entire Pool. 1171 4.5.2.2 Least Used Policy 1173 When the destination Pool is under the Least Used server pooling 1174 policy, the ASAP endpoint of the message sender will select the PE 1175 that has the lowest policy value in the group as the receiver of the 1176 current message. If more than one PE from the group share the same 1177 lowest policy value, the selection will be done round Robin amongst 1178 those PEs. 1180 It is important to note that this policy means that the same PE will 1181 be always selected as the message receiver by the sender until the 1182 load control information of the pool is updated and changed in the 1183 local cache of the sender (via a cache update see Section 3.3). 1185 4.5.2.3 Least Used with Degradation Policy 1187 This policy is the same as the Least Used policy with the exception 1188 that, each time the PE with the lowest policy value is selected from 1189 the Pool as the receiver of the current message, its policy value is 1190 incremented, and thus it may no longer be the lowest value in the 1191 Pool. 1193 This provides a degradation of the policy towards round Robin policy 1194 over time. As with the Least Used policy, every local cache update at 1195 the sender will bring the policy back to Least Used with Degradation. 1197 4.5.2.4 Weighted Round Robin Policy 1199 [TBD] 1201 4.5.3 Sending to a Pool Element Handle 1203 In this case the destinationAddress and typeOfAddress together 1204 indicate an ASAP Pool Element handle. 1206 This requests the ASAP endpoint to deliver the message to the PE 1207 identified by the Pool Element handle. 1209 The Pool Element handle should contain the Pool Handle and a 1210 destination transport address of the destination PE or the Pool 1211 Handle and the transport type. Other implementation dependant 1212 elements may also be cached in a Pool Element handle. 1214 The ASAP endpoint shall use the transport address and transport type 1215 to identify the endpoint to communicate with. If no communication 1216 state exists with the peer endpoint (and is required by the transport 1217 protocol) the ASAP endpoint MAY setup the needed state and then 1218 invoke the SEND primitive for the particular transport protocol to 1219 send the message to the PE. 1221 In addition, if a local translation cache is supported the endpoint 1222 will: 1224 A) send out the message to the transport address (or association id) 1225 designated by the PE handle. 1227 B) determine if the Pool Handle is in the local cache. 1229 If it is NOT, the endpoint will: 1231 i) ask the home ENRP server for name resolution on pool handle by 1232 sending a NAME.RESOLUTION message (see Section 2.2.5), and 1234 ii) use the response to update the local cache. 1236 If the pool handle is in the cache, the endpoint will only 1237 update the pool handle if the cache is stale. A stale cache is 1238 indicated by it being older than the protocol parameter 1239 'stale.cache.value' (see Section 5.2). 1241 Section 3.5 and Section 4.9 defines the fail-over procedures for 1242 cases where the PE pointed to by the Pool Element handle is found 1243 unreachable. 1245 Optionally, the ASAP endpoint may return the actual Pool Element 1246 handle to which the message was sent (this may be different from the 1247 Pool Element handle specified when the primitive is invoked, due to 1248 the possibility of automatic fail-over). 1250 4.5.4 Send by Transport Address 1252 In this case the destinationAddress and typeOfAddress together 1253 indicate a transport address and transport type. 1255 This directs the senders ASAP endpoint to send the message out to the 1256 specified transport address. 1258 No endpoint fail-over is support when this form of send request is 1259 used. This form of send request effectively by-passes the ASAP 1260 endpoint. 1262 4.5.5 Message Delivery Options 1264 The Options parameter passed in the various forms of the above 1265 data.send.request primitive gives directions to the senders ASAP 1266 endpoint on special handling of the message delivery. 1268 The value of the Options parameter is generated by bit-wise "OR"ing 1269 of the following pre-defined constants: 1271 ASAP_USE_DEFAULT: 0x0000 Use default setting. 1273 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 1274 case where the first selected PE or the PE pointed to by the PE 1275 handle is found unreachable, the sender's ASAP endpoint SHOULD 1276 re-select an alternate PE from the same pool if one exists, and 1277 silently re-send the message to this newly selected endpoint. 1279 Note that this is a best-effort service. Applications should be 1280 aware that messages can be lost during the failover process, even 1281 if the underlying transport supports retrieval of unacknowledged 1282 data (e.g. SCTP) (Example: messages acknowledged by the SCTP layer 1283 at a PE, but not yet read by the PE when a PE failure occurs.) In 1284 the case where the underlying transport does not support such 1285 retrieval (e.g. TCP), any data already submitted by ASAP to the 1286 transport layer MAY be lost upon failover. 1288 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP 1289 endpoint from re-sending the message to any alternate PE in case 1290 that the first selected PE or the PE pointed to by the PE handle 1291 is found unreachable. Instead, the senders ASAP endpoint shall 1292 notify its upper layer about the unreachability with an 1293 Error.Report and return any unsent data. 1295 ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 1296 endpoint to send the message to the same PE in the pool that the 1297 previous message destined to this pool was sent to. 1299 ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option 1300 directs the senders ASAP endpoint to send a copy of the message to 1301 all the PEs, except for the sender itself if the sender is a PE, 1302 in that pool. 1304 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination 1305 with ASAP_SEND_TO_ALL option. It permits the senders ASAP endpoint 1306 also deliver a copy of the message to itself if the sender is a PE 1307 of the pool (i.e., loop-back). 1309 ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to 1310 send the current message using un-ordered delivery (note the 1311 underlying transport must support un-ordered delivery for this 1312 option to be effective). 1314 4.6 Data.Received Notification 1316 Format: data.received(messageReceived, sizeOfMessage, senderAddress, 1317 typeOfAddress) 1319 When a new user message is received, the ASAP endpoint of the 1320 receiver uses this notification to pass the message to its upper 1321 layer. 1323 Along with the message being passed, the ASAP endpoint of the 1324 receiver should also indicate to its upper layer the message senders 1325 address. The senders address can be in the form of either an SCTP 1326 association id, TCP transport address, UDP transport address, or a 1327 ASAP Pool Element handle. 1329 A) If the name translation local cache is implemented at the 1330 receiver's ASAP endpoint, a reverse mapping from the senders IP 1331 address to the pool handle should be performed and if the mapping 1332 is successful, the senders ASAP Pool Element handle should be 1333 constructed and passed in the senderAddress field. 1335 B) If there is no local cache or the reverse mapping is not 1336 successful, the SCTP association id or other transport specific 1337 identification (if SCTP is not being used) should be passed in the 1338 senderAddress field. 1340 4.7 Error.Report Notification 1342 Format: error.report(destinationAddress, typeOfAddress, 1343 failedMessage, sizeOfMessage) 1345 An error.report should be generated to notify the ASAP user about 1346 failed message delivery as well as other abnormalities. 1348 The destinationAddress and typeOfAddress together indicates to whom 1349 the message was originally sent. The address type can be either a 1350 ASAP Pool Element handle, association id, or a transport address. 1352 The original message (or the first portion of it if the message is 1353 too big) and its size should be passed in the failedMessage and 1354 sizeOfMessage fields, respectively. 1356 4.8 Examples 1358 These examples assume an underlying SCTP transport between the PE and 1359 PU. Other transports are possible but SCTP is utilized in the 1360 examples for illustrative purposes. Note that all communication 1361 between PU and ENRP server and PE and ENRP servers would be using 1362 SCTP. 1364 4.8.1 Send to a New Pool 1366 This example shows the event sequence when a Pool User sends the 1367 message "hello" to a pool which is not in the local translation cache 1368 (assuming local caching is supported). 1370 ENRP Server PU new-name:PEx 1372 | | | 1373 | +---+ | 1374 | | 1 | | 1375 | 2. NAME_RESOLUTION +---+ | 1376 |<-------------------------------| | 1377 | +---+ | 1378 | | 3 | | 1379 | 4. NAME_RESOLUTION_REPONSE +---+ | 1380 |------------------------------->| | 1381 | +---+ | 1382 | | 5 | | 1383 | +---+ 6. "hello1" | 1384 | |---------------->| 1385 | | | 1387 1) The user at PU invokes: 1389 data.send.request("new-name", name-type, "hello1", 6, 0); 1391 The ASAP endpoint, in response, looks up the pool "new-name" in 1392 its local cache but fails to find it. 1394 2) The ASAP endpoint of PU queues the message, and sends a 1395 NAME_RESOLUTION request to the ENRP server asking for all 1396 information about pool "new-name". 1398 3) A T1-ENRPrequest timer is started while the ASAP endpoint is 1399 waiting for the response from the ENRP server. 1401 4) The ENRP Server responds to the query with a 1402 NAME_RESOLUTION_REPONSE message that contains all the information 1403 about pool "new-name". 1405 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 1406 cache with information on pool "new-name". 1408 6) Based on the server pooling policy of pool "new-name", ASAP at PU 1409 selects the destination PE (PEx), sets up, if necessary, an SCTP 1410 association towards PEx (explicitly or implicitly), and send out 1411 the queued "hello1" user message. 1413 4.8.2 Send to a Cached Pool Handle 1415 This shows the event sequence when the ASAP user PU sends another 1416 message to the pool "new-name" after what happened in Section 4.8.1. 1418 ENRP Server PU new-name:PEx 1420 | | | 1421 | +---+ | 1422 | | 1 | | 1423 | +---+ 2. "hello2" | 1424 | |---------------->| 1425 | | | 1427 1) The user at PU invokes: 1429 pdata.send.request("new-name", name-type, "hello2", 6, 0); 1431 The ASAP endpoint, in response, looks up the pool "new-name" in 1432 its local cache and find the mapping information. 1434 2) Based on the server pooling policy of "new-name", ASAP at PU 1435 selects the PE (assume EPx is selected again), and sends out 1436 "hello2" message (assume the SCTP association is already set up). 1438 4.9 PE send failure 1440 When the ASAP endpoint in a PE or PU attempts to send a message to a 1441 PE and fails the failed sender will report the event as described in 1442 Section 3.5 . 1444 Additional primitive are also defined in this section to support 1445 those user applications that do not wish to use ASAP as the actual 1446 transport. 1448 4.9.1 Translation.Request Primitive 1450 Format: translation.request(Pool-Handle) 1452 If the address type is a Pool handle and a local name translation 1453 cache exists, the ASAP endpoint should look within its translation 1454 cache and return the current known transport types, ports and 1455 addresses to the caller. 1457 If the Pool handle does not exist in the local name cache or no name 1458 cache exists, the ASAP endpoint will send a NAME.RESOLUTION request 1459 using the Pool-Handle. Upon completion of the name resolution, the 1460 ASAP endpoint should populate the local name cache (if a local name 1461 cache is supported) and return the transport types, ports and 1462 addresses to the caller. 1464 4.9.2 Transport.Failure Primitive 1466 Format: transport.failure(Pool-Handle, Transport-address) 1468 If an external user encounters a failure in sending to a PE and is 1469 NOT using ASAP it can use this primitive to report the failure to the 1470 ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ENRP 1471 server in response to this primitive. Note ASAP SHOULD NOT send a 1472 ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous 1473 request to send data to the PE. 1475 5. Variables, Timers, and Thresholds 1477 The following is a summary of the variables, timers, and pre-set 1478 protocol constants used in ASAP. 1480 5.1 Timers 1482 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1483 the ENRP server (providing application information is queued). 1484 Normally set to 15 seconds. 1486 T2-registration - A timer started when sending a registration request 1487 to the home ENRP server, normally set to 30 seconds. 1489 T3-deregistration - A timer started when sending a deregistration 1490 request to the home ENRP server, normally set to 30 seconds. 1492 T4-reregistration - This timer is started after successful 1493 registration into the ASAP name space and is used to cause a 1494 re-registration at a periodic interval. This timer is normally set 1495 to 10 minutes or 20 seconds less than the Life Timer parameter 1496 used in the registration request (whichever is less). 1498 T5-Serverhunt - This timer is used during the ENRP server hunt 1499 procedure and is normally set to 120 seconds. 1501 T6-Serverannounce - This timer gives the time between the sending of 1502 consecutive SERVER_ANNOUNCE messages. It is normally set to 1 1503 second. 1505 T7-ENRPoutdate - This timer gives the time a server announcement is 1506 valid. It is normally set to 5 seconds. 1508 5.2 Thresholds and Variables 1510 max-reg-attempt - The maximum number of registration attempts to be 1511 made before a server hunt is issued. 1513 max-request-retransmit - The maximum number of attempts to be made 1514 when requesting information from the local ENRP server before a 1515 server hunt is issued. 1517 stale.cache.value - A threshold variable that indicates how long a 1518 cache entry is valid for. 1520 6. Security Considerations 1522 Due to varying requirements and multiple use cases of Rserpool, we 1523 point out two basic security protocols, IPsec and TLS. We 1524 specifically do not discuss whether one security protocol would be 1525 preferred over the other. This choice will be made by designers and 1526 network architects based on system requirements. 1528 For networks that demand IPsec security, implementations MUST support 1529 SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below 1530 RSerPool. Therefore, if IPsec is used for securing Rserpool, no 1531 changes or special considerations need to be made to Rserpool to 1532 secure the protocol. 1534 For networks that cannot or do not wish to use IPsec and prefer 1535 instead TLS, implementations MUST support TLS with SCTP as described 1536 in RFC3436 [8] or TLS over TCP as described in RFC2246 [3] When using 1537 TLS/SCTP we must ensure that RSerPool does not use any features of 1538 SCTP that are not available to an TLS/SCTP user. This is not a 1539 difficult technical problem, but simply a requirement. When 1540 describing an API of the RSerPool lower layer we have also to take 1541 into account the differences between TLS and SCTP. This is also not 1542 difficult, but it is in contrast to the IPsec solution which is 1543 transparently layered below Rserpool. 1545 Support for security is required for the ENRP server and the PEs. 1546 Security support for the Rserpool end user is optional. Note that 1547 the end user implementation contains a piece of the Rserpool protocol 1548 -- namely ASAP -- whereby the pool handle is passed for name 1549 resolution to the ENRP server and IP address(es) are returned. 1551 The argument for optional end user security is as follows: If the 1552 user doesn't require security protection for example, against 1553 eavesdropping for the request for pool handle resolution and 1554 response, then they are free to make that choice. However, if the 1555 end user does require security, they are guaranteed to get it due to 1556 the requirement for security support for the ENRP server. It is also 1557 possible for the ENRP server to reject an unsecured request from the 1558 user due to its security policy in the case that it requires 1559 enforcement of strong security. But this will be determined by the 1560 security requirements of the individual network design. 1562 7. Acknowledgments 1564 The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon 1565 Ong, and many others for their invaluable comments. 1567 Normative References 1569 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1570 9, RFC 2026, October 1996. 1572 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1573 Levels", BCP 14, RFC 2119, March 1997. 1575 [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 1576 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1577 1999. 1579 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1580 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1581 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1583 [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1584 Server Access Protocol and Endpoint Name Resolution Protocol 1585 Common Parameters", draft-ietf-rserpool-common-param-01 (work in 1586 progress), June 2002. 1588 [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution 1589 Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in 1590 progress), May 2002. 1592 [7] Bellovin, S., "On the Use of SCTP with IPsec", 1593 draft-ietf-ipsec-sctp-06 (work in progress), April 2003. 1595 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1596 3436, December 2002. 1598 Informational References (non-normative) 1600 [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1601 Recommendations for Security", RFC 1750, December 1994. 1603 Authors' Addresses 1605 Randall R. Stewart 1606 Cisco Systems, Inc. 1607 8725 West Higgins Road 1608 Suite 300 1609 Chicago, IL 60631 1610 USA 1612 Phone: +1-815-477-2127 1613 EMail: rrs@cisco.com 1615 Qiaobing Xie 1616 Motorola, Inc. 1617 1501 W. Shure Drive, #2309 1618 Arlington Heights, IL 60004 1619 USA 1621 Phone: +1-847-632-3028 1622 EMail: qxie1@email.mot.com 1624 Maureen Stillman 1625 Nokia 1626 127 W. State Street 1627 Ithaca, NY 14850 1628 USA 1630 Phone: +1-607-273-0724 1631 EMail: maureen.stillman@nokia.com 1633 Michael Tuexen 1635 Germany 1637 Phone: 1638 EMail: tuexen@fh-muenster.de 1640 Intellectual Property Statement 1642 The IETF takes no position regarding the validity or scope of any 1643 intellectual property or other rights that might be claimed to 1644 pertain to the implementation or use of the technology described in 1645 this document or the extent to which any license under such rights 1646 might or might not be available; neither does it represent that it 1647 has made any effort to identify any such rights. Information on the 1648 IETF's procedures with respect to rights in standards-track and 1649 standards-related documentation can be found in BCP-11. Copies of 1650 claims of rights made available for publication and any assurances of 1651 licenses to be made available, or the result of an attempt made to 1652 obtain a general license or permission for the use of such 1653 proprietary rights by implementors or users of this specification can 1654 be obtained from the IETF Secretariat. 1656 The IETF invites any interested party to bring to its attention any 1657 copyrights, patents or patent applications, or other proprietary 1658 rights which may cover technology that may be required to practice 1659 this standard. Please address the information to the IETF Executive 1660 Director. 1662 Full Copyright Statement 1664 Copyright (C) The Internet Society (2003). All Rights Reserved. 1666 This document and translations of it may be copied and furnished to 1667 others, and derivative works that comment on or otherwise explain it 1668 or assist in its implementation may be prepared, copied, published 1669 and distributed, in whole or in part, without restriction of any 1670 kind, provided that the above copyright notice and this paragraph are 1671 included on all such copies and derivative works. However, this 1672 document itself may not be modified in any way, such as by removing 1673 the copyright notice or references to the Internet Society or other 1674 Internet organizations, except as needed for the purpose of 1675 developing Internet standards in which case the procedures for 1676 copyrights defined in the Internet Standards process must be 1677 followed, or as required to translate it into languages other than 1678 English. 1680 The limited permissions granted above are perpetual and will not be 1681 revoked by the Internet Society or its successors or assignees. 1683 This document and the information contained herein is provided on an 1684 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1685 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1686 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1687 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1688 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1690 Acknowledgement 1692 Funding for the RFC Editor function is currently provided by the 1693 Internet Society.