idnits 2.17.1 draft-ietf-rserpool-asap-06.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 (February 26, 2003) is 7728 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 1212 == Unused Reference: '1' is defined on line 1582, 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') == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-sctp-04 ** Obsolete normative reference: RFC 1750 (ref. '9') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: August 27, 2003 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 February 26, 2003 11 Aggregate Server Access Protocol (ASAP) 12 draft-ietf-rserpool-asap-06.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 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 27, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 Aggregate Server Access Protocol (ASAP) in conjunction with the 44 Endpoint Name Resolution Protocol (ENRP) [6] provides a high 45 availability data transfer mechanism over IP networks. ASAP uses a 46 name-based addressing model which isolates a logical communication 47 endpoint from its IP address(es), thus effectively eliminating the 48 binding between the communication endpoint and its physical IP 49 address(es) which normally constitutes a single point of failure. 51 In addition, ASAP defines each logical communication destination as a 52 pool, providing full transparent support for server-pooling and load 53 sharing. It also allows dynamic system scalability - members of a 54 server pool can be added or removed at any time without interrupting 55 the service. 57 ASAP is designed to take full advantage of the network level 58 redundancy provided by the Stream Transmission Control Protocol 59 (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool 60 Elements (PE) and Pool Users (PU) MUST have an accompanying 61 transports mapping document. Note that ASAP messages passed between 62 PE's and ENRP servers MUST use SCTP. 64 The high availability server pooling is gained by combining two 65 protocols, namely ASAP and ENRP, in which ASAP provides the user 66 interface for name to address translation, load sharing management, 67 and fault management while ENRP defines the high availability name 68 translation service. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.2 Organization of this document . . . . . . . . . . . . . . 7 75 1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 76 1.3.1 Extent of the Namespace . . . . . . . . . . . . . . . . . 7 77 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Message Definitions . . . . . . . . . . . . . . . . . . . 8 79 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 80 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 81 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9 82 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9 83 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10 84 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10 85 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11 86 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11 87 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12 88 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 13 89 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13 90 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 14 91 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14 92 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14 93 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 15 94 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15 95 2.2.15 Data Channel Contact message . . . . . . . . . . . . . . . 15 96 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17 97 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 17 98 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 99 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 19 100 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 20 101 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 21 102 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 21 103 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 23 104 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 23 105 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 23 106 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 107 3.9 Business Card handling procedures . . . . . . . . . . . . 24 108 3.10 Data Channel Contact Message . . . . . . . . . . . . . . . 24 109 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 25 110 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25 111 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25 112 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 113 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 114 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 115 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 27 116 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 28 117 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 29 118 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 30 119 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 30 120 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32 121 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32 122 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 123 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 33 124 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 34 125 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34 126 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 35 127 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 35 128 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 36 129 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 130 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 36 131 6. Security Considerations . . . . . . . . . . . . . . . . . 37 132 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38 133 Normative References . . . . . . . . . . . . . . . . . . . 39 134 Informational References (non-normative) . . . . . . . . . 40 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 136 Intellectual Property and Copyright Statements . . . . . . 41 138 1. Introduction 140 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] 141 provides a high availability data transfer mechanism over IP 142 networks. ASAP uses a name-based addressing model which isolates a 143 logical communication endpoint from its IP address(es), thus 144 effectively eliminating the binding between the communication 145 endpoint and its physical IP address(es) which normally constitutes a 146 single point of failure. 148 When multiple receiver instances exist under the same name, a.k.a, a 149 server pool, ASAP will select one Pool Element (PE), based on the 150 current load sharing policy indicated by the server pool, and deliver 151 the message to the selected PE. 153 While delivering the message, ASAP monitors the reachability of the 154 selected PE. If it is found unreachable, before notifying the sender 155 of the failure, ASAP can automatically select another PE (if one 156 exists) under that pool and attempt to deliver the message to that 157 PE. In other words, ASAP is capable of transparent fail-over amongst 158 instances of a server pool. 160 ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a 161 high availability name space. ASAP is responsible for the 162 abstraction of the underlying transport technologies, load 163 distribution management, fault management, as well as the 164 presentation to the upper layer (i.e., the ASAP user) a unified 165 primitive interface. 167 When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP 168 can seamlessly incorporate the link-layer redundancy provided by the 169 SCTP. 171 This document defines the ASAP portion of the high availability 172 server pool. ASAP depends on the services of a high availability 173 name space a.k.a. ENRP [6]. 175 1.1 Definitions 177 This document uses the following terms: 179 ASAP User: Either a PE or PU that uses ASAP. 181 Operation scope: The part of the network visible to Pool Users by a 182 specific instance of the reliable server pooling protocols. 184 Server pool (or Pool): A collection of servers providing the same 185 application functionality. 187 Pool handle (or pool name): A logical pointer to a pool. Each server 188 pool will be identifiable in the operation scope of the system by 189 a unique pool handle or "name". 191 Pool Element (PE): A server entity having registered to a pool. 193 Pool User (PU): A server Pool User. 195 Pool Element handle (PE handle): A logical pointer to a particular 196 Pool Element in a pool, 198 ENRP server: A server program running on a host that manages the name 199 space collectively with its peer ENRP servers and replies to the 200 service requests from any Pool User or Pool Element. 202 Home ENRP server: The ENRP server to which a Pool Element currently 203 uses. A PU or PE normally chooses the ENRP server on their local 204 host as the home ENRP server (if one exists). A PU or PE should 205 only have one home ENRP server at any given time. Having a "home" 206 ENRP server helps provide a mechanism to minimize the number of 207 associations a given PE will have. 209 ENRP client channel: The communication channel through which an ASAP 210 User (either a PE or PU) requests ENRP namespace service. The 211 client channel is usually defined by the transport address of the 212 home server and a well known port number. The channel MAY make 213 use of multi-cast or a named list of ENRP servers. 215 ENRP server channel: Defined by a well known multicast IP address and 216 a well known port number, OR a well known list of transport 217 addresses for a group of ENRP servers spanning an operational 218 scope. All ENRP servers in an operation scope can communicate 219 with one another through this channel via either multicast OR 220 direct point to point SCTP associations. 222 ENRP name domain: Defined by the combination of the ENRP client 223 channel and the ENRP server channel in the operation scope. 225 Network Byte Order: Most significant byte first, a.k.a Big Endian. 227 Transport address: A Transport Address is traditionally defined by 228 Network Layer address, Transport Layer protocol and Transport 229 Layer port number. In the case of SCTP running over IP, a 230 transport address is defined by the combination of an IP address 231 and an SCTP port number (where SCTP is the Transport protocol). 233 1.2 Organization of this document 235 Section 2 details ASAP message formats. In Section 3 we give the 236 detailed ASAP procedures for the ASAP implementer. And in Section 4 237 we give the details of the ASAP interface, focusing on the 238 communication primitives between the applications above ASAP and ASAP 239 itself, and the communications primitives between ASAP and SCTP (or 240 other transport layer). Also included in this discussion is relevant 241 timers and configurable parameters as appropriate. Section 5 242 provides threshold and protocol variables. 244 1.3 Scope of ASAP 246 The requirements for high availability and scalability do not imply 247 requirements on shared state and data. ASAP does not provide 248 transaction failover. If a host or application fails during 249 processing of a transaction this transaction may be lost. Some 250 services may provide a way to handle the failure, but this is not 251 guaranteed. ASAP MAY provide hooks to assist an application in 252 building a mechanism to share state but ASAP in itself will NOT share 253 any state. 255 1.3.1 Extent of the Namespace 257 The scope of the ASAP/ENRP is NOT Internet wide. The namespace is 258 neither hierarchical nor arbitrarily large like DNS. We propose a 259 flat peer-to-peer model. Pools of servers will exist in different 260 administrative domains. For example, suppose we want to use ASAP/ 261 ENRP. First, the PU may use DNS to contact an ENRP server. Suppose 262 a PU in North America wishes to contact the server pool in Japan 263 instead of North America. The PU would use DNS to get the list of IP 264 addresses of the Japanese server pool domain, that is, the ENRP 265 client channel in Japan. From there the PU would query the ENRP 266 server and then directly contact the PE(s) of interest. 268 1.4 Conventions 270 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 271 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 272 they appear in this document, are to be interpreted as described in 273 RFC2119 [2]. 275 2. Message Definitions 277 All messages as well as their fields described below shall be in 278 Network Byte Order during transmission. For fields with a length 279 bigger than 4 octets, a number in a pair of parentheses may follow 280 the field name to indicate the length of the field in number of 281 octets. 283 2.1 ASAP Parameter Formats 285 The basic message format and all parameter formats can be found in 286 ENRP-ASAP [5]. Note also that ALL ASAP message exchanged between the 287 ENRP server and either a PE or PU MUST user SCTP. PE to PU data 288 traffic MAY use any transport protocol specified by the PE during 289 registration. 291 2.2 ASAP Messages 293 This section details the individual messages used by ASAP. These 294 messages are composed of a standard message format found in Section 4 295 or ENRP-ASAP [5]. The parameter descriptions may also be found in 296 Section 3 of ENRP-ASAP [5]. 298 The following ASAP message types are defined in this section: 300 Type Message Name 301 ----- ------------------------- 302 0x00 - (reserved by IETF) 303 0x01 - Registration 304 0x02 - Deregistration 305 0x03 - Registration Response 306 0x04 - Deregistration Response 307 0x05 - Name Resolution 308 0x06 - Name Resolution Response 309 0x07 - Endpoint Keep Alive 310 0x08 - Endpoint Keep Alive Acknowledgement 311 0x09 - Endpoint Unreachable 312 0x0a - Server Announce 313 0x0b - Cookie 314 0x0c - Cookie-Echo 315 0x0d - Business Card 316 0x0e - Peer Error 317 0x0f - Data Channel Contact 319 2.2.1 REGISTRATION message 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 : Pool Handle Parameter : 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 : Pool Element Parameter : 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 The pool handle parameter field specifies the name to be registered. 332 The PE Parameter field MUST be filled in by the registrant endpoint 333 to declare its transports and addresses, server pooling policy and 334 value, and other operation preferences. Note that the registration 335 message MUST use SCTP and the IP addresses of the PE registered 336 within the Pool Element Parameter MUST be a subset of the addresses 337 of the SCTP association irrespective of the transport protocol 338 regestered by the PE. 340 2.2.2 DEREGISTRATION message 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 : Pool Handle Parameter : 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 : PE Identifier Parameter : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 352 The PE sending the DEREGISTRATION shall fill in the pool handle and 353 the PE identifier parameter in order to allow the ENRP server to 354 verify the identity of the endpoint. Note that deregistration is NOT 355 allowed by proxy, in other words a PE may only deregister itself. 357 2.2.3 REGISTRATION_RESPONSE message 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 : Pool Handle Parameter : 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : PE Identifier Parameter : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 : Operational Error (optional) : 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 : Member Selection Policy Parameter (optional) : 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Operational Error 375 This optional TLV parameter is included if an error or a selection 376 policy override occured during the registration process. The cause 377 code carried in this TLV will indicate to the registering PE whether 378 the registration is rejected or accepted with a warning (e.g., policy 379 overruled). If the registration was sucessful and there is no 380 warning this parameter is not included. 382 Member Selection Policy 384 This optional TLV parameter is included if the ENRP has overridden 385 the member selection policy of the registering PE. The new policy is 386 indicated in this parameter. See Section 4.3? of [6] for more 387 details on policy override during registration. 389 2.2.4 DEREGISTRATION_RESPONSE message 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 : Pool Handle Parameter : 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : PE Identifier Parameter : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 : Operational Error (optional) : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Operational Error 404 This optional TLV parameter is included if an error occured during 405 the deregistration process. If the deregistration was sucessful this 406 parameter is not included. 408 2.2.5 NAME_RESOLUTION message 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 : Pool Handle Parameter : 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 : Communication Restrictions Parameter : 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 This message is sent to a ENRP server to request translation of the 421 Pool Handle to a list of Pool Elements. If sent from a PE the SCTP 422 association used for registration SHOULD be used. 424 The Communication Restrictons Parameter is an optional parameter that 425 MAY be included. Note that if a Communication Restrictions Parameter 426 is NOT present the ENRP server will treat the request the same as if 427 the requestor had specified any transport for both Control and Data. 429 2.2.6 NAME_RESOLUTION_RESPONSE message 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 : Pool Handle Parameter : 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 : Overall PE Selection Policy (optional) : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 : Pool Element Parameter 1 (optional) : 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 : ... : 443 : : 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 : Pool Element Parameter N (optional) : 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 : Operational Error (optional) : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Overall PE Selection Policy: 452 This TLV is a PE selection policy parameter and can be present when 453 the response is positive. It indicates the overall selection policy 454 of the pool. If not present, round-robin is assumed. This TLV is 455 not present when the response is negative (i.e., a rejection). 457 Note, any load policy parameter inside the Pool Element Parameter (if 458 present) MUST be ignored, and MUST NOT be used to determine the 459 overall pool policy. 461 Pool Element Parameters 463 When the response is positive, an array of PE TLVs are included, 464 indicating the current PEs and their information in the named pool. 465 In a positive response, at least one PE TLV MUST be present. When 466 the response is negative, no PE TLVs are included. 468 Operational Error 470 The presence of this TLV indicates that the response is negative 471 (i.e., the name resolution request was rejected by the ENRP server). 472 The cause code in this TLV (if present) will indicate the reason the 473 name resolution request was rejected (e.g., the requested pool handle 474 was not found). 476 2.2.7 ENDPOINT_KEEP_ALIVE message 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 : Pool Handle Parameter : 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 This message is sent to a PE by the ENRP server has a "health" check. 487 If the transport level Heart Beat mechanism is insufficient (usually 488 this means that time outs are set for too long or heartbeats are not 489 frequent enough), this adds heartbeat messages with the goal of 490 determining health status in a more timely fashion. 492 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 : Pool Handle Parameter : 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 : PE Identifier Parameter : 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 This message is sent by the PE to the ENRP server has an 505 acknowledgment to the ENDPOINT_KEEP_ALIVE message. 507 2.2.9 ENDPOINT_UNREACHABLE message 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 : Pool Handle Parameter : 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : PE Identifier Parameter : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 A PE or PU will send this message to an ENRP server to report the 520 unreachability of the specified PE. 522 2.2.10 SERVER_ANNOUNCE message 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 : Transport param #1 : 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 : Transport param #2 : 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 : : 534 : ..... : 535 : : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 : Transport param #n : 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 This message is sent by an ENRP server such that PUs and PEs know the 541 transport layer information necessary to connect to the ENRP server. 542 The transport parameters are optional and only TCP and SCTP transport 543 parameters are allowed. 545 2.2.11 COOKIE message 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 = 0x0b |0|0|0|0|0|0|0|0| Message Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 : Cookie Parameter : 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 This message is sent by a PE to a PU. It may only be sent when a 556 control channel exists between the PE and PU. 558 2.2.12 COOKIE_ECHO message 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 : Cookie Parameter : 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 This message is sent by a PU to a PE in case of a failover. The 569 Cookie Parameter is one received latest from the failed PE. 571 2.2.13 BUSINESS_CARD message 573 This message is sent by a PU to a PE or from a PE to a PU. This 574 parameter MUST NOT be sent if a control channel does NOT exists 575 between the PE and PU. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type = 0xd |0|0|0|0|0|0|0|0| Message Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 : Pool Handle Parameter : 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 : Pool Element Parameter-1 : 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 : .. : 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 : Pool Element Parameter-N : 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 The sender of this message lists both the Pool that the sender 592 belongs to and a prefered list of failover candidates. 594 2.2.14 PEER_ERROR message 596 This message is used to report an operation error. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type = 0xe |0|0|0|0|0|0|0|0| Message Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 : Operation Error Parameter : 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 2.2.15 Data Channel Contact message 608 This message is used in communication between a PE and PU. When the 609 PE wishes the PU to transfer data on a different transport address 610 this message is sent to the PU by the PE to inform the PU where data 611 messages should be sent. 613 0 1 2 3 614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type = 0xf |0|0|0|0|0|0|0|0| Message Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 : User Transport Parameter | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 A single User Transport Parameter is included with this message. The 622 parameter identifies a transport address (UDP, TCP or SCTP) to send 623 Data to. 625 3. Procedures 627 This section will focus on the methods and procedures used by an 628 internal ASAP endpoint. Appropriate timers and recovery actions for 629 failure detection and management are also discussed. 631 3.1 Registration 633 When a PE wishes to join its server pool it MUST use the procedures 634 outlined in this section to register. Often the registration will be 635 triggered by a user request primitive (discussed in Section 4.1). 636 The ASAP endpoint MUST register using an SCTP association between the 637 ASAP endpoint and the ENRP server. If the ASAP endpoint has not 638 established its Home ENRP server it MUST follow the procedures 639 specified in Section 3.6 to establish its Home ENRP server. 641 Once the ASAP endpoint has established its Home ENRP server the 642 following procedures MUST be followed to register: 644 R1) The SCTP endpoint used to communicate with the ENRP server MUST 645 be bound to all IP addresses that will be used by the PE 646 (irregardless of what protocol will be used to service user 647 requests to the PE). 649 R2) The ASAP endpoint MUST formulate a Registration message as 650 defined in Section 2.2.1 In formulating the message the ASAP 651 endpoint MUST: 653 R2.1) Fill in the the Pool Handle to specify which server pool the 654 ASAP endpoint wishes to join. 656 R2.2) Fill in a PE identifier using a good quality randomly 657 generated number (RFC1750 [9] provides some information on 658 randomness guidelines). 660 R2.3) Fill in the registration life time parameter with the number 661 of seconds that this registration is good for. Note a PE that 662 wishes to continue service MUST re-register after the 663 registration expires. 665 R2.4) Fill in a User Transport Parameter for EACH type of 666 transport the PE is willing to support. 668 R2.5) Fill in the preferred Member selection policy. 670 R3) Send the Registration request to the Home ENRP server using SCTP. 672 R4) Start a T2-registration timer. 674 If the T2-registration timer expires before receiving a 675 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 676 received from the SCTP layer, the ASAP endpoint shall start the 677 Server Hunt procedure (see Section 3.6) in an attempt to get service 678 from a different ENRP server. After establishing a new Home ENRP 679 server the ASAP endpoint SHOULD restart the registration procedure. 681 At the reception of the registration response, the ASAP endpoint MUST 682 stop the T2-Registration timer. If the response indicated success, 683 then the PE is now registered and will be considered an available 684 member of the server pool. If the registration response indicates a 685 failure, the ASAP endpoint must either re-attempt registration after 686 correcting the error or return a failure indication to the ASAP 687 endpoints upper layer. The ASAP endpoint MUST NOT re-attempt 688 registration without correcting the error condition. 690 At any time a registered PE MAY wish to re-register to either update 691 its member selection policy value or registration expiration time. 692 When re-registering the PE MUST use the same PE identifier. 694 After successful registration the PE MUST start a T4-reregistration 695 timer. At its expiration a re-registration SHOULD be made starting 696 at step R1 including (at completion) restarting the T4-reregistration 697 timer. 699 Note that an implementation SHOULD keep a record of the number of 700 registration attempts it makes in a local variable. If repeated 701 registration time-outs or failures occurs and the local count exceeds 702 the Threshold 'max-reg-attempt' the implementation SHOULD report the 703 error to its upper layer and stop attempting registration. 705 3.2 Deregistration 707 In the event the PE wishes to deregister from its server pool 708 (normally via an upper layer requests see Section 4.2) it SHOULD use 709 the following procedures. Note that an alternate method of 710 deregistration is to NOT re-register and to allow the registration 711 lift time to expire. 713 When deregistering the PE SHOULD use the same SCTP association with 714 its Home ENRP server that was used for registration. To deregister 715 the ASAP endpoint MUST take the following actions: 717 D1) Fill in the Pool Handle parameter of the Deregistration message ( 718 Section 2.2.2) using the same Pool Handle parameter sent during 719 registration. 721 D2) Fill in the PE Identifier. The identifier MUST be the same one 722 used during registration. 724 D3) Send the deregistration message to the Home ENRP server using the 725 SCTP association. 727 D4) Start a T3-Deregistration timer. 729 If the T3-Deregistration timer expires before receiving a 730 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 731 received from the SCTP layer, the ASAP endpoint shall start the 732 Server Hunt procedure (see Section 3.6) in an attempt to get service 733 from a different ENRP server. After establishing a new Home ENRP 734 server the ASAP endpoint SHOULD restart the deregistration procedure. 736 At the reception of the deregistration response, the ASAP endpoint 737 MUST stop the T3-deregistration timer. 739 Note that after a successful deregistration the PE MAY still receive 740 requests for some period of time. The PE MAY wish to still remain 741 active and service these requests or may wish to ignore these 742 requests and exit. 744 3.3 Name resolution 746 At any time a PE or PU may wish to resolve a name. This usually will 747 occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or 748 requests a cache population (Section 4.3) but may occur for other 749 reasons (e.g. the internal ASAP PE wishes to know its peers for 750 sending a message to all of them). When an Endpoint (PE or PU) 751 wishes to resolve a name it MUST take the following actions: 753 NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool 754 Handle to be resolved. 756 NR2) If the endpoint does not have a Home ENRP server start the ENRP 757 Server Hunt procedures specified in Section 3.6 to obtain one. 758 Otherwise proceed to step NR3. 760 NR3) Send the NAME_RESOLUTION message to the Home ENRP server using 761 SCTP. 763 NR4) Start a T1-ENRPrequest timer. 765 If the T1-ENRPrequest timer expires before receiving a response 766 message, or a SEND.FAILURE notification is received from the SCTP 767 layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see 768 Section 3.6) in an attempt to get service from a different ENRP 769 server. After establishing a new Home ENRP server the ASAP endpoint 770 SHOULD restart the name resolution procedure. 772 At the reception of the response message (i.e., a 773 NAME_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-ENRPrequest 774 timer. After stopping the T1 timer the endpoint SHOULD process the 775 name response as appropriate (e.g. populate a local cache, give the 776 response to the ASAP user, and/or use the response to send the ASAP 777 users message). 779 Note that some ASAP endpoints MAY use a cache to minimize the number 780 of name resolutions made. If such a cache is used it SHOULD: 782 C1) Be consulted before requesting a name resolution. 784 C2) Have a stale timeout time associated with the cache so that even 785 in the event of a cache-hit, if the cache is "stale" it will cause 786 a new name_resolution to be issued to update the cache. 788 C3) In the case of a "stale" cache the implementation may in parallel 789 request an update and answer the request or block the user and 790 wait for an updated cache before proceeding with the users 791 request. 793 C4) If the cache is NOT stale, the endpoint SHOULD NOT make a 794 name_resolution request but instead use the entry from the cache. 796 3.4 Endpoint keep alive 798 Periodically an ENRP server may choose to "audit" a PE. It does this 799 by sending a ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). Upon 800 reception of an ENDPOINT_KEEP_ALIVE message the following actions 801 MUST be taken: 803 KA1) The PE must verify that the Pool Handle is correct and matches 804 the Pool Handle sent in its earlier Registration. If the Pool 805 Handle does not match silently discard the message. 807 KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: 809 KA2.1) Filling in the Pool Handle Parameter with the PE's Pool 810 Handle. 812 KA2.2) Fill in the PE Identifier that was used with this PE for 813 registration. 815 KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the 816 appropriate SCTP association for that ENRP server. 818 KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the 819 new home ENRP server. 821 3.5 Reporting unreachable endpoints 823 Occasionally an ASAP endpoint may realize that a PE is unreachable. 824 This may occur by a specific SCTP error realized by the ASAP endpoint 825 or via a ASAP user report via the Transport.Failure Primitive 826 (Section 4.9.2). In either case the ASAP endpoint SHOULD report the 827 unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to 828 its home ENRP server. The Endpoint should fill in the Pool Handle 829 and PE identifier of the unreachable endpoint. If the sender is a PE 830 the message MUST be sent via SCTP to the Endpoints Home ENRP server. 832 Note: when processing a Transport.Failure Primitive (Section 4.9.2) 833 the ASAP endpoint MUST NOT send a unreachable report unless the ASAP 834 endpoint as sent at least one message to the PE specified by the 835 primitive. 837 3.6 ENRP server hunt procedures 839 Each PU and PE manages a list of transport addresses of ENRP servers. 841 If the multicast capabilities are used an ENRP server MUST send 842 periodically every T6-Serverannounce a SERVER_ANNOUNE message 843 (Section 2.2.10) including all the transport addresses available for 844 ASAP communication to the multicast channel. 846 If a SERVER_ANNOUNCE message is received by a PU or PE it SHOULD 847 insert all new included transport address in its list of ENRP server 848 addresses and start a T7-ENRPoutdate timer for each address. For all 849 already known addresses the T7-ENRPoutdate timers MUST be restarted. 850 If no transport parameters are included in the SERVER_ANNOUNCE 851 message the source IP address and the IANA registered ASAP port 852 number are used instead. It is also assumed that the transport 853 protocol used is SCTP. If a T7-ENRP timer for a transport address 854 expires the corresponding address is deleted from the list of 855 transport addresses. 857 If no multicast capabilities are used each PU and PE MUST have a 858 configured list of transport addresses of ENRP servers. 860 At its startup, or when it fails to send to (i.e., timed-out on a 861 service request) with its current home ENRP server, a PE or PU shall 862 establish its Home ENRP server, i.e. setup a TCP connection or SCTP 863 association with an ENRP server. 865 To establish a new association or connection the following rules MUST 866 be followed: 868 SH1) The PE or PU SHOULD try to establish an association or 869 connection with no more than three ENRP server addresses. An 870 endpoint MUST NOT try to establish more than three association or 871 connections at any single time. 873 SH2) The endpoint shall start a T5-Serverhunt timer. 875 SH3) If the endpoint establishes an association or connection it MUST 876 stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the 877 T5-Serverhunt value to its initial value and then proceed to step 878 SH6. 880 SH4) If an association or connection establishment fails the endpoint 881 SHOULD try to establish an association or connection by using a 882 different transport address. 884 SH5) If the T5-Serverhunt timer expires the following should be 885 performed: 887 SH5.1) The endpoint MUST double the value of the T5-Serverhunt 888 timer. 890 SH5.2) The endpoint SHOULD stop the establishment of associations 891 and connections. 893 SH5.2) The endpoint SHOULD repeat trying to establish an 894 association or connection by proceeding to step SH1. It SHOULD 895 attempt to select a different set of transport addresses to 896 connect to. 898 SH6) The PE or PU shall pick one of the ENRP servers that it was able 899 to establish an association or connection with, and send all its 900 subsequent the namespace service requests to this new home ENRP 901 server. 903 3.7 Handle ASAP to ENRP Communication Failures 905 Three types of failure may occur when the ASAP endpoint at an 906 endpoint tries to communicate with the ENRP server: 908 A) SCTP send failure 910 B) T1-ENRPrequest timer expiration 912 C) Registration failure 914 Registration failure is discussed in Section 3.1 916 3.7.1 SCTP Send Failure 918 This indicates that the SCTP layer failed to deliver a message sent 919 to the ENRP server. In other words, the ENRP server is currently 920 unreachable. 922 In such a case, the ASAP endpoint should not re-send the failed 923 message. Instead, it should discard the failed message and start the 924 ENRP server hunt procedure as described in Section 3.6 926 3.7.2 T1-ENRPrequest Timer Expiration 928 When a T1-ENRPrequest timer expires, the ASAP should re-send the 929 original request to the ENRP server and re-start the T1-ENRPrequest 930 timer. In parallel, a SERVER_HUNT message should be issued per 931 Section 3.6 933 This should be repeated up to 'max-request-retransmit' times. After 934 that, an Error.Report notification should be generated to inform the 935 ASAP user and the ENRP request message associated with the timer 936 should be discarded. Note that if an alternate ENRP server responds 937 the ASAP endpoint SHOULD adopt the responding ENRP server as its new 938 "home" server and resend the request to the new "home" server. 940 3.8 Cookie handling procedures 942 Whenever a PE wants and a control channel exists it can send a Cookie 943 Message to the PU via the control channel. The ASAP layer at the PU 944 stores the Cookie parameter and discards an older one if it is 945 present. 947 If the ASAP layer detects a failure and initiates a failover to a 948 different PE, the ASAP layer sends the last received Cookie parameter 949 in a Cookie Echo message to the new PE. The upper layer may be 950 involved in the failover procedure. 952 This cookie mechanism can be used as a simple method for state 953 sharing. Therefore a cookie should be signed by the sending PE and 954 this should be verified by the receiving PE. The details of this are 955 out of scope of this document. It is only important that the PU 956 stores always the last received Cookie Parameter and sends that back 957 unmodified in case of a PE failure. 959 3.9 Business Card handling procedures 961 When communication begins between a PU and a PE (i.e. the first 962 message is sent from the PU to the PE) the ASAP layer in the PU 963 SHOULD send a Business card IF the sender is also registered as a PE. 964 A PE may also send back to a PU a business card as well. A Bussiness 965 card MUST NOT be sent if a control channel does NOT exist between the 966 PU and PE. After communication as been established between a PE and 967 PU at any time either entity may update its failover distribution by 968 sending a new Business Card. 970 The business card serves two purposes (for both endpoints PU and PE). 971 First it lists the endpoints pool handle. For a PU contacting a PE 972 this is essential so that the PE may also gain the full benefits of 973 ASAP if the PU is also a PE. Secondly the business card tells the 974 receiver a failover order that is recommended to follow. This may 975 facilitate rendouvous between PE's as well as some control of load 976 redistribution upon the failure of any given PE. 978 Upon receipt of a Business Card Message (see Section 2.2.13) the 979 receiver SHOULD: 981 BC1) Unpack the business card, and if no entry exists in the 982 translation cache and one exists, populate the new Pool Handle 983 into the cache and request a NAME.RESOLUTION of the pool handle. 985 BC2) Create a list for this PE of prefered failover order so that in 986 the event of a failure the prefered list will be used to guide the 987 ASAP endpoint in the selection of an alternate PE. 989 3.10 Data Channel Contact Message 991 At the beginning of communication between a PE and a PU, a PE may 992 send this message to info the PU what transport is to be used for 993 Data. This message SHOULD only be sent at initial contact between a 994 PE and a PU. 996 4. The ASAP Interfaces 998 This chapter will focus primarily on the primitives and notifications 999 that form the interface between the ASAP-user and ASAP and that 1000 between ASAP and its lower layer transport protocol (e.g., SCTP). 1002 An ASAP User passes primitives to the ASAP sub-layer to request 1003 certain actions. Upon the completion of those actions or upon the 1004 detection of certain events, the ASAP will notify the ASAP user. 1006 4.1 Registration.Request Primitive 1008 Format: registration.request(poolHandle, 1009 User Transport parameter(s)) 1011 The poolHandle parameter contains a NULL terminated ASCII string of 1012 fixed length. The optional User Transport parameter(s) indicate 1013 specific transport parameters and types to register with. If this 1014 optional parameter is left off, then the SCTP endpoint used to 1015 communicate with the ENRP server is used as the default User 1016 Transport parameter. Note that any IP address contained within a 1017 User Transport parameter MUST be a bound IP address in the SCTP 1018 endpoint used to communicate with the ENRP server. 1020 The ASAP user invokes this primitive to add itself to the namespace, 1021 thus becoming a Pool Element of a pool. The ASAP user must register 1022 itself with the ENRP server by using this primitive before other ASAP 1023 users using the namespace can send message(s) to this ASAP user by 1024 Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3). 1026 In response to the registration primitive, the ASAP endpoint will 1027 send a REGISTRATION message to the home ENRP server (See Section 1028 2.2.1 and Section 3.1), and start a T2-registration timer. 1030 4.2 Deregistration.Request Primitive 1032 Format: deregistration.request(poolHandle) 1034 The ASAP PE invokes this primitive to remove itself from the Server 1035 Pool. This should be used as a part of the graceful shutdown process 1036 by the application. 1038 A DEREGISTRATION message will be sent by ASAP endpoint to the home 1039 ENRP server (see Section 2.2.2 and Section 3.2). 1041 4.3 Cache.Populate.Request Primitive 1043 Format: cache.populate.request([Pool-Handle | 1044 Pool-Element-Handle]) 1046 If the address type is a Pool handle and a local name translation 1047 cache exists, the ASAP endpoint should initiate a mapping information 1048 query by sending a NAME.RESOLUTION message on the Pool handle and 1049 update it local cache when the response comes back from the ENRP 1050 server. 1052 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 1053 from the Pool-Element-Handle and the NAME.RESOLUTION message is sent 1054 to the ENRP server for resolution. When the response message returns 1055 from the ENRP server the local cache is updated. 1057 Note that if the ASAP service does NOT support a local cache this 1058 primitive performs NO action. 1060 4.4 Cache.Purge.Request Primitive 1062 Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) 1064 If the user passes a Pool handle and local name translation cache 1065 exists, the ASAP endpoint should remove the mapping information on 1066 the Pool handle from its local cache. If the user passes a 1067 Pool-Element-Handle then the Pool handle within is used for the 1068 cache.purge.request. 1070 Note that if the ASAP service does NOT support a local cache this 1071 primitive performs NO action. 1073 4.5 Data.Send.Request Primitive 1075 Format: data.send.request(destinationAddress, typeOfAddress, 1076 message, sizeOfMessage, Options); 1078 This primitive requests ASAP to send a message to some specified Pool 1079 or Pool Element within the current Operational scope. 1081 Depending on the address type used for the send request, the senders 1082 ASAP endpoint may perform address translation and Pool Element 1083 selection before sending the message out. This also MAY dictate the 1084 creation of a local transport endpoint in order to meet the required 1085 transport type. 1087 The data.send.request primitive can take different forms of address 1088 types as described in the following sections. 1090 4.5.1 Sending to a Pool Handle 1092 In this case the destinationAddress and typeOfAddress together 1093 indicates a pool handle. 1095 This is the simplest form of send.data.request primitive. By 1096 default, this directs ASAP to send the message to one of the Pool 1097 Elements in the specified pool. 1099 Before sending the message out to the pool, the senders ASAP endpoint 1100 MUST first perform a pool handle to address translation. It may also 1101 need to perform Pool Element selection if multiple Pool Elements 1102 exist in the pool. 1104 If the senders ASAP implementation does not support a local cache of 1105 the mapping information or if it does not have the mapping 1106 information on the pool in its local cache, it will transmit a 1107 NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the 1108 current home ENRP server, and MUST hold the outbound message in queue 1109 while awaiting the response from the ENRP server (any further send 1110 request to this pool before the ENRP server responds SHOULD also be 1111 queued). 1113 Once the necessary mapping information arrives from the ENRP server, 1114 the senders ASAP will: 1116 A) map the pool handle into a list of transport addresses of the 1117 destination PE(s), 1119 B) if multiple PEs exist in the pool, ASAP will choose one of them 1120 and transmit the message to it. In that case, the choice of the 1121 PE is made by ASAP endpoint of the sender based on the server 1122 pooling policy as discussed in Section 4.5.2 1124 C) Optionally create any transport endpoint that may be needed to 1125 communicate with the PE selected. 1127 D) if no transport association or connection exists towards the 1128 destination PE, ASAP will establish any needed transport state, 1130 E) send out the queued message(s) to the appropriate transport 1131 connection using the appropriate send mechanism (e.g. for SCTP 1132 the SEND primitive in RFC2960 [4] would be used), and, 1134 F) if the local cache is implemented, append/update the local cache 1135 with the mapping information received in the ENRP server's 1136 response. Also, record the local transport information (e.g. the 1137 SCTP association id) if any new transport state was created. 1139 For more on the ENRP server request procedures see ENRP [6]. 1141 Optionally, the ASAP endpoint of the sender may return a Pool Element 1142 handle of the selected PE to the application after sending the 1143 message. This PE handle can then be used for future transmissions to 1144 that same PE (see Section 4.5.3). 1146 Section 3.7 defines the fail-over procedures for cases where the 1147 selected PE is found unreachable. 1149 4.5.2 Pool Element Selection 1151 Each time an ASAP user sends a message to a pool that contains more 1152 than one PE, the senders ASAP endpoint must select one of the PEs in 1153 the pool as the receiver of the current message. The selection is 1154 done according to the current server pooling policy of the pool to 1155 which the message is sent. 1157 Note, no selection is needed if the ASAP_SEND_TOALL option is set 1158 (see Section 4.5.5). 1160 Together with the server pooling policy, each PE can also specify a 1161 Policy Value for itself at the registration time. The meaning of the 1162 policy value depends on the current server pooling policy of the 1163 group. A PE can also change its policy value whenever it desires, by 1164 re-registering itself with the namespace with a new policy value. 1165 Re-registration shall be done by simply sending another REGISTRATION 1166 to its home ENRP server (See Section 2.2.1). 1168 Four basic server pooling policies are defined in ASAP, namely the 1169 Round Robin, Least Used, Least Used Degrading and Weighted Round 1170 Robin. The following sections describes each of these policies. 1172 4.5.2.1 Round Robin Policy 1174 When a ASAP endpoint sends messages by Pool Handle and Round-Robin is 1175 the current policy of that Pool, the ASAP endpoint of the sender will 1176 select the receiver for each outbound message by round-Robining 1177 through all the registered PEs in that Pool, in an attempt to achieve 1178 an even distribution of outbound messages. Note that in a large 1179 server pool, the ENRP server MAY NOT send back all PEs to the ASAP 1180 client. In this case the client or PU will be performing a round 1181 robin policy on a subset of the entire Pool. 1183 4.5.2.2 Least Used Policy 1185 When the destination Pool is under the Least Used server pooling 1186 policy, the ASAP endpoint of the message sender will select the PE 1187 that has the lowest policy value in the group as the receiver of the 1188 current message. If more than one PE from the group share the same 1189 lowest policy value, the selection will be done round Robin amongst 1190 those PEs. 1192 It is important to note that this policy means that the same PE will 1193 be always selected as the message receiver by the sender until the 1194 load control information of the pool is updated and changed in the 1195 local cache of the sender (via a cache update see Section 3.3). 1197 4.5.2.3 Least Used with Degradation Policy 1199 This policy is the same as the Least Used policy with the exception 1200 that, each time the PE with the lowest policy value is selected from 1201 the Pool as the receiver of the current message, its policy value is 1202 incremented, and thus it may no longer be the lowest value in the 1203 Pool. 1205 This provides a degradation of the policy towards round Robin policy 1206 over time. As with the Least Used policy, every local cache update 1207 at the sender will bring the policy back to Least Used with 1208 Degradation. 1210 4.5.2.4 Weighted Round Robin Policy 1212 [TBD] 1214 4.5.3 Sending to a Pool Element Handle 1216 In this case the destinationAddress and typeOfAddress together 1217 indicate an ASAP Pool Element handle. 1219 This requests the ASAP endpoint to deliver the message to the PE 1220 identified by the Pool Element handle. 1222 The Pool Element handle should contain the Pool Handle and a 1223 destination transport address of the destination PE or the Pool 1224 Handle and the transport type. Other implementation dependant 1225 elements may also be cached in a Pool Element handle. 1227 The ASAP endpoint shall use the transport address and transport type 1228 to identify the endpoint to communicate with. If no communication 1229 state exists with the peer endpoint (and is required by the transport 1230 protocol) the ASAP endpoint MAY setup the needed state and then 1231 invoke the SEND primitive for the particular transport protocol to 1232 send the message to the PE. 1234 In addition, if a local translation cache is supported the endpoint 1235 will: 1237 A) send out the message to the transport address (or association id) 1238 designated by the PE handle. 1240 B) determine if the Pool Handle is in the local cache. 1242 If it is NOT, the endpoint will: 1244 i) ask the home ENRP server for name resolution on pool handle by 1245 sending a NAME.RESOLUTION message (see Section 2.2.5), and 1247 ii) use the response to update the local cache. 1249 If the pool handle is in the cache, the endpoint will only 1250 update the pool handle if the cache is stale. A stale cache is 1251 indicated by it being older than the protocol parameter 1252 'stale.cache.value' (see Section 5.2). 1254 Section 3.5 and Section 4.9 defines the fail-over procedures for 1255 cases where the PE pointed to by the Pool Element handle is found 1256 unreachable. 1258 Optionally, the ASAP endpoint may return the actual Pool Element 1259 handle to which the message was sent (this may be different from the 1260 Pool Element handle specified when the primitive is invoked, due to 1261 the possibility of automatic fail-over). 1263 4.5.4 Send by Transport Address 1265 In this case the destinationAddress and typeOfAddress together 1266 indicate a transport address and transport type. 1268 This directs the senders ASAP endpoint to send the message out to the 1269 specified transport address. 1271 No endpoint fail-over is support when this form of send request is 1272 used. This form of send request effectively by-passes the ASAP 1273 endpoint. 1275 4.5.5 Message Delivery Options 1277 The Options parameter passed in the various forms of the above 1278 data.send.request primitive gives directions to the senders ASAP 1279 endpoint on special handling of the message delivery. 1281 The value of the Options parameter is generated by bit-wise "OR"ing 1282 of the following pre-defined constants: 1284 ASAP_USE_DEFAULT: 0x0000 Use default setting. 1286 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 1287 case where the first selected PE or the PE pointed to by the PE 1288 handle is found unreachable, the sender's ASAP endpoint SHOULD 1289 re-select an alternate PE from the same pool if one exists, and 1290 silently re-send the message to this newly selected endpoint. 1292 Note that this is a best-effort service. Applications should be 1293 aware that messages can be lost during the failover process, even 1294 if the underlying transport supports retrieval of unacknowledged 1295 data (e.g. SCTP) (Example: messages acknowledged by the SCTP 1296 layer at a PE, but not yet read by the PE when a PE failure 1297 occurs.) In the case where the underlying transport does not 1298 support such retrieval (e.g. TCP), any data already submitted by 1299 ASAP to the transport layer MAY be lost upon failover. 1301 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP 1302 endpoint from re-sending the message to any alternate PE in case 1303 that the first selected PE or the PE pointed to by the PE handle 1304 is found unreachable. Instead, the senders ASAP endpoint shall 1305 notify its upper layer about the unreachability with an 1306 Error.Report and return any unsent data. 1308 ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 1309 endpoint to send the message to the same PE in the pool that the 1310 previous message destined to this pool was sent to. 1312 ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option 1313 directs the senders ASAP endpoint to send a copy of the message to 1314 all the PEs, except for the sender itself if the sender is a PE, 1315 in that pool. 1317 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination 1318 with ASAP_SEND_TO_ALL option. It permits the senders ASAP 1319 endpoint also deliver a copy of the message to itself if the 1320 sender is a PE of the pool (i.e., loop-back). 1322 ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to 1323 send the current message using un-ordered delivery (note the 1324 underlying transport must support un-ordered delivery for this 1325 option to be effective). 1327 4.6 Data.Received Notification 1329 Format: data.received(messageReceived, sizeOfMessage, senderAddress, 1330 typeOfAddress) 1332 When a new user message is received, the ASAP endpoint of the 1333 receiver uses this notification to pass the message to its upper 1334 layer. 1336 Along with the message being passed, the ASAP endpoint of the 1337 receiver should also indicate to its upper layer the message senders 1338 address. The senders address can be in the form of either an SCTP 1339 association id, TCP transport address, UDP transport address, or a 1340 ASAP Pool Element handle. 1342 A) If the name translation local cache is implemented at the 1343 receiver's ASAP endpoint, a reverse mapping from the senders IP 1344 address to the pool handle should be performed and if the mapping 1345 is successful, the senders ASAP Pool Element handle should be 1346 constructed and passed in the senderAddress field. 1348 B) If there is no local cache or the reverse mapping is not 1349 successful, the SCTP association id or other transport specific 1350 identification (if SCTP is not being used) should be passed in the 1351 senderAddress field. 1353 4.7 Error.Report Notification 1355 Format: error.report(destinationAddress, typeOfAddress, 1356 failedMessage, sizeOfMessage) 1358 An error.report should be generated to notify the ASAP user about 1359 failed message delivery as well as other abnormalities. 1361 The destinationAddress and typeOfAddress together indicates to whom 1362 the message was originally sent. The address type can be either a 1363 ASAP Pool Element handle, association id, or a transport address. 1365 The original message (or the first portion of it if the message is 1366 too big) and its size should be passed in the failedMessage and 1367 sizeOfMessage fields, respectively. 1369 4.8 Examples 1371 These examples assume an underlying SCTP transport between the PE and 1372 PU. Other transports are possible but SCTP is utilized in the 1373 examples for illustrative purposes. Note that all communication 1374 between PU and ENRP server and PE and ENRP servers would be using 1375 SCTP. 1377 4.8.1 Send to a New Pool 1379 This example shows the event sequence when a Pool User sends the 1380 message "hello" to a pool which is not in the local translation cache 1381 (assuming local caching is supported). 1383 ENRP Server PU new-name:PEx 1385 | | | 1386 | +---+ | 1387 | | 1 | | 1388 | 2. NAME_RESOLUTION +---+ | 1389 |<-------------------------------| | 1390 | +---+ | 1391 | | 3 | | 1392 | 4. NAME_RESOLUTION_REPONSE +---+ | 1393 |------------------------------->| | 1394 | +---+ | 1395 | | 5 | | 1396 | +---+ 6. "hello1" | 1397 | |---------------->| 1398 | | | 1400 1) The user at PU invokes: 1402 data.send.request("new-name", name-type, "hello1", 6, 0); 1404 The ASAP endpoint, in response, looks up the pool "new-name" in 1405 its local cache but fails to find it. 1407 2) The ASAP endpoint of PU queues the message, and sends a 1408 NAME_RESOLUTION request to the ENRP server asking for all 1409 information about pool "new-name". 1411 3) A T1-ENRPrequest timer is started while the ASAP endpoint is 1412 waiting for the response from the ENRP server. 1414 4) The ENRP Server responds to the query with a 1415 NAME_RESOLUTION_REPONSE message that contains all the information 1416 about pool "new-name". 1418 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 1419 cache with information on pool "new-name". 1421 6) Based on the server pooling policy of pool "new-name", ASAP at PU 1422 selects the destination PE (PEx), sets up, if necessary, an SCTP 1423 association towards PEx (explicitly or implicitly), and send out 1424 the queued "hello1" user message. 1426 4.8.2 Send to a Cached Pool Handle 1428 This shows the event sequence when the ASAP user PU sends another 1429 message to the pool "new-name" after what happened in Section 4.8.1. 1431 ENRP Server PU new-name:PEx 1433 | | | 1434 | +---+ | 1435 | | 1 | | 1436 | +---+ 2. "hello2" | 1437 | |---------------->| 1438 | | | 1440 1) The user at PU invokes: 1442 pdata.send.request("new-name", name-type, "hello2", 6, 0); 1444 The ASAP endpoint, in response, looks up the pool "new-name" in 1445 its local cache and find the mapping information. 1447 2) Based on the server pooling policy of "new-name", ASAP at PU 1448 selects the PE (assume EPx is selected again), and sends out 1449 "hello2" message (assume the SCTP association is already set up). 1451 4.9 PE send failure 1453 When the ASAP endpoint in a PE or PU attempts to send a message to a 1454 PE and fails the failed sender will report the event as described in 1455 Section 3.5 . 1457 Additional primitive are also defined in this section to support 1458 those user applications that do not wish to use ASAP as the actual 1459 transport. 1461 4.9.1 Translation.Request Primitive 1463 Format: translation.request(Pool-Handle) 1465 If the address type is a Pool handle and a local name translation 1466 cache exists, the ASAP endpoint should look within its translation 1467 cache and return the current known transport types, ports and 1468 addresses to the caller. 1470 If the Pool handle does not exist in the local name cache or no name 1471 cache exists, the ASAP endpoint will send a NAME.RESOLUTION request 1472 using the Pool-Handle. Upon completion of the name resolution, the 1473 ASAP endpoint should populate the local name cache (if a local name 1474 cache is supported) and return the transport types, ports and 1475 addresses to the caller. 1477 4.9.2 Transport.Failure Primitive 1479 Format: transport.failure(Pool-Handle, Transport-address) 1481 If an external user encounters a failure in sending to a PE and is 1482 NOT using ASAP it can use this primitive to report the failure to the 1483 ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" 1484 ENRP server in response to this primitive. Note ASAP SHOULD NOT send 1485 a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous 1486 request to send data to the PE. 1488 5. Variables, Timers, and Thresholds 1490 The following is a summary of the variables, timers, and pre-set 1491 protocol constants used in ASAP. 1493 5.1 Timers 1495 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1496 the ENRP server (providing application information is queued). 1497 Normally set to 15 seconds. 1499 T2-registration - A timer started when sending a registration request 1500 to the home ENRP server, normally set to 30 seconds. 1502 T3-deregistration - A timer started when sending a deregistration 1503 request to the home ENRP server, normally set to 30 seconds. 1505 T4-reregistration - This timer is started after successful 1506 registration into the ASAP name space and is used to cause a 1507 re-registration at a periodic interval. This timer is normally 1508 set to 10 minutes or 20 seconds less than the Life Timer parameter 1509 used in the registration request (whichever is less). 1511 T5-Serverhunt - This timer is used during the ENRP server hunt 1512 procedure and is normally set to 120 seconds. 1514 T6-Serverannounce - This timer gives the time between the sending of 1515 consequetive SERVER_ANNOUNCE messages. It is normally set to 1 1516 second. 1518 T7-ENRPoutdate - This timer gives the time a server announcement is 1519 valid. It is normally set to 5 seconds. 1521 5.2 Thresholds and Variables 1523 max-reg-attempt - The maximum number of registration attempts to be 1524 made before a server hunt is issued. 1526 max-request-retransmit - The maximum number of attempts to be made 1527 when requesting information from the local ENRP server before a 1528 server hunt is issued. 1530 stale.cache.value - A threshold variable that indicates how long a 1531 cache entry is valid for. 1533 6. Security Considerations 1535 Due to varying requirements and multiple use cases of Rserpool, we 1536 point out two basic security protocols, IPsec and TLS. We 1537 specifically do not discuss whether one security protocol would be 1538 preferred over the other. This choice will be made by designers and 1539 network architects based on system requirements. 1541 For networks that demand IPsec security, implementations MUST support 1542 SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below 1543 RSerPool. Therefore, if IPsec is used for securing Rserpool, no 1544 changes or special considerations need to be made to Rserpool to 1545 secure the protocol. 1547 For networks that cannot or do not wish to use IPsec and prefer 1548 instead TLS, implementations MUST support TLS with SCTP as described 1549 in RFC3436 [8] or TLS over TCP as described in RFC2246 [3] When using 1550 TLS/SCTP we must ensure that RSerPool does not use any features of 1551 SCTP that are not available to an TLS/SCTP user. This is not a 1552 difficult technical problem, but simply a requirement. When 1553 describing an API of the RSerPool lower layer we have also to take 1554 into account the differences between TLS and SCTP. This is also not 1555 difficult, but it is in contrast to the IPsec solution which is 1556 transparently layered below Rserpool. 1558 Support for security is required for the ENRP server and the PEs. 1559 Security support for the Rserpool end user is optional. Note that 1560 the end user implementation contains a piece of the Rserpool protocol 1561 -- namely ASAP -- whereby the pool handle is passed for name 1562 resolution to the ENRP server and IP address(es) are returned. 1564 The argument for optional end user security is as follows: If the 1565 user doesn't require security protection for example, against 1566 eavesdropping for the request for pool handle resolution and 1567 response, then they are free to make that choice. However, if the 1568 end user does require security, they are guaranteed to get it due to 1569 the requirement for security support for the ENRP server. It is also 1570 possible for the ENRP server to reject an unsecured request from the 1571 user due to its security policy in the case that it requires 1572 enforcement of strong security. But this will be determined by the 1573 security requirements of the individual network design. 1575 7. Acknowledgments 1577 The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon 1578 Ong, and many others for their invaluable comments. 1580 Normative References 1582 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1583 9, RFC 2026, October 1996. 1585 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1586 Levels", BCP 14, RFC 2119, March 1997. 1588 [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 1589 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1590 1999. 1592 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1593 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1594 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1596 [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1597 Server Access Protocol and Endpoint Name Resolution Protocol 1598 Common Parameters", draft-ietf-rserpool-common-param-01 (work in 1599 progress), June 2002. 1601 [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution 1602 Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in 1603 progress), May 2002. 1605 [7] Bellovin, S., "On the Use of SCTP with IPsec", 1606 draft-ietf-ipsec-sctp-04 (work in progress), October 2002. 1608 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1609 3436, December 2002. 1611 Informational References (non-normative) 1613 [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1614 Recommendations for Security", RFC 1750, December 1994. 1616 Authors' Addresses 1618 Randall R. Stewart 1619 Cisco Systems, Inc. 1620 8725 West Higgins Road 1621 Suite 300 1622 Chicago, IL 60631 1623 USA 1625 Phone: +1-815-477-2127 1626 EMail: rrs@cisco.com 1628 Qiaobing Xie 1629 Motorola, Inc. 1630 1501 W. Shure Drive, #2309 1631 Arlington Heights, IL 60004 1632 USA 1634 Phone: +1-847-632-3028 1635 EMail: qxie1@email.mot.com 1637 Maureen Stillman 1638 Nokia 1639 127 W. State Street 1640 Ithaca, NY 14850 1641 USA 1643 Phone: +1-607-273-0724 1644 EMail: maureen.stillman@nokia.com 1646 Michael Tuexen 1648 Germany 1650 Phone: 1651 EMail: tuexen@fh-muenster.de 1653 Intellectual Property Statement 1655 The IETF takes no position regarding the validity or scope of any 1656 intellectual property or other rights that might be claimed to 1657 pertain to the implementation or use of the technology described in 1658 this document or the extent to which any license under such rights 1659 might or might not be available; neither does it represent that it 1660 has made any effort to identify any such rights. Information on the 1661 IETF's procedures with respect to rights in standards-track and 1662 standards-related documentation can be found in BCP-11. Copies of 1663 claims of rights made available for publication and any assurances of 1664 licenses to be made available, or the result of an attempt made to 1665 obtain a general license or permission for the use of such 1666 proprietary rights by implementors or users of this specification can 1667 be obtained from the IETF Secretariat. 1669 The IETF invites any interested party to bring to its attention any 1670 copyrights, patents or patent applications, or other proprietary 1671 rights which may cover technology that may be required to practice 1672 this standard. Please address the information to the IETF Executive 1673 Director. 1675 Full Copyright Statement 1677 Copyright (C) The Internet Society (2003). All Rights Reserved. 1679 This document and translations of it may be copied and furnished to 1680 others, and derivative works that comment on or otherwise explain it 1681 or assist in its implementation may be prepared, copied, published 1682 and distributed, in whole or in part, without restriction of any 1683 kind, provided that the above copyright notice and this paragraph are 1684 included on all such copies and derivative works. However, this 1685 document itself may not be modified in any way, such as by removing 1686 the copyright notice or references to the Internet Society or other 1687 Internet organizations, except as needed for the purpose of 1688 developing Internet standards in which case the procedures for 1689 copyrights defined in the Internet Standards process must be 1690 followed, or as required to translate it into languages other than 1691 English. 1693 The limited permissions granted above are perpetual and will not be 1694 revoked by the Internet Society or its successors or assignees. 1696 This document and the information contained herein is provided on an 1697 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1698 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1699 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1700 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1701 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1703 Acknowledgement 1705 Funding for the RFC Editor function is currently provided by the 1706 Internet Society.