idnits 2.17.1 draft-ietf-rserpool-asap-09.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1746. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1762), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 181 instances of too long lines in the document, the longest one being 6 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 (June 9, 2004) is 7259 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: '9' is mentioned on line 1684, but not defined -- Looks like a reference, but probably isn't: 'TBD' on line 1212 == Unused Reference: '1' is defined on line 1652, 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-06 ** 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-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '6') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '7') Summary: 14 errors (**), 0 flaws (~~), 10 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: December 8, 2004 Q. Xie 5 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 June 9, 2004 11 Aggregate Server Access Protocol (ASAP) 12 draft-ietf-rserpool-asap-09.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 8, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 Aggregate Server Access Protocol (ASAP) in conjunction with the 46 Endpoint Name Resolution Protocol (ENRP) [6] provides a high 47 availability data transfer mechanism over IP networks. ASAP uses a 48 name-based addressing model which isolates a logical communication 49 endpoint from its IP address(es), thus effectively eliminating the 50 binding between the communication endpoint and its physical IP 51 address(es) which normally constitutes a single point of failure. 53 In addition, ASAP defines each logical communication destination as a 54 pool, providing full transparent support for server-pooling and load 55 sharing. It also allows dynamic system scalability - members of a 56 server pool can be added or removed at any time without interrupting 57 the service. 59 ASAP is designed to take full advantage of the network level 60 redundancy provided by the Stream Transmission Control Protocol 61 (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool 62 Elements (PE) and Pool Users (PU) MUST have an accompanying 63 transports mapping document. Note that ASAP messages passed between 64 PE's and ENRP servers MUST use SCTP. 66 The high availability server pooling is gained by combining two 67 protocols, namely ASAP and ENRP, in which ASAP provides the user 68 interface for name to address translation, load sharing management, 69 and fault management while ENRP defines the high availability name 70 translation service. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.2 Organization of this document . . . . . . . . . . . . . . 7 77 1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 78 1.3.1 Extent of the Namespace . . . . . . . . . . . . . . . 7 79 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 80 2. Message Definitions . . . . . . . . . . . . . . . . . . . . 8 81 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 82 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 83 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . 9 84 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . 9 85 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . 10 86 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . 10 87 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . 11 88 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . 11 89 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . 12 90 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . 13 91 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . 13 92 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . 13 93 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14 94 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . 14 95 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 14 96 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . 15 97 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 99 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 100 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 101 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 102 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 103 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 104 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 105 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 106 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 107 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 108 3.9 Business Card handling procedures . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . 31 121 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32 122 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32 123 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 124 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . 33 125 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . 34 126 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34 127 4.9.1 Translation.Request Primitive . . . . . . . . . . . . 35 128 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . 35 129 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . 36 130 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 131 5.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 132 5.3 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 133 6. Security Considerations . . . . . . . . . . . . . . . . . . 37 134 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 135 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40 136 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 137 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 41 138 8.2 Informational References (non-normative) . . . . . . . . . . 41 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 140 Intellectual Property and Copyright Statements . . . . . . . 43 142 1. Introduction 144 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] 145 provides a high availability data transfer mechanism over IP 146 networks. ASAP uses a name-based addressing model which isolates a 147 logical communication endpoint from its IP address(es), thus 148 effectively eliminating the binding between the communication 149 endpoint and its physical IP address(es) which normally constitutes a 150 single point of failure. 152 When multiple receiver instances exist under the same name, a.k.a, a 153 server pool, ASAP will select one Pool Element (PE), based on the 154 current load sharing policy indicated by the server pool, and deliver 155 the message to the selected PE. 157 While delivering the message, ASAP monitors the reachability of the 158 selected PE. If it is found unreachable, before notifying the sender 159 of the failure, ASAP can automatically select another PE (if one 160 exists) under that pool and attempt to deliver the message to that 161 PE. In other words, ASAP is capable of transparent fail-over amongst 162 instances of a server pool. 164 ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a 165 high availability name space. ASAP is responsible for the 166 abstraction of the underlying transport technologies, load 167 distribution management, fault management, as well as the 168 presentation to the upper layer (i.e., the ASAP user) a unified 169 primitive interface. 171 When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP 172 can seamlessly incorporate the link-layer redundancy provided by the 173 SCTP. 175 This document defines the ASAP portion of the high availability 176 server pool. ASAP depends on the services of a high availability 177 name space a.k.a. ENRP [6]. 179 1.1 Definitions 181 This document uses the following terms: 183 ASAP User: Either a PE or PU that uses ASAP. 185 Operation scope: The part of the network visible to Pool Users by a 186 specific instance of the reliable server pooling protocols. 188 Server pool (or Pool): A collection of servers providing the same 189 application functionality. 191 Pool handle (or pool name): A logical pointer to a pool. Each server 192 pool will be identifiable in the operation scope of the system by 193 a unique pool handle or "name". 195 Pool Element (PE): A server entity having registered to a pool. 197 Pool User (PU): A server Pool User. 199 Pool Element handle (PE handle): A logical pointer to a particular 200 Pool Element in a pool, 202 ENRP server: A server program running on a host that manages the name 203 space collectively with its peer ENRP servers and replies to the 204 service requests from any Pool User or Pool Element. 206 Home ENRP server: The ENRP server to which a Pool Element currently 207 uses. A PU or PE normally chooses the ENRP server on their local 208 host as the home ENRP server (if one exists). A PU or PE should 209 only have one home ENRP server at any given time. Having a "home" 210 ENRP server helps provide a mechanism to minimize the number of 211 associations a given PE will have. 213 ENRP client channel: The communication channel through which an ASAP 214 User (either a PE or PU) requests ENRP namespace 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 ENRP server channel: Defined by a well known multicast IP address and 220 a well known port number, OR a well known list of transport 221 addresses for a group of ENRP servers spanning an operational 222 scope. All ENRP servers in an operation scope can communicate 223 with one another through this channel via either multicast OR 224 direct point to point SCTP associations. 226 ENRP name domain: Defined by the combination of the ENRP client 227 channel and the ENRP server channel in the operation scope. 229 Network Byte Order: Most significant byte first, a.k.a Big Endian. 231 Transport address: A Transport Address is traditionally defined by 232 Network Layer address, Transport Layer protocol and Transport 233 Layer port number. In the case of SCTP running over IP, a 234 transport address is defined by the combination of an IP address 235 and an SCTP port number (where SCTP is the Transport protocol). 237 1.2 Organization of this document 239 Section 2 details ASAP message formats. In Section 3 we give the 240 detailed ASAP procedures for the ASAP implementer. And in Section 4 241 we give the details of the ASAP interface, focusing on the 242 communication primitives between the applications above ASAP and ASAP 243 itself, and the communications primitives between ASAP and SCTP (or 244 other transport layer). Also included in this discussion is relevant 245 timers and configurable parameters as appropriate. Section 5 246 provides threshold and protocol variables. 248 1.3 Scope of ASAP 250 The requirements for high availability and scalability do not imply 251 requirements on shared state and data. ASAP does not provide 252 transaction failover. If a host or application fails during 253 processing of a transaction this transaction may be lost. Some 254 services may provide a way to handle the failure, but this is not 255 guaranteed. ASAP MAY provide hooks to assist an application in 256 building a mechanism to share state but ASAP in itself will NOT share 257 any state. 259 1.3.1 Extent of the Namespace 261 The scope of the ASAP/ENRP is NOT Internet wide. The namespace is 262 neither hierarchical nor arbitrarily large like DNS. We propose a 263 flat peer-to-peer model. Pools of servers will exist in different 264 administrative domains. For example, suppose we want to use ASAP/ 265 ENRP. First, the PU may use DNS to contact an ENRP server. Suppose 266 a PU in North America wishes to contact the server pool in Japan 267 instead of North America. The PU would use DNS to get the list of IP 268 addresses of the Japanese server pool domain, that is, the ENRP 269 client channel in Japan. From there the PU would query the ENRP 270 server and then directly contact the PE(s) of interest. 272 1.4 Conventions 274 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 275 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 276 they appear in this document, are to be interpreted as described in 277 RFC2119 [2]. 279 2. Message Definitions 281 All messages as well as their fields described below shall be in 282 Network Byte Order during transmission. For fields with a length 283 bigger than 4 octets, a number in a pair of parentheses may follow 284 the field name to indicate the length of the field in number of 285 octets. 287 2.1 ASAP Parameter Formats 289 The basic message format and all parameter formats can be found in 290 ENRP-ASAP [5]. Note also that ALL ASAP messages exchanged between an 291 ENRP server and a PE MUST use SCTP as transport, while ASAP messages 292 exchanged between an ENRP server and a PU MUST use either SCTP or TCP 293 as transport. PE to PU data traffic MAY use any transport protocol 294 specified by the PE during registration. 296 2.2 ASAP Messages 298 This section details the individual messages used by ASAP. These 299 messages are composed of a standard message format found in Section 4 300 of ENRP-ASAP [5]. The parameter descriptions may also be found in 301 Section 3 of ENRP-ASAP [5]. 303 The following ASAP message types are defined in this section: 305 Type Message Name 306 ----- ------------------------- 307 0x00 - (reserved by IETF) 308 0x01 - Registration 309 0x02 - Deregistration 310 0x03 - Registration Response 311 0x04 - Deregistration Response 312 0x05 - Name Resolution 313 0x06 - Name Resolution Response 314 0x07 - Endpoint Keep Alive 315 0x08 - Endpoint Keep Alive Acknowledgement 316 0x09 - Endpoint Unreachable 317 0x0a - Server Announce 318 0x0b - Cookie 319 0x0c - Cookie-Echo 320 0x0d - Business Card 321 0x0e - Peer Error 323 2.2.1 REGISTRATION message 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 : Pool Handle Parameter : 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 : Pool Element Parameter : 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 The pool handle parameter field specifies the name to be registered. 336 The PE Parameter field MUST be filled in by the registrant endpoint 337 to declare its transport address, server pooling policy and value, 338 and other operation preferences. Note that the registration message 339 MUST use SCTP and the IP address(es) of the PE registered within the 340 Pool Element Parameter MUST be a subset of the addresses of the SCTP 341 association in respective of the transport protocol registered by the 342 PE. 344 2.2.2 DEREGISTRATION message 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 : Pool Handle Parameter : 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 : PE Identifier Parameter : 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 356 The PE sending the DEREGISTRATION shall fill in the pool handle and 357 the PE identifier parameter in order to allow the ENRP server to 358 verify the identity of the endpoint. Note that deregistration is NOT 359 allowed by proxy, in other words a PE may only deregister itself. 361 2.2.3 REGISTRATION_RESPONSE message 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = 0x3 |0|0|0|0|0|0|0|R| Message Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 : Pool Handle Parameter : 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 : PE Identifier Parameter : 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 : Operational Error (optional) : 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 R (Reject) flag 377 When set to '1', indicate that the ENRP server that sent this message 378 has rejected the registration. Otherwise, the registration is 379 granted. 381 Operational Error 383 This optional TLV parameter is included if an error or some atypical 384 events occurred during the registration process. When the 'R' flag 385 is set to '1', this TLV, if present, indicates the cause of the 386 rejection. When the 'R' flag is set to '0', this TLV, if present, 387 serves as a warning to the registering PE, informing it that some of 388 its registration values may have been modified or overruled by the 389 ENRP server (e.g., the selection policy type overruled). If the 390 registration was successful and there is no warning this parameter is 391 not included. 393 2.2.4 DEREGISTRATION_RESPONSE message 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 : Pool Handle Parameter : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 : PE Identifier Parameter : 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 : Operational Error (optional) : 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Operational Error 408 This optional TLV parameter is included if an error occurred during 409 the deregistration process. If the deregistration was successful 410 this parameter is not included. 412 2.2.5 NAME_RESOLUTION 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 = 0x5 |0|0|0|0|0|0|0|0| Message Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 : Pool Handle Parameter : 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 This message is sent to a ENRP server to request translation of the 423 Pool Handle to a list of Pool Elements. If sent from a PE the SCTP 424 association used for registration SHOULD be used. 426 2.2.6 NAME_RESOLUTION_RESPONSE message 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 : Pool Handle Parameter : 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 : Overall PE Selection Policy (optional) : 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 : Pool Element Parameter 1 (optional) : 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 : ... : 440 : : 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 : Pool Element Parameter N (optional) : 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 : Operational Error (optional) : 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Overall PE Selection Policy: 449 This TLV is a PE selection policy parameter and can be present when 450 the response is positive. It indicates the overall selection policy 451 of the pool. If not present, round-robin is assumed. This TLV is 452 not present when the response is negative (i.e., a rejection). 454 Note, any load policy parameter inside the Pool Element Parameter (if 455 present) MUST be ignored, and MUST NOT be used to determine the 456 overall pool policy. 458 Pool Element Parameters 460 When the response is positive, an array of PE TLVs are included, 461 indicating the current PEs and their information in the named pool. 462 In a positive response, at least one PE TLV MUST be present. When 463 the response is negative, no PE TLVs are included. 465 Operational Error 467 The presence of this TLV indicates that the response is negative 468 (i.e., the name resolution request was rejected by the ENRP server). 469 The cause code in this TLV (if present) will indicate the reason the 470 name resolution request was rejected (e.g., the requested pool handle 471 was not found). 473 2.2.7 ENDPOINT_KEEP_ALIVE message 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 : Pool Handle Parameter : 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 This message is sent to a PE by the ENRP server as a "health" check. 484 If the transport level Heart Beat mechanism is insufficient, this 485 adds heartbeat messages with the goal of determining health status at 486 ASAP level in a possibly more timely fashion. (The transport level 487 Heart Beat may sometimes be considered insufficient due to that time 488 outs are set for too long or heartbeats are not frequent enough, or, 489 that the transport level Heart Beat mechanism's coverage is limited 490 only to the transport level at the two ends.) 492 Using ASAP keepalive also has additional value to the reliability of 493 fault detection when SCTP stack is in the kernel. In such a case, 494 while SCTP level heartbeat monitors the end-to-end connectivity 495 between the two SCTP stacks, ASAP keepalive monitors the end-to-end 496 liveliness of the ASAP layer above it. 498 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 : Pool Handle Parameter : 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 : PE Identifier Parameter : 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 This message is sent by the PE to the ENRP server has an 511 acknowledgment to the ENDPOINT_KEEP_ALIVE message. 513 2.2.9 ENDPOINT_UNREACHABLE message 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 : Pool Handle Parameter : 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 : PE Identifier Parameter : 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 A PE or PU will send this message to an ENRP server to report the 526 unreachability of the specified PE. 528 2.2.10 SERVER_ANNOUNCE message 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 : Transport param #1 : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 : Transport param #2 : 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 : : 540 : ..... : 541 : : 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 : Transport param #n : 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 550 2.2.11 COOKIE message 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 : Cookie Parameter : 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 This message is sent by a PE to a PU. It may only be sent when a 561 control channel exists between the PE and PU. 563 2.2.12 COOKIE_ECHO message 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 : Cookie Parameter : 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 This message is sent by a PU to a PE in case of a failover. The 574 Cookie Parameter is one received latest from the failed PE. 576 2.2.13 BUSINESS_CARD message 578 This message is sent by a PU to a PE or from a PE to a PU. This 579 parameter MUST NOT be sent if a control channel does NOT exists 580 between the PE and PU. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 0xd |0|0|0|0|0|0|0|0| Message Length | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 : Pool Handle Parameter : 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 : Pool Element Parameter-1 : 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 : .. : 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 : Pool Element Parameter-N : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 The sender of this message lists both the Pool that the sender 597 belongs to and a preferred list of failover candidates. 599 2.2.14 PEER_ERROR message 601 This message is used to report an operation error. 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type = 0xe |0|0|0|0|0|0|0|0| Message Length | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 : Operation Error Parameter : 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 3. Procedures 613 This section will focus on the methods and procedures used by an 614 internal ASAP endpoint. Appropriate timers and recovery actions for 615 failure detection and management are also discussed. 617 3.1 Registration 619 When a PE wishes to join its server pool it MUST use the procedures 620 outlined in this section to register. Often the registration will be 621 triggered by a user request primitive (discussed in Section 4.1). 622 The ASAP endpoint MUST register using an SCTP association between the 623 ASAP endpoint and the ENRP server. If the ASAP endpoint has not 624 established its Home ENRP server it MUST follow the procedures 625 specified in Section 3.6 to establish its Home ENRP server. 627 Once the ASAP endpoint has established its Home ENRP server the 628 following procedures MUST be followed to register: 630 R1) The SCTP endpoint used to communicate with the ENRP server MUST 631 be bound to all IP addresses that will be used by the PE 632 (irregardless of what protocol will be used to service user 633 requests to the PE). 635 R2) The ASAP endpoint MUST formulate a Registration message as 636 defined in Section 2.2.1 In formulating the message the ASAP 637 endpoint MUST: 639 R2.1) Fill in the Pool Handle to specify which server pool the 640 ASAP endpoint wishes to join. 642 R2.2) Fill in a PE identifier using a good quality randomly 643 generated number (RFC1750 [9] provides some information on 644 randomness guidelines). 646 R2.3) Fill in the registration life time parameter with the number 647 of seconds that this registration is good for. Note a PE that 648 wishes to continue service MUST re-register after the 649 registration expires. 651 R2.4) Fill in a User Transport Parameter for the type of transport 652 and the data/control channel usage the PE is willing to 653 support. Note, to join an existing server pool, the PE MUST 654 follow the overall transport type and overall data/control 655 channel usage of the pool. Otherwise, the registration may be 656 rejected by the ENRP server. 658 R2.5) Fill in the preferred Member selection policy. 660 R3) Send the Registration request to the Home ENRP server using SCTP. 662 R4) Start a T2-registration timer. 664 If the T2-registration timer expires before receiving a 665 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 666 received from the SCTP layer, the ASAP endpoint shall start the 667 Server Hunt procedure (see Section 3.6) in an attempt to get service 668 from a different ENRP server. After establishing a new Home ENRP 669 server the ASAP endpoint SHOULD restart the registration procedure. 671 At the reception of the registration response, the ASAP endpoint MUST 672 stop the T2-Registration timer. If the response indicated success, 673 then the PE is now registered and will be considered an available 674 member of the server pool. If the registration response indicates a 675 failure, the ASAP endpoint must either re-attempt registration after 676 correcting the error or return a failure indication to the ASAP 677 endpoints upper layer. The ASAP endpoint MUST NOT re-attempt 678 registration without correcting the error condition. 680 The registration response may also indicate that the registration is 681 accepted with a warning, often indicating that the ENRP server might 682 have made modifications to the value of some registration attribute 683 or attributes (such as policy type, transport usage, etc.). When 684 this happens, the PE SHOULD immediately notify its upper layer about 685 the registration modifications. This gives the upper layer a chance, 686 for example, to withdraw itself from the pool if such modifications 687 are unacceptable for its operation. 689 At any time a registered PE MAY wish to re-register to either update 690 its member selection policy value or registration expiration time. 691 When re-registering the PE MUST use the same PE identifier. 693 After successful registration the PE MUST start a T4-reregistration 694 timer. At its expiration a re-registration SHOULD be made starting 695 at step R1 including (at completion) restarting the T4-reregistration 696 timer. 698 Note that an implementation SHOULD keep a record of the number of 699 registration attempts it makes in a local variable. If repeated 700 registration time-outs or failures occurs and the local count exceeds 701 the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the 702 error to its upper layer and stop attempting registration. 704 3.2 Deregistration 706 In the event the PE wishes to deregister from its server pool 707 (normally via an upper layer requests see Section 4.2) it SHOULD use 708 the following procedures. Note that an alternate method of 709 deregistration is to NOT re-register and to allow the registration 710 lift time to expire. 712 When deregistering the PE SHOULD use the same SCTP association with 713 its Home ENRP server that was used for registration. To deregister 714 the ASAP endpoint MUST take the following actions: 716 D1) Fill in the Pool Handle parameter of the Deregistration message ( 717 Section 2.2.2) using the same Pool Handle parameter sent during 718 registration. 720 D2) Fill in the PE Identifier. The identifier MUST be the same one 721 used during registration. 723 D3) Send the deregistration message to the Home ENRP server using the 724 SCTP association. 726 D4) Start a T3-Deregistration timer. 728 If the T3-Deregistration timer expires before receiving a 729 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 730 received from the SCTP layer, the ASAP endpoint shall start the 731 Server Hunt procedure (see Section 3.6) in an attempt to get service 732 from a different ENRP server. After establishing a new Home ENRP 733 server the ASAP endpoint SHOULD restart the deregistration procedure. 735 At the reception of the deregistration response, the ASAP endpoint 736 MUST stop the T3-deregistration timer. 738 Note that after a successful deregistration the PE MAY still receive 739 requests for some period of time. The PE MAY wish to still remain 740 active and service these requests or may wish to ignore these 741 requests and exit. 743 3.3 Name resolution 745 At any time a PE or PU may wish to resolve a name. This usually will 746 occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or 747 requests a cache population (Section 4.3) but may occur for other 748 reasons (e.g. the internal ASAP PE wishes to know its peers for 749 sending a message to all of them). When an Endpoint (PE or PU) 750 wishes to resolve a name it MUST take the following actions: 752 NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool 753 Handle to be resolved. 755 NR2) If the endpoint does not have a Home ENRP server start the ENRP 756 Server Hunt procedures specified in Section 3.6 to obtain one. 757 Otherwise proceed to step NR3. 759 NR3) Send the NAME_RESOLUTION message to the Home ENRP server using 760 SCTP. 762 NR4) Start a T1-ENRPrequest timer. 764 If the T1-ENRPrequest timer expires before receiving a response 765 message, or a SEND.FAILURE notification is received from the SCTP 766 layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see 767 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 name resolution procedure. 771 At the reception of the response message (i.e., a 772 NAME_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-ENRPrequest 773 timer. After stopping the T1 timer the endpoint SHOULD process the 774 name response as appropriate (e.g. populate a local cache, give the 775 response to the ASAP user, and/or use the response to send the ASAP 776 users message). 778 Note that some ASAP endpoints MAY use a cache to minimize the number 779 of name resolutions made. If such a cache is used it SHOULD: 781 C1) Be consulted before requesting a name 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 name_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 793 name_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 a ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). Upon 799 reception of an ENDPOINT_KEEP_ALIVE message the following actions 800 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 Registration. If the Pool 804 Handle does not match silently discard the message. 806 KA2) Send a 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 ENDPOINT_KEEP_ALIVE_ACK message via the 815 appropriate SCTP association for that ENRP server. 817 KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the 818 new home ENRP server. 820 3.5 Reporting unreachable endpoints 822 Occasionally an ASAP endpoint may realize that a PE is unreachable. 823 This may occur by a specific SCTP error realized by the ASAP endpoint 824 or via an ASAP user report via the Transport.Failure Primitive 825 (Section 4.9.2). In either case the ASAP endpoint SHOULD report the 826 unavailability of the PE by sending an ENDPOINT_UNREACHABLE message 827 to its home ENRP server. The Endpoint should fill in the Pool Handle 828 and PE identifier of the unreachable endpoint. If the sender is a PE 829 the message MUST be sent via SCTP to the Endpoints Home ENRP server. 830 Note: an ASAP endpoint MUST report No more than once each time it 831 encounters such an event. 833 Note: when processing a Transport.Failure Primitive (Section 4.9.2) 834 the ASAP endpoint MUST NOT send a unreachable report unless the ASAP 835 endpoint has sent at least one message to the PE specified by the 836 primitive. 838 3.6 ENRP server hunt procedures 840 Each PU and PE manages a list of transport addresses of ENRP servers. 842 If the multicast capabilities are used an ENRP server MUST send 843 periodically every T6-Serverannounce a SERVER_ANNOUNE message 844 (Section 2.2.10) including all the transport addresses available for 845 ASAP communication to the multicast channel. 847 If a SERVER_ANNOUNCE message is received by a PU or PE it SHOULD 848 insert all new included transport address in its list of ENRP server 849 addresses and start a T7-ENRPoutdate timer for each address. For all 850 already known addresses the T7-ENRPoutdate timers MUST be restarted. 851 If no transport parameters are included in the SERVER_ANNOUNCE 852 message the source IP address and the IANA registered ASAP port 853 number are used instead. It is also assumed that the transport 854 protocol used is SCTP. If a T7-ENRP timer for a transport address 855 expires the corresponding address is deleted from the list of 856 transport addresses. 858 If no multicast capabilities are used each PU and PE MUST have a 859 configured list of transport addresses of ENRP servers. 861 At its startup, or when it fails to send to (i.e., timed-out on a 862 service request) with its current home ENRP server, a PE or PU shall 863 establish its Home ENRP server, i.e. setup a TCP connection or SCTP 864 association with an ENRP server. 866 To establish a new association or connection the following rules MUST 867 be followed: 869 SH1) The PE or PU SHOULD try to establish an association or 870 connection with no more than three ENRP server addresses. An 871 endpoint MUST NOT try to establish more than three association or 872 connections at any single time. 874 SH2) The endpoint shall start a T5-Serverhunt timer. 876 SH3) If the endpoint establishes an association or connection it MUST 877 stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the 878 T5-Serverhunt value to its initial value and then proceed to step 879 SH6. 881 SH4) If an association or connection establishment fails the endpoint 882 SHOULD try to establish an association or connection by using a 883 different transport address. 885 SH5) If the T5-Serverhunt timer expires the following should be 886 performed: 888 SH5.1) The endpoint MUST double the value of the T5-Serverhunt 889 timer. 891 SH5.2) The endpoint SHOULD stop the establishment of associations 892 and connections. 894 SH5.2) The endpoint SHOULD repeat trying to establish an 895 association or connection by proceeding to step SH1. It SHOULD 896 attempt to select a different set of transport addresses to 897 connect to. 899 SH6) The PE or PU shall pick one of the ENRP servers that it was able 900 to establish an association or connection with, and send all its 901 subsequent the namespace service requests to this new home ENRP 902 server. 904 3.7 Handle ASAP to ENRP Communication Failures 906 Three types of failure may occur when the ASAP endpoint at an 907 endpoint tries to communicate with the ENRP server: 909 A) SCTP send failure 911 B) T1-ENRPrequest timer expiration 913 C) Registration failure 915 Registration failure is discussed in Section 3.1 917 3.7.1 SCTP Send Failure 919 This indicates that the SCTP layer failed to deliver a message sent 920 to the ENRP server. In other words, the ENRP server is currently 921 unreachable. 923 In such a case, the ASAP endpoint should not re-send the failed 924 message. Instead, it should discard the failed message and start the 925 ENRP server hunt procedure as described in Section 3.6 927 3.7.2 T1-ENRPrequest Timer Expiration 929 When a T1-ENRPrequest timer expires, the ASAP should re-send the 930 original request to the ENRP server and re-start the T1-ENRPrequest 931 timer. In parallel, a SERVER_HUNT message should be issued per 932 Section 3.6 934 This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times. After 935 that, an Error.Report notification should be generated to inform the 936 ASAP user and the ENRP request message associated with the timer 937 should be discarded. Note that if an alternate ENRP server responds 938 the ASAP endpoint SHOULD adopt the responding ENRP server as its new 939 "home" server and resend the request to the new "home" server. 941 3.8 Cookie handling procedures 943 Whenever a PE wants and a control channel exists it can send a Cookie 944 Message to the PU via the control channel. The ASAP layer at the PU 945 stores the Cookie parameter and discards an older one if it is 946 present. 948 If the ASAP layer detects a failure and initiates a failover to a 949 different PE, the ASAP layer sends the last received Cookie parameter 950 in a Cookie Echo message to the new PE. The upper layer may be 951 involved in the failover procedure. 953 This cookie mechanism can be used as a simple method for state 954 sharing. Therefore a cookie should be signed by the sending PE and 955 this should be verified by the receiving PE. The details of this are 956 out of scope of this document. It is only important that the PU 957 stores always the last received Cookie Parameter and sends that back 958 unmodified in case of a PE failure. 960 3.9 Business Card handling procedures 962 When communication begins between a PU and a PE (i.e. the first 963 message is sent from the PU to the PE) the ASAP layer in the PU 964 SHOULD send a Business card IF the sender is also registered as a PE. 965 A PE may also send back to a PU a business card as well. A Business 966 card MUST NOT be sent if a control channel does NOT exist between the 967 PU and PE. After communication as been established between a PE and 968 PU at any time either entity may update its failover distribution by 969 sending a new Business Card. 971 The business card serves two purposes (for both endpoints PU and PE). 972 First it lists the endpoints pool handle. For a PU contacting a PE 973 this is essential so that the PE may also gain the full benefits of 974 ASAP if the PU is also a PE. Secondly the business card tells the 975 receiver a failover order that is recommended to follow. This may 976 facilitate rendezvous between PE's as well as some control of load 977 redistribution upon the failure of any given PE. 979 Upon receipt of a Business Card Message (see Section 2.2.13) the 980 receiver SHOULD: 982 BC1) Unpack the business card, and if no entry exists in the 983 translation cache and one exists, populate the new Pool Handle 984 into the cache and request a NAME.RESOLUTION of the pool handle. 986 BC2) Create a list for this PE of preferred failover order so that in 987 the event of a failure the preferred list will be used to guide 988 the ASAP endpoint in the selection of an alternate PE. 990 4. The ASAP Interfaces 992 This chapter will focus primarily on the primitives and notifications 993 that form the interface between the ASAP-user and ASAP and that 994 between ASAP and its lower layer transport protocol (e.g., SCTP). 996 Note, the following primitive and notification descriptions are shown 997 for illustrative purposes. We believe that including these 998 descriptions in this document is important to the understanding of 999 the operation of many aspects of ASAP. But an ASAP implementation is 1000 not required to use the exact syntax described in this section. 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 has actually made a previous 1486 request to send data to the PE. 1488 5. Timers, Variables, and Thresholds 1490 The following is a summary of the timers, variables, 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 consecutive 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 Variables 1523 stale.cache.value - A threshold variable that indicates how long a 1524 cache entry is valid for. 1526 5.3 Thresholds 1528 MAX-REG-ATTEMPT - The maximum number of registration attempts to be 1529 made before a server hunt is issued. 1531 MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made 1532 when requesting information from the local ENRP server before a 1533 server hunt is issued. 1535 6. Security Considerations 1537 Threats Introduced by Rserpool and Requirements for Security in 1538 Response to Threats [7] describes the threats to the Rserpool 1539 architecture in detail and lists the security requirements in 1540 response to each threat. From the threats described in this 1541 document, the security services required for the Rserpool protocol 1542 are enumerated below. 1544 Threat 1) PE registration/deregistration flooding or spoofing 1545 ----------- 1546 Security mechanism in response: ENRP server authenticates the PE 1548 Threat 2) PE registers with a malicious ENRP server 1549 ----------- 1550 Security mechanism in response: PE authenticates the ENRP server 1552 Threat 1 and 2 taken together results in mutual authentication of the 1553 ENRP server and the PE. 1555 Threat 3) Malicious ENRP server joins the ENRP server pool 1556 ----------- 1557 Security mechanism in response: ENRP servers mutually authenticate 1559 Threat 4) A PU communicates with a malicious ENRP server for name 1560 resolution 1561 ----------- 1562 Security mechanism in response: The PU authenticates the ENRP server 1564 Threat 5) Replay attack 1565 ----------- 1566 Security mechanism in response: Security protocol which has 1567 protection from replay attacks 1569 Threat 6) Corrupted data which causes a PU to have misinformation 1570 concerning a pool handle resolution 1571 ----------- 1572 Security mechanism in response: Security protocol which supports 1573 integrity protection 1575 Threat 7) Eavesdropper snooping on namespace information 1576 ----------- 1577 Security mechanism in response: Security protocol which supports data 1578 confidentiality 1580 Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP 1581 server 1582 ----------- 1583 Security mechanism in response: ASAP must control the number of 1584 endpoint unreachable messages transmitted from the PU to the ENRP 1585 server. 1587 Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the 1588 ENRP server 1589 ----------- 1590 Security mechanism in response: ENRP server must control the number 1591 of Endpoint_KeepAlive messages to the PE 1593 To summarize the threats 1-7 require security mechanisms which 1594 support authentication, integrity, data confidentiality, protection 1595 from replay attacks. 1597 For Rserpool we need to authenticate the following: 1599 PU <---- ENRP Server (PU authenticates the ENRP server) 1600 PE <----> ENRP Server (mutual authentication) 1601 ENRP server <-----> ENRP Server (mutual authentication) 1603 We do not define any new security mechanisms specifically for 1604 responding to threats 1-7. Rather we use existing IETF security 1605 protocols to provide the security services required. TLS supports 1606 all these requirements and MUST be implemented. The 1607 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1608 minimum by implementers of TLS for Rserpool. For purposes of 1609 backwards compatibility, ENRP SHOULD support 1610 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1611 other ciphersuite. 1613 Threat 8 requires the ASAP protocol to limit the number of 1614 Endpoint_Unreachable messages (see Section 3.5) to the ENRP server. 1616 Threat 9 requires the ENRP protocol to limit the number of 1617 Endpoint_KeepAlive messages to the PE (see section x.y??? in [6]). 1619 6.1 Implementing Security Mechanisms 1621 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1622 support mutual authentication. ENRP servers must support mutual 1623 authentication among themselves. PUs MUST authenticate ENRP servers. 1625 ENRP servers and PEs SHOULD possess a site certificate whose subject 1626 corresponds to their canonical hostname. PUs MAY have certificates 1627 of their own for mutual authentication with TLS, but no provisions 1628 are set forth in this document for their use. All Rserpool elements 1629 that support TLS MUST have a mechanism for validating certificates 1630 received during TLS negotiation; this entails possession of one or 1631 more root certificates issued by certificate authorities (preferably 1632 well-known distributors of site certificates comparable to those that 1633 issue root certificates for web browsers). 1635 Implementations MUST support TLS with SCTP as described in RFC3436 1636 [8] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP 1637 we must ensure that RSerPool does not use any features of SCTP that 1638 are not available to an TLS/SCTP user. This is not a difficult 1639 technical problem, but simply a requirement. When describing an API 1640 of the RSerPool lower layer we have also to take into account the 1641 differences between TLS and SCTP. 1643 7. Acknowledgments 1645 The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon 1646 Ong, and many others for their invaluable comments. 1648 8. References 1650 8.1 Normative References 1652 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1653 9, RFC 2026, October 1996. 1655 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1656 Levels", BCP 14, RFC 2119, March 1997. 1658 [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 1659 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1660 1999. 1662 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1663 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1664 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1666 [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1667 Server Access Protocol (ASAP) and Endpoint Name Resolution 1668 Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-06 1669 (work in progress), June 2004. 1671 [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution 1672 Protocol (ENRP)", draft-ietf-rserpool-enrp-08 (work in 1673 progress), June 2004. 1675 [7] Stillman, M., "Threats Introduced by Rserpool and Requirements 1676 for Security in Response to Threats", 1677 draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. 1679 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1680 3436, December 2002. 1682 8.2 Informational References (non-normative) 1684 [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1685 Recommendations for Security", RFC 1750, December 1994. 1687 Authors' Addresses 1689 Randall R. Stewart 1690 Cisco Systems, Inc. 1691 8725 West Higgins Road 1692 Suite 300 1693 Chicago, IL 60631 1694 USA 1696 Phone: +1-815-477-2127 1697 EMail: rrs@cisco.com 1699 Qiaobing Xie 1700 Motorola, Inc. 1701 1501 W. Shure Drive, #2309 1702 Arlington Heights, IL 60004 1703 USA 1705 Phone: +1-847-632-3028 1706 EMail: qxie1@email.mot.com 1708 Maureen Stillman 1709 Nokia 1710 127 W. State Street 1711 Ithaca, NY 14850 1712 USA 1714 Phone: +1-607-273-0724 1715 EMail: maureen.stillman@nokia.com 1717 Michael Tuexen 1719 Germany 1721 Phone: 1722 EMail: tuexen@fh-muenster.de 1724 Intellectual Property Statement 1726 The IETF takes no position regarding the validity or scope of any 1727 Intellectual Property Rights or other rights that might be claimed to 1728 pertain to the implementation or use of the technology described in 1729 this document or the extent to which any license under such rights 1730 might or might not be available; nor does it represent that it has 1731 made any independent effort to identify any such rights. Information 1732 on the procedures with respect to rights in RFC documents can be 1733 found in BCP 78 and BCP 79. 1735 Copies of IPR disclosures made to the IETF Secretariat and any 1736 assurances of licenses to be made available, or the result of an 1737 attempt made to obtain a general license or permission for the use of 1738 such proprietary rights by implementers or users of this 1739 specification can be obtained from the IETF on-line IPR repository at 1740 http://www.ietf.org/ipr. 1742 The IETF invites any interested party to bring to its attention any 1743 copyrights, patents or patent applications, or other proprietary 1744 rights that may cover technology that may be required to implement 1745 this standard. Please address the information to the IETF at 1746 ietf-ipr@ietf.org. 1748 Disclaimer of Validity 1750 This document and the information contained herein are provided on an 1751 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1752 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1753 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1754 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1755 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1756 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1758 Copyright Statement 1760 Copyright (C) The Internet Society (2004). This document is subject 1761 to the rights, licenses and restrictions contained in BCP 78, and 1762 except as set forth therein, the authors retain all their rights. 1764 Acknowledgment 1766 Funding for the RFC Editor function is currently provided by the 1767 Internet Society.