idnits 2.17.1 draft-ietf-rserpool-asap-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1759. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([4], [7]), 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 an 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 7, 2006) is 6652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '10' is mentioned on line 1696, but not defined -- Looks like a reference, but probably isn't: 'TBD' on line 1214 == Unused Reference: '1' is defined on line 1659, 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-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '5') == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '6') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '7') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-05 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '8') Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 11, 2006 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 February 7, 2006 12 Aggregate Server Access Protocol (ASAP) 13 draft-ietf-rserpool-asap-13.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 11, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Aggregate Server Access Protocol (ASAP) in conjunction with the 47 Endpoint Handlespace Redundancy Protocol (ENRP) [7] provides a high 48 availability data transfer mechanism over IP networks. ASAP uses a 49 handle-based addressing model which isolates a logical communication 50 endpoint from its IP address(es), thus effectively eliminating the 51 binding between the communication endpoint and its physical IP 52 address(es) which normally constitutes a single point of failure. 54 In addition, ASAP defines each logical communication destination as a 55 pool, providing full transparent support for server-pooling and load 56 sharing. It also allows dynamic system scalability - members of a 57 server pool can be added or removed at any time without interrupting 58 the service. 60 ASAP is designed to take full advantage of the network level 61 redundancy provided by the Stream Transmission Control Protocol 62 (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool 63 Elements (PE) and Pool Users (PU) MUST have an accompanying 64 transports mapping document. Note that ASAP messages passed between 65 PE's and ENRP servers MUST use SCTP. 67 The high availability server pooling is gained by combining two 68 protocols, namely ASAP and ENRP, in which ASAP provides the user 69 interface for pool handle to address translation, load sharing 70 management, and fault management while ENRP defines the high 71 availability pool handle translation service. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.2. Organization of this document . . . . . . . . . . . . . . 6 78 1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 79 1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 80 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 81 2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 82 2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 83 2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 84 2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 85 2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 86 2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 87 2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10 88 2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 89 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 11 90 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12 91 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13 92 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13 93 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 13 94 2.2.11. COOKIE message . . . . . . . . . . . . . . . . . . . . 14 95 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 14 96 2.2.13. BUSINESS_CARD message . . . . . . . . . . . . . . . . 14 97 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 15 98 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16 100 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 101 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 18 102 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 103 3.5. Reporting unreachable endpoints . . . . . . . . . . . . . 20 104 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 20 105 3.7. Handle ASAP to ENRP Communication Failures . . . . . . . . 22 106 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 107 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 108 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 23 109 3.9. Business Card handling procedures . . . . . . . . . . . . 23 110 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 25 111 4.1. Registration.Request Primitive . . . . . . . . . . . . . . 25 112 4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 25 113 4.3. Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 114 4.4. Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 115 4.5. Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 116 4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 27 117 4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 28 118 4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 29 119 4.5.4. Send by Transport Address . . . . . . . . . . . . . . 30 120 4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 31 122 4.6. Data.Received Notification . . . . . . . . . . . . . . . . 32 123 4.7. Error.Report Notification . . . . . . . . . . . . . . . . 32 124 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 125 4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 33 126 4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 34 127 4.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 34 128 4.9.1. Translation.Request Primitive . . . . . . . . . . . . 35 129 4.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 35 130 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 36 131 5.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 5.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 133 5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 134 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 135 6.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38 136 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 137 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 138 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 139 8.2. Informational References (non-normative) . . . . . . . . . 41 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 141 Intellectual Property and Copyright Statements . . . . . . . . . . 43 143 1. Introduction 145 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7] 146 provides a high availability data transfer mechanism over IP 147 networks. ASAP uses a handle-based addressing model which isolates a 148 logical communication endpoint from its IP address(es), thus 149 effectively eliminating the binding between the communication 150 endpoint and its physical IP address(es) which normally constitutes a 151 single point of failure. 153 When multiple receiver instances exist under the same handle, a.k.a, 154 a server pool, ASAP will select one Pool Element (PE), based on the 155 current load sharing policy indicated by the server pool, and deliver 156 the message to the selected PE. 158 While delivering the message, ASAP monitors the reachability of the 159 selected PE. If it is found unreachable, before notifying the sender 160 of the failure, ASAP can automatically select another PE (if one 161 exists) under that pool and attempt to deliver the message to that 162 PE. In other words, ASAP is capable of transparent fail-over amongst 163 instances of a server pool. 165 ASAP uses the Endpoint Handlespace Redundancy Protocol (ENRP) to 166 provide a high availability pool handle space. ASAP is responsible 167 for the abstraction of the underlying transport technologies, load 168 distribution management, fault management, as well as the 169 presentation to the upper layer (i.e., the ASAP user) a unified 170 primitive interface. 172 When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP 173 can seamlessly incorporate the link-layer redundancy provided by the 174 SCTP. 176 This document defines the ASAP portion of the high availability 177 server pool. ASAP depends on the services of a high availability 178 pool handle database a.k.a. ENRP [7]. 180 1.1. Definitions 182 This document uses the following terms: 184 ASAP User: Either a PE or PU that uses ASAP. 186 Operational scope: See [6]; 187 Operational scope: See [6]; 189 Pool (or server pool): See [6]; 191 Pool handle: See [6]; 193 Pool element (PE): See [6]; 195 Pool user (PU): See [6]; 197 Pool element handle: See [6]; 199 ENRP handlespace (or handlespace): See [6]; 201 pool registrar: A server program running on a host that manages the 202 handle space collectively with its peer ENRP servers and replies 203 to the service requests from any Pool User or Pool Element. 205 Home ENRP server: The ENRP server to which a PE or PU currently 206 belongs. A PE MUST only have one home ENRP server at any given 207 time and both the PE and its home ENRP server MUST keep track of 208 this master/slave relationship between them. A PU SHOULD select 209 one of the available ENRP servers as its home ENRP server, but the 210 ENRP server does not need to know, nor does it need to keep track 211 of this relationship. 213 ENRP client channel: The communication channel through which an ASAP 214 User (either a PE or PU) requests ENRP handlespace service. The 215 client channel is usually defined by the transport address of the 216 home server and a well known port number. The channel MAY make 217 use of multi-cast or a named list of ENRP servers. 219 Network Byte Order: Most significant byte first, a.k.a Big Endian. 221 Transport address: A Transport Address is traditionally defined by 222 Network Layer address, Transport Layer protocol and Transport 223 Layer port number. In the case of SCTP running over IP, a 224 transport address is defined by the combination of an IP address 225 and an SCTP port number (where SCTP is the Transport protocol). 227 1.2. Organization of this document 229 Section 2 details ASAP message formats. In Section 3 we give the 230 detailed ASAP procedures for the ASAP implementer. And in Section 4 231 we give the details of the ASAP interface, focusing on the 232 communication primitives between the applications above ASAP and ASAP 233 itself, and the communications primitives between ASAP and SCTP (or 234 other transport layer). Also included in this discussion is relevant 235 timers and configurable parameters as appropriate. Section 5 236 provides threshold and protocol variables. 238 1.3. Scope of ASAP 240 The requirements for high availability and scalability do not imply 241 requirements on shared state and data. ASAP does not provide 242 transaction failover. If a host or application fails during 243 processing of a transaction this transaction may be lost. Some 244 services may provide a way to handle the failure, but this is not 245 guaranteed. ASAP MAY provide hooks to assist an application in 246 building a mechanism to share state but ASAP in itself will NOT share 247 any state. 249 1.3.1. Extent of the Handlespace 251 The scope of the ASAP/ENRP is NOT Internet wide. The handlespace is 252 neither hierarchical nor arbitrarily large like DNS. We propose a 253 flat peer-to-peer model. Pools of servers will exist in different 254 administrative domains. For example, suppose we want to use ASAP/ 255 ENRP. First, the PU may use DNS to contact an ENRP server. Suppose 256 a PU in North America wishes to contact the server pool in Japan 257 instead of North America. The PU would use DNS to get the list of IP 258 addresses of the Japanese server pool domain, that is, the ENRP 259 client channel in Japan. From there the PU would query the ENRP 260 server and then directly contact the PE(s) of interest. 262 1.4. Conventions 264 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 265 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 266 they appear in this document, are to be interpreted as described in 267 RFC2119 [2]. 269 2. Message Definitions 271 All messages as well as their fields described below shall be in 272 Network Byte Order during transmission. For fields with a length 273 bigger than 4 octets, a number in a pair of parentheses may follow 274 the field name to indicate the length of the field in number of 275 octets. 277 2.1. ASAP Parameter Formats 279 The basic message format and all parameter formats can be found in 280 ENRP-ASAP [5]. Note also that ALL ASAP messages exchanged between an 281 ENRP server and a PE MUST use SCTP as transport, while ASAP messages 282 exchanged between an ENRP server and a PU MUST use either SCTP or TCP 283 as transport. PE to PU data traffic MAY use any transport protocol 284 specified by the PE during registration. 286 2.2. ASAP Messages 288 This section details the individual messages used by ASAP. These 289 messages are composed of a standard message format found in Section 4 290 of ENRP-ASAP [5]. The parameter descriptions may also be found in 291 Section 3 of ENRP-ASAP [5]. 293 The following ASAP message types are defined in this section: 295 Type Message Name 296 ----- ------------------------- 297 0x00 - (reserved by IETF) 298 0x01 - ASAP_REGISTRATION 299 0x02 - ASAP_DEREGISTRATION 300 0x03 - ASAP_REGISTRATION_RESPONSE 301 0x04 - ASAP_DEREGISTRATION_RESPONSE 302 0x05 - ASAP_HANDLE_RESOLUTION 303 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 304 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 305 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 306 0x09 - ASAP_ENDPOINT_UNREACHABLE 307 0x0a - ASAP_SERVER_ANNOUNCE 308 0x0b - ASAP_COOKIE 309 0x0c - ASAP_COOKIE_ECHO 310 0x0d - ASAP_BUSINESS_CARD 311 0x0e - ASAP_ERROR 313 2.2.1. ASAP_REGISTRATION message 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 : Pool Handle Parameter : 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 : Pool Element Parameter : 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The pool handle parameter field specifies the handle to be 326 registered. The PE Parameter field MUST be filled in by the 327 registrant endpoint to declare its transport address, server pooling 328 policy and value, and other operational preferences. Note that the 329 ASAP_REGISTRATION message MUST use SCTP and the IP address(es) of the 330 PE registered within the Pool Element Parameter MUST be a subset of 331 the addresses of the SCTP association in respective of the transport 332 protocol registered by the PE. 334 2.2.2. ASAP_DEREGISTRATION message 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 : Pool Handle Parameter : 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 : PE Identifier Parameter : 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 346 The PE sending the ASAP_DEREGISTRATION shall fill in the pool handle 347 and the PE identifier parameter in order to allow the ENRP server to 348 verify the identity of the endpoint. Note that deregistration is NOT 349 allowed by proxy, in other words a PE may only deregister itself. 351 2.2.3. ASAP_REGISTRATION_RESPONSE message 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type = 0x03 |0|0|0|0|0|0|0|R| Message Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 : Pool Handle Parameter : 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 : PE Identifier Parameter : 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 : Operational Error (optional) : 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 R (Reject) flag 367 When set to '1', indicate that the ENRP server that sent this message 368 has rejected the registration. Otherwise, the registration is 369 granted. 371 Operational Error 373 This optional TLV parameter may be included if the registration was 374 rejected. This TLV, if present, indicates the cause of the 375 rejection. If the registration was successful this parameter is not 376 included. 378 2.2.4. ASAP_DEREGISTRATION_RESPONSE message 380 0 1 2 3 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 : Pool Handle Parameter : 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 : PE Identifier Parameter : 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 : Operational Error (optional) : 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Operational Error 394 This optional TLV parameter is included if an error occurred during 395 the deregistration process. If the deregistration was successful 396 this parameter is not included. 398 2.2.5. ASAP_HANDLE_RESOLUTION message 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 : Pool Handle Parameter : 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 This message is sent to a ENRP server to request translation of the 409 Pool Handle to a list of Pool Elements. If sent from a PE the SCTP 410 association used for registration SHOULD be used. 412 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type = 0x06 |0|0|0|0|0|0|0|0| Message Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 : Pool Handle Parameter : 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 : Overall PE Selection Policy (optional) : 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 : Pool Element Parameter 1 (optional) : 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 : ... : 426 : : 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 : Pool Element Parameter N (optional) : 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 : Operational Error (optional) : 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Overall PE Selection Policy: 435 This TLV is a PE selection policy parameter and can be present when 436 the response is positive. It indicates the overall selection policy 437 of the pool. If not present, round-robin is assumed. This TLV is 438 not present when the response is negative (i.e., a rejection). 440 Note, any load policy parameter inside the Pool Element Parameter (if 441 present) MUST be ignored, and MUST NOT be used to determine the 442 overall pool policy. 444 Pool Element Parameters 445 When the response is positive, an array of PE TLVs are included, 446 indicating the current PEs and their information in the named pool. 447 In a positive response, at least one PE TLV MUST be present. When 448 the response is negative, no PE TLVs are included. 450 Operational Error 452 The presence of this TLV indicates that the response is negative 453 (i.e., the handle resolution request was rejected by the ENRP 454 server). The cause code in this TLV (if present) will indicate the 455 reason the handle resolution request was rejected (e.g., the 456 requested pool handle was not found). 458 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message 460 0 1 2 3 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Server Identifier | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 : Pool Handle Parameter : 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 H (Home ENRP server) flag 472 When set to '1', indicate that the ENRP server that sends this 473 message want to be the home ENRP server of the receiver of this 474 message. 476 Server Identifier field indicates the sender ENRP server of the 477 message. 479 This message is sent to a PE by the ENRP server as a "health" check. 480 If the transport level Heart Beat mechanism is insufficient, this 481 adds heartbeat messages with the goal of determining health status at 482 ASAP level in a possibly more timely fashion. (The transport level 483 Heart Beat may sometimes be considered insufficient due to that time 484 outs are set for too long or heartbeats are not frequent enough, or, 485 that the transport level Heart Beat mechanism's coverage is limited 486 only to the transport level at the two ends.) 488 Using ASAP keepalive also has additional value to the reliability of 489 fault detection when SCTP stack is in the kernel. In such a case, 490 while SCTP level heartbeat monitors the end-to-end connectivity 491 between the two SCTP stacks, ASAP keepalive monitors the end-to-end 492 liveliness of the ASAP layer above it. 494 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 : Pool Handle Parameter : 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 : PE Identifier Parameter : 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 This message is sent by the PE to the ENRP server as an 507 acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message. 509 2.2.9. ASAP_ENDPOINT_UNREACHABLE message 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : Pool Handle Parameter : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 : PE Identifier Parameter : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 A PE or PU will send this message to an ENRP server to report the 522 unreachability of the specified PE. 524 2.2.10. ASAP_SERVER_ANNOUNCE message 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Server Identifier | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 : Transport param #1 : 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 : Transport param #2 : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 : : 538 : ..... : 539 : : 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 : Transport param #n : 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 This message is sent by an ENRP server such that PUs and PEs know the 546 transport layer information necessary to connect to the ENRP server. 547 The transport parameters are optional and only TCP and SCTP transport 548 parameters are allowed. Server Identifier field indicates the sender 549 ENRP server of the message. 551 2.2.11. COOKIE message 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 : Cookie Parameter : 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 This message is sent by a PE to a PU. It may only be sent when a 562 control channel exists between the PE and PU. 564 2.2.12. ASAP_COOKIE_ECHO message 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : Cookie Parameter : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 This message is sent by a PU to a PE in case of a failover. The 575 Cookie Parameter is one received latest from the failed PE. 577 2.2.13. BUSINESS_CARD message 579 This message is sent by a PU to a PE or from a PE to a PU. This 580 parameter MUST NOT be sent if a control channel does NOT exists 581 between the PE and PU. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 : Pool Handle Parameter : 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 : Pool Element Parameter-1 : 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 : .. : 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 : Pool Element Parameter-N : 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 The sender of this message lists both the Pool that the sender 598 belongs to and a preferred list of failover candidates. 600 2.2.14. ASAP_ERROR message 602 This message is used to report an operational error. Currently the 603 use of this message is undefined, it is reserved for future use 604 [Editors Note: we need to come up with concrete uses or get rid of 605 the message]. 607 0 1 2 3 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 : Operational Error Parameter : 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 3. Procedures 617 This section will focus on the methods and procedures used by an 618 internal ASAP endpoint. Appropriate timers and recovery actions for 619 failure detection and management are also discussed. 621 3.1. Registration 623 When a PE wishes to join its server pool it MUST use the procedures 624 outlined in this section to register. Often the registration will be 625 triggered by a user request primitive (discussed in Section 4.1). 626 The ASAP endpoint MUST register using an SCTP association between the 627 ASAP endpoint and the ENRP server. If the ASAP endpoint has not 628 established its Home ENRP server it MUST follow the procedures 629 specified in Section 3.6 to establish its Home ENRP server. 631 Once the ASAP endpoint has established its Home ENRP server the 632 following procedures MUST be followed to register: 634 R1) The SCTP endpoint used to communicate with the ENRP server MUST 635 be bound to all IP addresses that will be used by the PE 636 (irregardless of what protocol will be used to service user 637 requests to the PE). 639 R2) The ASAP endpoint MUST formulate an ASAP_REGISTRATION message as 640 defined in Section 2.2.1 In formulating the message the ASAP 641 endpoint MUST: 643 R2.1) Fill in the Pool Handle to specify which server pool the 644 ASAP endpoint wishes to join. 646 R2.2) Fill in a PE identifier using a good quality randomly 647 generated number (RFC1750 [10] provides some information on 648 randomness guidelines). 650 R2.3) Fill in the registration life time parameter with the number 651 of seconds that this registration is good for. Note a PE that 652 wishes to continue service MUST re-register after the 653 registration expires. 655 R2.4) Fill in a User Transport Parameter for the type of transport 656 and the data/control channel usage the PE is willing to 657 support. Note, to join an existing server pool, the PE MUST 658 follow the overall transport type and overall data/control 659 channel usage of the pool. Otherwise, the registration may be 660 rejected by the ENRP server. 662 R2.5) Fill in the preferred Member selection policy. 664 R2.6) PE does not need to fill in the ASAP transport parameter. 665 The ASAP transport TLV will be filled in and used by the home 666 ENRP server. 668 R3) Send the Registration request to the Home ENRP server using SCTP. 670 R4) Start a T2-registration timer. 672 If the T2-registration timer expires before receiving an 673 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 674 received from the SCTP layer, the ASAP endpoint shall start the 675 Server Hunt procedure (see Section 3.6) in an attempt to get service 676 from a different ENRP server. After establishing a new Home ENRP 677 server the ASAP endpoint SHOULD restart the registration procedure. 679 At the reception of the registration response, the ASAP endpoint MUST 680 stop the T2-Registration timer. If the response indicated success, 681 then the PE is now registered and will be considered an available 682 member of the server pool. If the registration response indicates a 683 failure, the ASAP endpoint must either re-attempt registration after 684 correcting the error or return a failure indication to the ASAP 685 endpoints upper layer. The ASAP endpoint MUST NOT re-attempt 686 registration without correcting the error condition. 688 At any time a registered PE MAY wish to re-register to either update 689 its member selection policy value or registration expiration time. 690 When re-registering the PE MUST use the same PE identifier. 692 After successful registration the PE MUST start a T4-reregistration 693 timer. At its expiration a re-registration SHOULD be made starting 694 at step R1 including (at completion) restarting the T4-reregistration 695 timer. 697 Note that an implementation SHOULD keep a record of the number of 698 registration attempts it makes in a local variable. If repeated 699 registration time-outs or failures occurs and the local count exceeds 700 the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the 701 error to its upper layer and stop attempting registration. 703 3.2. Deregistration 705 In the event the PE wishes to deregister from its server pool 706 (normally via an upper layer requests see Section 4.2) it SHOULD use 707 the following procedures. Note that an alternate method of 708 deregistration is to NOT re-register and to allow the registration 709 lift time to expire. 711 When deregistering the PE SHOULD use the same SCTP association with 712 its Home ENRP server that was used for registration. To deregister 713 the ASAP endpoint MUST take the following actions: 715 D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION 716 message ( Section 2.2.2) using the same Pool Handle parameter sent 717 during registration. 719 D2) Fill in the PE Identifier. The identifier MUST be the same one 720 used during registration. 722 D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server 723 using the SCTP association. 725 D4) Start a T3-Deregistration timer. 727 If the T3-Deregistration timer expires before receiving an 728 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 729 received from the SCTP layer, the ASAP endpoint shall start the 730 Server Hunt procedure (see Section 3.6) in an attempt to get service 731 from a different ENRP server. After establishing a new Home ENRP 732 server the ASAP endpoint SHOULD restart the deregistration procedure. 734 At the reception of the deregistration response, the ASAP endpoint 735 MUST stop the T3-deregistration timer. 737 Note that after a successful deregistration the PE MAY still receive 738 requests for some period of time. The PE MAY wish to still remain 739 active and service these requests or may wish to ignore these 740 requests and exit. 742 3.3. Handle resolution 744 At any time a PE or PU may wish to resolve a handle. This usually 745 will occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or 746 requests a cache population (Section 4.3) but may occur for other 747 reasons (e.g. the internal ASAP PE wishes to know its peers for 748 sending a message to all of them). When an Endpoint (PE or PU) 749 wishes to resolve a pool handle it MUST take the following actions: 751 NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with 752 the Pool Handle to be resolved. 754 NR2) If the endpoint does not have a Home ENRP server start the ENRP 755 Server Hunt procedures specified in Section 3.6 to obtain one. 756 Otherwise proceed to step NR3. 758 NR3) Send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server 759 using SCTP. 761 NR4) Start a T1-ENRPrequest timer. 763 If the T1-ENRPrequest timer expires before receiving a response 764 message, the ASAP endpoint SHOULD take the steps described in 765 Section 3.7.2. If a SEND.FAILURE notification is received from the 766 SCTP layer, the ASAP endpoint SHOULD start the Server Hunt procedure 767 (see Section 3.6) in an attempt to get service from a different ENRP 768 server. After establishing a new Home ENRP server the ASAP endpoint 769 SHOULD restart the handle resolution procedure. 771 At the reception of the response message (i.e., an 772 ASAP_HANDLE_RESOLUTION_RESPONSE) the endpoint MUST stop its T1- 773 ENRPrequest timer. After stopping the T1 timer the endpoint SHOULD 774 process the pool handle response as appropriate (e.g. populate a 775 local cache, give the response to the ASAP user, and/or use the 776 response to send the ASAP users message). 778 Note that some ASAP endpoints MAY use a cache to minimize the number 779 of handle resolutions made. If such a cache is used it SHOULD: 781 C1) Be consulted before requesting a handle resolution. 783 C2) Have a stale timeout time associated with the cache so that even 784 in the event of a cache-hit, if the cache is "stale" it will cause 785 a new handle resolution to be issued to update the cache. 787 C3) In the case of a "stale" cache the implementation may in parallel 788 request an update and answer the request or block the user and 789 wait for an updated cache before proceeding with the users 790 request. 792 C4) If the cache is NOT stale, the endpoint SHOULD NOT make a handle 793 resolution request but instead use the entry from the cache. 795 3.4. Endpoint keep alive 797 Periodically an ENRP server may choose to "audit" a PE. It does this 798 by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). 799 Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message the following 800 actions MUST be taken: 802 KA1) The PE must verify that the Pool Handle is correct and matches 803 the Pool Handle sent in its earlier ASAP_REGISTRATION. If the 804 Pool Handle does not match silently discard the message. 806 KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: 808 KA2.1) Filling in the Pool Handle Parameter with the PE's Pool 809 Handle. 811 KA2.2) Fill in the PE Identifier that was used with this PE for 812 registration. 814 KA2.3) Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the 815 appropriate SCTP association for that ENRP server. 817 KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE 818 message is set, adopt the sender of the 819 ASAP_ENDPOINT_KEEP_ALIVE message as the 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 an ASAP user report via the Transport.Failure Primitive 826 (Section 4.9.2). In either case the ASAP endpoint SHOULD report the 827 unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE 828 message to its home ENRP server. The Endpoint should fill in the 829 Pool Handle and PE identifier of the unreachable endpoint. If the 830 sender is a PE the message MUST be sent via SCTP to the Endpoints 831 Home ENRP server. Note: an ASAP endpoint MUST report No more than 832 once each time it encounters such an event. 834 Note: when processing a Transport.Failure Primitive (Section 4.9.2) 835 the ASAP endpoint MUST NOT send a unreachable report unless the ASAP 836 endpoint has sent at least one message to the PE specified by the 837 primitive. 839 3.6. ENRP server hunt procedures 841 Each PU and PE manages a list of transport addresses of ENRP servers. 843 If the multicast capabilities are used an ENRP server MUST send 844 periodically every T6-Serverannounce an ASAP_SERVER_ANNOUNCE message 845 (Section 2.2.10) including all the transport addresses available for 846 ASAP communication to the multicast channel. 848 If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE it 849 SHOULD insert all new included transport address in its list of ENRP 850 server addresses and start a T7-ENRPoutdate timer for each address. 851 For all already known addresses the T7-ENRPoutdate timers MUST be 852 restarted. If no transport parameters are included in the 853 ASAP_SERVER_ANNOUNCE message the source IP address and the IANA 854 registered ASAP port number are used instead. It is also assumed 855 that the transport protocol used is SCTP. If a T7-ENRP timer for a 856 transport address expires the corresponding address is deleted from 857 the list of transport addresses. 859 If no multicast capabilities are used each PU and PE MUST have a 860 configured list of transport addresses of ENRP servers. 862 At its startup, or when it fails to send to (i.e., timed-out on a 863 service request) with its current home ENRP server, a PE or PU shall 864 establish its Home ENRP server, i.e. setup a TCP connection or SCTP 865 association with an ENRP server. 867 To establish a new association or connection the following rules MUST 868 be followed: 870 SH1) The PE or PU SHOULD try to establish an association or 871 connection with no more than three ENRP server addresses. An 872 endpoint MUST NOT try to establish more than three association or 873 connections at any single time. 875 SH2) The endpoint shall start a T5-Serverhunt timer. 877 SH3) If the endpoint establishes an association or connection it MUST 878 stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the 879 T5-Serverhunt value to its initial value and then proceed to step 880 SH6. 882 SH4) If an association or connection establishment fails the endpoint 883 SHOULD try to establish an association or connection by using a 884 different transport address. 886 SH5) If the T5-Serverhunt timer expires the following should be 887 performed: 889 SH5.1) The endpoint MUST double the value of the T5-Serverhunt 890 timer. 892 SH5.2) The endpoint SHOULD stop the establishment of associations 893 and connections. 895 SH5.2) The endpoint SHOULD repeat trying to establish an 896 association or connection by proceeding to step SH1. It SHOULD 897 attempt to select a different set of transport addresses to 898 connect to. 900 SH6) The PE or PU shall pick one of the ENRP servers that it was able 901 to establish an association or connection with, and send all its 902 subsequent the handlespace service requests to this new home ENRP 903 server. 905 3.7. Handle ASAP to ENRP Communication Failures 907 Three types of failure may occur when the ASAP endpoint at an 908 endpoint tries to communicate with the ENRP server: 910 A) SCTP send failure 912 B) T1-ENRPrequest timer expiration 914 C) Registration failure 916 Registration failure is discussed in Section 3.1 918 3.7.1. SCTP Send Failure 920 This indicates that the SCTP layer failed to deliver a message sent 921 to the ENRP server. In other words, the ENRP server is currently 922 unreachable. 924 In such a case, the ASAP endpoint should not re-send the failed 925 message. Instead, it should discard the failed message and start the 926 ENRP server hunt procedure as described in Section 3.6 928 3.7.2. T1-ENRPrequest Timer Expiration 930 When a T1-ENRPrequest timer expires, the ASAP should re-send the 931 original request to the ENRP server and re-start the T1-ENRPrequest 932 timer. In parallel, the server hunt procedure should be started as 933 outlined in Section 3.6. 935 This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times. After 936 that, an Error.Report notification should be generated to inform the 937 ASAP user and the ENRP request message associated with the timer 938 should be discarded. Note that if an alternate ENRP server responds 939 the ASAP endpoint SHOULD adopt the responding ENRP server as its new 940 "home" server and resend the request to the new "home" server. 942 3.8. Cookie handling procedures 944 Whenever a PE wants and a control channel exists it can send an 945 ASAP_COOKIE Message to the PU via the control channel. The ASAP 946 layer at the PU stores the Cookie parameter and discards an older one 947 if it is present. 949 If the ASAP layer detects a failure and initiates a failover to a 950 different PE, the ASAP layer sends the last received Cookie parameter 951 in an ASAP_COOKIE_ECHO message to the new PE. The upper layer may be 952 involved in the failover procedure. 954 This cookie mechanism can be used as a simple method for state 955 sharing. Therefore a cookie should be signed by the sending PE and 956 this should be verified by the receiving PE. The details of this are 957 out of scope of this document. It is only important that the PU 958 stores always the last received Cookie Parameter and sends that back 959 unmodified in case of a PE failure. 961 3.9. Business Card handling procedures 963 When communication begins between a PU and a PE (i.e. the first 964 message is sent from the PU to the PE) the ASAP layer in the PU 965 SHOULD send an ASAP_BUSINESS_CARD IF the sender is also registered as 966 a PE. A PE may also send back to a PU a business card as well. An 967 ASAP_BUSINESS_CARD MUST NOT be sent if a control channel does NOT 968 exist between the PU and PE. After communication as been established 969 between a PE and PU at any time either entity may update its failover 970 distribution by sending a new ASAP_BUSINESS_CARD. 972 The business card serves two purposes (for both endpoints PU and PE). 973 First it lists the endpoints pool handle. For a PU contacting a PE 974 this is essential so that the PE may also gain the full benefits of 975 ASAP if the PU is also a PE. Secondly the business card tells the 976 receiver a failover order that is recommended to follow. This may 977 facilitate rendezvous between PE's as well as some control of load 978 redistribution upon the failure of any given PE. 980 Upon receipt of an ASAP_BUSINESS_CARD Message (see Section 2.2.13) 981 the receiver SHOULD: 983 BC1) Unpack the ASAP_BUSINESS_CARD, and if no entry exists in the 984 translation cache and one exists, populate the new Pool Handle 985 into the cache and request a handle resolution of the pool handle. 987 BC2) Create a list for this PE of preferred failover order so that in 988 the event of a failure the preferred list will be used to guide 989 the ASAP endpoint in the selection of an alternate PE. 991 4. The ASAP Interfaces 993 This chapter will focus primarily on the primitives and notifications 994 that form the interface between the ASAP-user and ASAP and that 995 between ASAP and its lower layer transport protocol (e.g., SCTP). 997 Note, the following primitive and notification descriptions are shown 998 for illustrative purposes. We believe that including these 999 descriptions in this document is important to the understanding of 1000 the operation of many aspects of ASAP. But an ASAP implementation is 1001 not required to use the exact syntax described in this section. 1003 An ASAP User passes primitives to the ASAP sub-layer to request 1004 certain actions. Upon the completion of those actions or upon the 1005 detection of certain events, the ASAP will notify the ASAP user. 1007 4.1. Registration.Request Primitive 1009 Format: registration.request(poolHandle, 1010 User Transport parameter(s)) 1012 The poolHandle parameter contains a NULL terminated ASCII string of 1013 fixed length. The optional User Transport parameter(s) indicate 1014 specific transport parameters and types to register with. If this 1015 optional parameter is left off, then the SCTP endpoint used to 1016 communicate with the ENRP server is used as the default User 1017 Transport parameter. Note that any IP address contained within a 1018 User Transport parameter MUST be a bound IP address in the SCTP 1019 endpoint used to communicate with the ENRP server. 1021 The ASAP user invokes this primitive to add itself to the 1022 handlespace, thus becoming a Pool Element of a pool. The ASAP user 1023 must register itself with the ENRP server by using this primitive 1024 before other ASAP users using the handlespace can send message(s) to 1025 this ASAP user by Pool Handle or by PE handle (see Section 4.5.1 and 1026 Section 4.5.3). 1028 In response to the registration primitive, the ASAP endpoint will 1029 send an ASAP_REGISTRATION message to the home ENRP server (See 1030 Section 2.2.1 and Section 3.1), and start a T2-registration timer. 1032 4.2. Deregistration.Request Primitive 1034 Format: deregistration.request(poolHandle) 1036 The ASAP PE invokes this primitive to remove itself from the Server 1037 Pool. This should be used as a part of the graceful shutdown process 1038 by the application. 1040 A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the 1041 home ENRP server (see Section 2.2.2 and Section 3.2). 1043 4.3. Cache.Populate.Request Primitive 1045 Format: cache.populate.request([Pool-Handle | 1046 Pool-Element-Handle]) 1048 If the address type is a Pool handle and a local handle translation 1049 cache exists, the ASAP endpoint should initiate a mapping information 1050 query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle 1051 and update it local cache when the response comes back from the ENRP 1052 server. 1054 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 1055 from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message 1056 is sent to the ENRP server for resolution. When the response message 1057 returns from the ENRP server the local cache is updated. 1059 Note that if the ASAP service does NOT support a local cache this 1060 primitive performs NO action. 1062 4.4. Cache.Purge.Request Primitive 1064 Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) 1066 If the user passes a Pool handle and local handle translation cache 1067 exists, the ASAP endpoint should remove the mapping information on 1068 the Pool handle from its local cache. If the user passes a Pool- 1069 Element-Handle then the Pool handle within is used for the 1070 cache.purge.request. 1072 Note that if the ASAP service does NOT support a local cache this 1073 primitive performs NO action. 1075 4.5. Data.Send.Request Primitive 1077 Format: data.send.request(destinationAddress, typeOfAddress, 1078 message, sizeOfMessage, Options); 1080 This primitive requests ASAP to send a message to some specified Pool 1081 or Pool Element within the current Operational scope. 1083 Depending on the address type used for the send request, the senders 1084 ASAP endpoint may perform address translation and Pool Element 1085 selection before sending the message out. This also MAY dictate the 1086 creation of a local transport endpoint in order to meet the required 1087 transport type. 1089 The data.send.request primitive can take different forms of address 1090 types as described in the following sections. 1092 4.5.1. Sending to a Pool Handle 1094 In this case the destinationAddress and typeOfAddress together 1095 indicates a pool handle. 1097 This is the simplest form of send.data.request primitive. By 1098 default, this directs ASAP to send the message to one of the Pool 1099 Elements in the specified pool. 1101 Before sending the message out to the pool, the senders ASAP endpoint 1102 MUST first perform a pool handle to address translation. It may also 1103 need to perform Pool Element selection if multiple Pool Elements 1104 exist in the pool. 1106 If the senders ASAP implementation does not support a local cache of 1107 the mapping information or if it does not have the mapping 1108 information on the pool in its local cache, it will transmit a 1109 ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to 1110 the current home ENRP server, and MUST hold the outbound message in 1111 queue while awaiting the response from the ENRP server (any further 1112 send request to this pool before the ENRP server responds SHOULD also 1113 be queued). 1115 Once the necessary mapping information arrives from the ENRP server, 1116 the senders ASAP will: 1118 A) map the pool handle into a list of transport addresses of the 1119 destination PE(s), 1121 B) if multiple PEs exist in the pool, ASAP will choose one of them 1122 and transmit the message to it. In that case, the choice of the 1123 PE is made by ASAP endpoint of the sender based on the server 1124 pooling policy as discussed in Section 4.5.2 1126 C) Optionally create any transport endpoint that may be needed to 1127 communicate with the PE selected. 1129 D) if no transport association or connection exists towards the 1130 destination PE, ASAP will establish any needed transport state, 1132 E) send out the queued message(s) to the appropriate transport 1133 connection using the appropriate send mechanism (e.g. for SCTP the 1134 SEND primitive in RFC2960 [4] would be used), and, 1136 F) if the local cache is implemented, append/update the local cache 1137 with the mapping information received in the ENRP server's 1138 response. Also, record the local transport information (e.g. the 1139 SCTP association id) if any new transport state was created. 1141 For more on the ENRP server request procedures see ENRP [7]. 1143 Optionally, the ASAP endpoint of the sender may return a Pool Element 1144 handle of the selected PE to the application after sending the 1145 message. This PE handle can then be used for future transmissions to 1146 that same PE (see Section 4.5.3). 1148 Section 3.7 defines the fail-over procedures for cases where the 1149 selected PE is found unreachable. 1151 4.5.2. Pool Element Selection 1153 Each time an ASAP user sends a message to a pool that contains more 1154 than one PE, the senders ASAP endpoint must select one of the PEs in 1155 the pool as the receiver of the current message. The selection is 1156 done according to the current server pooling policy of the pool to 1157 which the message is sent. 1159 Note, no selection is needed if the ASAP_SEND_TOALL option is set 1160 (see Section 4.5.5). 1162 Together with the server pooling policy, each PE can also specify a 1163 Policy Value for itself at the registration time. The meaning of the 1164 policy value depends on the current server pooling policy of the 1165 group. A PE can also change its policy value whenever it desires, by 1166 re-registering itself with the handlespace with a new policy value. 1167 Re-registration shall be done by simply sending another 1168 ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). 1170 Four basic server pooling policies are defined in ASAP, namely the 1171 Round Robin, Least Used, Least Used Degrading and Weighted Round 1172 Robin. The following sections describes each of these policies. 1174 4.5.2.1. Round Robin Policy 1176 When an ASAP endpoint sends messages by Pool Handle and Round-Robin 1177 is the current policy of that Pool, the ASAP endpoint of the sender 1178 will select the receiver for each outbound message by round-Robining 1179 through all the registered PEs in that Pool, in an attempt to achieve 1180 an even distribution of outbound messages. Note that in a large 1181 server pool, the ENRP server MAY NOT send back all PEs to the ASAP 1182 client. In this case the client or PU will be performing a round 1183 robin policy on a subset of the entire Pool. 1185 4.5.2.2. Least Used Policy 1187 When the destination Pool is under the Least Used server pooling 1188 policy, the ASAP endpoint of the message sender will select the PE 1189 that has the lowest policy value in the group as the receiver of the 1190 current message. If more than one PE from the group share the same 1191 lowest policy value, the selection will be done round Robin amongst 1192 those PEs. 1194 It is important to note that this policy means that the same PE will 1195 be always selected as the message receiver by the sender until the 1196 load control information of the pool is updated and changed in the 1197 local cache of the sender (via a cache update see Section 3.3). 1199 4.5.2.3. Least Used with Degradation Policy 1201 This policy is the same as the Least Used policy with the exception 1202 that, each time the PE with the lowest policy value is selected from 1203 the Pool as the receiver of the current message, its policy value is 1204 incremented, and thus it may no longer be the lowest value in the 1205 Pool. 1207 This provides a degradation of the policy towards round Robin policy 1208 over time. As with the Least Used policy, every local cache update 1209 at the sender will bring the policy back to Least Used with 1210 Degradation. 1212 4.5.2.4. Weighted Round Robin Policy 1214 [TBD] 1216 4.5.3. Sending to a Pool Element Handle 1218 In this case the destinationAddress and typeOfAddress together 1219 indicate an ASAP Pool Element handle. 1221 This requests the ASAP endpoint to deliver the message to the PE 1222 identified by the Pool Element handle. 1224 The Pool Element handle should contain the Pool Handle and a 1225 destination transport address of the destination PE or the Pool 1226 Handle and the transport type. Other implementation dependant 1227 elements may also be cached in a Pool Element handle. 1229 The ASAP endpoint shall use the transport address and transport type 1230 to identify the endpoint to communicate with. If no communication 1231 state exists with the peer endpoint (and is required by the transport 1232 protocol) the ASAP endpoint MAY setup the needed state and then 1233 invoke the SEND primitive for the particular transport protocol to 1234 send the message to the PE. 1236 In addition, if a local translation cache is supported the endpoint 1237 will: 1239 A) send out the message to the transport address (or association id) 1240 designated by the PE handle. 1242 B) determine if the Pool Handle is in the local cache. 1244 If it is NOT, the endpoint will: 1246 i) ask the home ENRP server for handle resolution on pool handle 1247 by sending an ASAP_HANDLE_RESOLUTION message (see 1248 Section 2.2.5), and 1250 ii) use the response to update the local cache. 1252 If the pool handle is in the cache, the endpoint will only 1253 update the pool handle if the cache is stale. A stale cache is 1254 indicated by it being older than the protocol parameter 1255 'stale.cache.value' (see Section 5.2). 1257 Section 3.5 and Section 4.9 defines the fail-over procedures for 1258 cases where the PE pointed to by the Pool Element handle is found 1259 unreachable. 1261 Optionally, the ASAP endpoint may return the actual Pool Element 1262 handle to which the message was sent (this may be different from the 1263 Pool Element handle specified when the primitive is invoked, due to 1264 the possibility of automatic fail-over). 1266 4.5.4. Send by Transport Address 1268 In this case the destinationAddress and typeOfAddress together 1269 indicate a transport address and transport type. 1271 This directs the senders ASAP endpoint to send the message out to the 1272 specified transport address. 1274 No endpoint fail-over is support when this form of send request is 1275 used. This form of send request effectively by-passes the ASAP 1276 endpoint. 1278 4.5.5. Message Delivery Options 1280 The Options parameter passed in the various forms of the above 1281 data.send.request primitive gives directions to the senders ASAP 1282 endpoint on special handling of the message delivery. 1284 The value of the Options parameter is generated by bit-wise "OR"ing 1285 of the following pre-defined constants: 1287 ASAP_USE_DEFAULT: 0x0000 Use default setting. 1289 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 1290 case where the first selected PE or the PE pointed to by the PE 1291 handle is found unreachable, the sender's ASAP endpoint SHOULD re- 1292 select an alternate PE from the same pool if one exists, and 1293 silently re-send the message to this newly selected endpoint. 1295 Note that this is a best-effort service. Applications should be 1296 aware that messages can be lost during the failover process, even 1297 if the underlying transport supports retrieval of unacknowledged 1298 data (e.g. SCTP) (Example: messages acknowledged by the SCTP 1299 layer at a PE, but not yet read by the PE when a PE failure 1300 occurs.) In the case where the underlying transport does not 1301 support such retrieval (e.g. TCP), any data already submitted by 1302 ASAP to the transport layer MAY be lost upon failover. 1304 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP 1305 endpoint from re-sending the message to any alternate PE in case 1306 that the first selected PE or the PE pointed to by the PE handle 1307 is found unreachable. Instead, the senders ASAP endpoint shall 1308 notify its upper layer about the unreachability with an 1309 Error.Report and return any unsent data. 1311 ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 1312 endpoint to send the message to the same PE in the pool that the 1313 previous message destined to this pool was sent to. 1315 ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option 1316 directs the senders ASAP endpoint to send a copy of the message to 1317 all the PEs, except for the sender itself if the sender is a PE, 1318 in that pool. 1320 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination 1321 with ASAP_SEND_TO_ALL option. It permits the senders ASAP 1322 endpoint also deliver a copy of the message to itself if the 1323 sender is a PE of the pool (i.e., loop-back). 1325 ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to 1326 send the current message using un-ordered delivery (note the 1327 underlying transport must support un-ordered delivery for this 1328 option to be effective). 1330 4.6. Data.Received Notification 1332 Format: data.received(messageReceived, sizeOfMessage, 1333 senderAddress, typeOfAddress) 1335 When a new user message is received, the ASAP endpoint of the 1336 receiver uses this notification to pass the message to its upper 1337 layer. 1339 Along with the message being passed, the ASAP endpoint of the 1340 receiver should also indicate to its upper layer the message senders 1341 address. The senders address can be in the form of either an SCTP 1342 association id, TCP transport address, UDP transport address, or an 1343 ASAP Pool Element handle. 1345 A) If the handle translation local cache is implemented at the 1346 receiver's ASAP endpoint, a reverse mapping from the senders IP 1347 address to the pool handle should be performed and if the mapping 1348 is successful, the senders ASAP Pool Element handle should be 1349 constructed and passed in the senderAddress field. 1351 B) If there is no local cache or the reverse mapping is not 1352 successful, the SCTP association id or other transport specific 1353 identification (if SCTP is not being used) should be passed in the 1354 senderAddress field. 1356 4.7. Error.Report Notification 1358 Format: error.report(destinationAddress, typeOfAddress, 1359 failedMessage, sizeOfMessage) 1361 An error.report should be generated to notify the ASAP user about 1362 failed message delivery as well as other abnormalities. 1364 The destinationAddress and typeOfAddress together indicates to whom 1365 the message was originally sent. The address type can be either a 1366 ASAP Pool Element handle, association id, or a transport address. 1368 The original message (or the first portion of it if the message is 1369 too big) and its size should be passed in the failedMessage and 1370 sizeOfMessage fields, respectively. 1372 4.8. Examples 1374 These examples assume an underlying SCTP transport between the PE and 1375 PU. Other transports are possible but SCTP is utilized in the 1376 examples for illustrative purposes. Note that all communication 1377 between PU and ENRP server and PE and ENRP servers would be using 1378 SCTP. 1380 4.8.1. Send to a New Pool 1382 This example shows the event sequence when a Pool User sends the 1383 message "hello" to a pool which is not in the local translation cache 1384 (assuming local caching is supported). 1386 ENRP Server PU new-handle:PEx 1388 | | | 1389 | +---+ | 1390 | | 1 | | 1391 |2. ASAP_HANDLE_RESOLUTION +---+ | 1392 |<-------------------------------| | 1393 | +---+ | 1394 | | 3 | | 1395 |4. ASAP_HANDLE_RESOLUTION_RSP +---+ | 1396 |------------------------------->| | 1397 | +---+ | 1398 | | 5 | | 1399 | +---+ 6. "hello1" | 1400 | |---------------->| 1401 | | | 1403 1) The user at PU invokes: 1405 data.send.request("new-handle", handle-type, "hello1", 6, 0); 1407 The ASAP endpoint, in response, looks up the pool "new-handle" in 1408 its local cache but fails to find it. 1410 2) The ASAP endpoint of PU queues the message, and sends an 1411 ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all 1412 information about pool "new-handle". 1414 3) A T1-ENRPrequest timer is started while the ASAP endpoint is 1415 waiting for the response from the ENRP server. 1417 4) The ENRP Server responds to the query with an 1418 ASAP_HANDLE_RESOLUTION_REPONSE message that contains all the 1419 information about pool "new-handle". 1421 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 1422 cache with information on pool "new-handle". 1424 6) Based on the server pooling policy of pool "new-handle", ASAP at 1425 PU selects the destination PE (PEx), sets up, if necessary, an 1426 SCTP association towards PEx (explicitly or implicitly), and send 1427 out the queued "hello1" user message. 1429 4.8.2. Send to a Cached Pool Handle 1431 This shows the event sequence when the ASAP user PU sends another 1432 message to the pool "new-handle" after what happened in 1433 Section 4.8.1. 1435 ENRP Server PU new-handle:PEx 1437 | | | 1438 | +---+ | 1439 | | 1 | | 1440 | +---+ 2. "hello2" | 1441 | |---------------->| 1442 | | | 1444 1) The user at PU invokes: 1446 pdata.send.request("new-handle", handle-type, "hello2", 6, 0); 1448 The ASAP endpoint, in response, looks up the pool "new-handle" in 1449 its local cache and find the mapping information. 1451 2) Based on the server pooling policy of "new-handle", ASAP at PU 1452 selects the PE (assume EPx is selected again), and sends out 1453 "hello2" message (assume the SCTP association is already set up). 1455 4.9. PE send failure 1457 When the ASAP endpoint in a PE or PU attempts to send a message to a 1458 PE and fails the failed sender will report the event as described in 1459 Section 3.5 . 1461 Additional primitive are also defined in this section to support 1462 those user applications that do not wish to use ASAP as the actual 1463 transport. 1465 4.9.1. Translation.Request Primitive 1467 Format: translation.request(Pool-Handle) 1469 If the address type is a Pool handle and a local handle translation 1470 cache exists, the ASAP endpoint should look within its translation 1471 cache and return the current known transport types, ports and 1472 addresses to the caller. 1474 If the Pool handle does not exist in the local handle cache or no 1475 handle cache exists, the ASAP endpoint will send an 1476 ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon 1477 completion of the handle resolution, the ASAP endpoint should 1478 populate the local handle cache (if a local handle cache is 1479 supported) and return the transport types, ports and addresses to the 1480 caller. 1482 4.9.2. Transport.Failure Primitive 1484 Format: transport.failure(Pool-Handle, Transport-address) 1486 If an external user encounters a failure in sending to a PE and is 1487 NOT using ASAP it can use this primitive to report the failure to the 1488 ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the 1489 "home" ENRP server in response to this primitive. Note ASAP SHOULD 1490 NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually 1491 made a previous request to send data to the PE. 1493 5. Timers, Variables, and Thresholds 1495 The following is a summary of the timers, variables, and pre-set 1496 protocol constants used in ASAP. 1498 5.1. Timers 1500 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1501 the ENRP server (providing application information is queued). 1502 Normally set to 15 seconds. 1504 T2-registration - A timer started when sending an ASAP_REGISTRATION 1505 request to the home ENRP server, normally set to 30 seconds. 1507 T3-deregistration - A timer started when sending a deregistration 1508 request to the home ENRP server, normally set to 30 seconds. 1510 T4-reregistration - This timer is started after successful 1511 registration into the ASAP handle space and is used to cause a re- 1512 registration at a periodic interval. This timer is normally set 1513 to 10 minutes or 20 seconds less than the Life Timer parameter 1514 used in the registration request (whichever is less). 1516 T5-Serverhunt - This timer is used during the ENRP server hunt 1517 procedure and is normally set to 120 seconds. 1519 T6-Serverannounce - This timer gives the time between the sending of 1520 consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1521 1 second. 1523 T7-ENRPoutdate - This timer gives the time a server announcement is 1524 valid. It is normally set to 5 seconds. 1526 5.2. Variables 1528 stale.cache.value - A threshold variable that indicates how long a 1529 cache entry is valid for. 1531 5.3. Thresholds 1533 MAX-REG-ATTEMPT - The maximum number of registration attempts to be 1534 made before a server hunt is issued. 1536 MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made 1537 when requesting information from the local ENRP server before a 1538 server hunt is issued. 1540 6. Security Considerations 1542 Threats Introduced by Rserpool and Requirements for Security in 1543 Response to Threats [8] describes the threats to the Rserpool 1544 architecture in detail and lists the security requirements in 1545 response to each threat. From the threats described in this 1546 document, the security services required for the Rserpool protocol 1547 are enumerated below. 1549 Threat 1) PE registration/deregistration flooding or spoofing 1550 ----------- 1551 Security mechanism in response: ENRP server authenticates the PE 1553 Threat 2) PE registers with a malicious ENRP server 1554 ----------- 1555 Security mechanism in response: PE authenticates the ENRP server 1557 Threat 1 and 2 taken together results in mutual authentication of the 1558 ENRP server and the PE. 1560 Threat 3) Malicious ENRP server joins the ENRP server pool 1561 ----------- 1562 Security mechanism in response: ENRP servers mutually authenticate 1564 Threat 4) A PU communicates with a malicious ENRP server for handle 1565 resolution 1566 ----------- 1567 Security mechanism in response: The PU authenticates the ENRP server 1569 Threat 5) Replay attack 1570 ----------- 1571 Security mechanism in response: Security protocol which has 1572 protection from replay attacks 1574 Threat 6) Corrupted data which causes a PU to have misinformation 1575 concerning a pool handle resolution 1576 ----------- 1577 Security mechanism in response: Security protocol which supports 1578 integrity protection 1580 Threat 7) Eavesdropper snooping on handlespace information 1581 ----------- 1582 Security mechanism in response: Security protocol which supports data 1583 confidentiality 1585 Threat 8) Flood of ASAP Endpoint_Unreachable messages from the PU to 1586 ENRP server 1587 ----------- 1588 Security mechanism in response: ASAP must control the number of ASAP 1589 endpoint unreachable messages transmitted from the PU to the ENRP 1590 server. 1592 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 1593 the ENRP server 1594 ----------- 1595 Security mechanism in response: ENRP server must control the number 1596 of ASAP_ENDPOINT_KEEP_AlIVE messages to the PE 1598 To summarize the threats 1-7 require security mechanisms which 1599 support authentication, integrity, data confidentiality, protection 1600 from replay attacks. 1602 For Rserpool we need to authenticate the following: 1604 PU <---- ENRP Server (PU authenticates the ENRP server) 1605 PE <----> ENRP Server (mutual authentication) 1606 ENRP server <-----> ENRP Server (mutual authentication) 1608 We do not define any new security mechanisms specifically for 1609 responding to threats 1-7. Rather we use existing IETF security 1610 protocols to provide the security services required. TLS supports 1611 all these requirements and MUST be implemented. The 1612 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1613 minimum by implementers of TLS for Rserpool. For purposes of 1614 backwards compatibility, ENRP SHOULD support 1615 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1616 other ciphersuite. 1618 Threat 8 requires the ASAP protocol to limit the number of ASAP 1619 Endpoint_Unreachable messages (see Section 3.5) to the ENRP server. 1621 Threat 9 requires the ENRP protocol to limit the number of 1622 ASAP_ENDPOINT_KEEP_ALIVE messages to the PE (see section x.y??? in 1623 [7]). 1625 6.1. Implementing Security Mechanisms 1627 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1628 support mutual authentication. ENRP servers must support mutual 1629 authentication among themselves. PUs MUST authenticate ENRP servers. 1631 ENRP servers and PEs SHOULD possess a site certificate whose subject 1632 corresponds to their canonical hostname. PUs MAY have certificates 1633 of their own for mutual authentication with TLS, but no provisions 1634 are set forth in this document for their use. All Rserpool elements 1635 that support TLS MUST have a mechanism for validating certificates 1636 received during TLS negotiation; this entails possession of one or 1637 more root certificates issued by certificate authorities (preferably 1638 well-known distributors of site certificates comparable to those that 1639 issue root certificates for web browsers). 1641 Implementations MUST support TLS with SCTP as described in RFC3436 1642 [9] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP 1643 we must ensure that RSerPool does not use any features of SCTP that 1644 are not available to an TLS/SCTP user. This is not a difficult 1645 technical problem, but simply a requirement. When describing an API 1646 of the RSerPool lower layer we have also to take into account the 1647 differences between TLS and SCTP. 1649 7. Acknowledgments 1651 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 1652 Thomas Dreibholz, and many others for their invaluable comments and 1653 feedback. 1655 8. References 1657 8.1. Normative References 1659 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 1660 BCP 9, RFC 2026, October 1996. 1662 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1663 Levels", BCP 14, RFC 2119, March 1997. 1665 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1666 RFC 2246, January 1999. 1668 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1669 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 1670 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1672 [5] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1673 Server Access Protocol (ASAP) and Endpoint Handlespace 1674 Redundancy Protocol (ENRP) Parameters", 1675 draft-ietf-rserpool-common-param-09 (work in progress), 1676 July 2005. 1678 [6] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 1679 A. Silverton, "Architecture for Reliable Server Pooling", 1680 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 1682 [7] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 1683 Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", 1684 draft-ietf-rserpool-enrp-12 (work in progress), July 2005. 1686 [8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. 1687 Holdrege, "Threats Introduced by Rserpool and Requirements for 1688 Security in Response to Threats", draft-ietf-rserpool-threats-05 1689 (work in progress), July 2005. 1691 [9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", 1692 RFC 3436, December 2002. 1694 8.2. Informational References (non-normative) 1696 [10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1697 Recommendations for Security", RFC 1750, December 1994. 1699 Authors' Addresses 1701 Randall R. Stewart 1702 Cisco Systems, Inc. 1703 4875 Forest Drive 1704 Suite 200 1705 Columbia, SC 29206 1706 USA 1708 Phone: 1709 Email: rrs@cisco.com 1711 Qiaobing Xie 1712 Motorola, Inc. 1713 1501 W. Shure Drive, #2309 1714 Arlington Heights, IL 60004 1715 USA 1717 Phone: 1718 Email: qxie1@email.mot.com 1720 Maureen Stillman 1721 Nokia 1722 127 W. State Street 1723 Ithaca, NY 14850 1724 USA 1726 Phone: 1727 Email: maureen.stillman@nokia.com 1729 Michael Tuexen 1730 Muenster Univ. of Applied Sciences 1731 Stegerwaldstr. 39 1732 48565 Steinfurt 1733 Germany 1735 Email: tuexen@fh-muenster.de 1737 Intellectual Property Statement 1739 The IETF takes no position regarding the validity or scope of any 1740 Intellectual Property Rights or other rights that might be claimed to 1741 pertain to the implementation or use of the technology described in 1742 this document or the extent to which any license under such rights 1743 might or might not be available; nor does it represent that it has 1744 made any independent effort to identify any such rights. Information 1745 on the procedures with respect to rights in RFC documents can be 1746 found in BCP 78 and BCP 79. 1748 Copies of IPR disclosures made to the IETF Secretariat and any 1749 assurances of licenses to be made available, or the result of an 1750 attempt made to obtain a general license or permission for the use of 1751 such proprietary rights by implementers or users of this 1752 specification can be obtained from the IETF on-line IPR repository at 1753 http://www.ietf.org/ipr. 1755 The IETF invites any interested party to bring to its attention any 1756 copyrights, patents or patent applications, or other proprietary 1757 rights that may cover technology that may be required to implement 1758 this standard. Please address the information to the IETF at 1759 ietf-ipr@ietf.org. 1761 Disclaimer of Validity 1763 This document and the information contained herein are provided on an 1764 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1765 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1766 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1767 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1768 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1769 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1771 Copyright Statement 1773 Copyright (C) The Internet Society (2006). This document is subject 1774 to the rights, licenses and restrictions contained in BCP 78, and 1775 except as set forth therein, the authors retain all their rights. 1777 Acknowledgment 1779 Funding for the RFC Editor function is currently provided by the 1780 Internet Society.