idnits 2.17.1 draft-ietf-rserpool-asap-21.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2421. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4960], [I-D.ietf-rserpool-enrp]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 11, 2008) is 5761 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-09 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-17 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-20 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Q. Xie 4 Intended status: Experimental 5 Expires: January 12, 2009 M. Stillman 6 Nokia 7 M. Tuexen 8 Muenster Univ. of Applied Sciences 9 July 11, 2008 11 Aggregate Server Access Protocol (ASAP) 12 draft-ietf-rserpool-asap-21.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 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 January 12, 2009. 39 Abstract 41 Aggregate Server Access Protocol (ASAP) in conjunction with the 42 Endpoint Handlespace Redundancy Protocol (ENRP) 43 [I-D.ietf-rserpool-enrp] provides a high availability data transfer 44 mechanism over IP networks. ASAP uses a handle-based addressing 45 model which isolates a logical communication endpoint from its IP 46 address(es), thus effectively eliminating the binding between the 47 communication endpoint and its physical IP address(es) which normally 48 constitutes a single point of failure. 50 In addition, ASAP defines each logical communication destination as a 51 pool, providing full transparent support for server-pooling and load 52 sharing. It also allows dynamic system scalability - members of a 53 server pool can be added or removed at any time without interrupting 54 the service. 56 ASAP is designed to take full advantage of the network level 57 redundancy provided by the Stream Transmission Control Protocol 58 (SCTP) [RFC4960]. Each transport protocol, other than SCTP, MUST 59 have an accompanying transport mapping document. It should be noted 60 that ASAP messages passed between PE's and ENRP servers MUST use the 61 SCTP transport protocol. 63 The high availability server pooling is gained by combining two 64 protocols, namely ASAP and ENRP, in which ASAP provides the user 65 interface for pool handle to address translation, load sharing 66 management, and fault management while ENRP defines the high 67 availability pool handle translation service. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. Organization of this document . . . . . . . . . . . . . . 6 74 1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 75 1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 76 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 77 2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 78 2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 79 2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 80 2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 81 2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 82 2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 83 2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 11 84 2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 85 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 12 86 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 14 87 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 15 88 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 15 89 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 16 90 2.2.11. ASAP_COOKIE message . . . . . . . . . . . . . . . . . 16 91 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 17 92 2.2.13. ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . 17 93 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 18 94 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 19 96 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 22 97 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 23 98 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 25 99 3.5. Unreachable endpoints . . . . . . . . . . . . . . . . . . 26 100 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 27 101 3.7. Handling ASAP Endpoint to ENRP Server Communication 102 Failures . . . . . . . . . . . . . . . . . . . . . . . . . 29 103 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 29 104 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 29 105 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 30 106 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 30 107 3.9. Business Card handling procedures . . . . . . . . . . . . 30 108 4. Roles of Endpoints . . . . . . . . . . . . . . . . . . . . . . 32 109 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 33 110 6. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 34 111 6.1. Registration.Request Primitive . . . . . . . . . . . . . . 34 112 6.2. Deregistration.Request Primitive . . . . . . . . . . . . . 34 113 6.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 35 114 6.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 35 115 6.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 35 116 6.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 36 117 6.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 37 118 6.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 38 119 6.5.4. Send by Transport Address . . . . . . . . . . . . . . 39 120 6.5.5. Message Delivery Options . . . . . . . . . . . . . . . 39 121 6.6. Data.Received Notification . . . . . . . . . . . . . . . . 40 122 6.7. Error.Report Notification . . . . . . . . . . . . . . . . 41 123 6.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 124 6.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 41 125 6.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 43 126 6.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 43 127 6.9.1. Translation.Request Primitive . . . . . . . . . . . . 43 128 6.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 44 129 7. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 45 130 7.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 131 7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45 132 7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45 133 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 134 8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47 135 8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47 136 8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48 137 8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48 138 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 139 9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49 140 9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50 141 9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 53 142 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 143 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 144 11.1. Normative References . . . . . . . . . . . . . . . . . . . 56 145 11.2. Informative References . . . . . . . . . . . . . . . . . . 57 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 147 Intellectual Property and Copyright Statements . . . . . . . . . . 59 149 1. Introduction 151 The Aggregate Server Access Protocol (ASAP) when used in conjunction 152 with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp] 153 provides a high availability data transfer mechanism over IP 154 networks. ASAP uses a handle-based addressing model which isolates a 155 logical communication endpoint from its IP address(es), thus 156 effectively eliminating the binding between the communication 157 endpoint and its physical IP address(es) which normally constitutes a 158 single point of failure. 160 When multiple receiver instances exist under the same handle (a.k.a, 161 a server pool),an ASAP endpoint will select one Pool Element (PE), 162 based on the current load sharing policy indicated by the server 163 pool, and deliver its message to the selected PE. 165 While delivering the message, ASAP can be used to monitor the 166 reachability of the selected PE. If it is found unreachable, before 167 notifying the message sender (an ASAP user) of the failure, ASAP can 168 automatically select another PE (if one exists) under that pool and 169 attempt to deliver the message to that PE. In other words, ASAP is 170 capable of transparent fail-over amongst PE instances within a server 171 pool. 173 ASAP depends on ENRP which provides a high availability pool handle 174 space. ASAP is responsible for the abstraction of the underlying 175 transport technologies, load distribution management, fault 176 management, as well as presentation to the upper layer (aka an ASAP 177 user) via a unified primitive interface. 179 When SCTP [RFC4960] is used as the transport layer protocol, ASAP can 180 seamlessly incorporate the link-layer redundancy provided by SCTP. 182 This document defines the ASAP portion of the high availability 183 server pool. 185 1.1. Definitions 187 This document uses the following terms: 189 ASAP user: Either a PE or PU that uses ASAP. 191 Business Card: When presented by a PU or PE it specifies the pool 192 the sender belongs to and provides a list of alternate PEs in case 193 of fail-overs. 195 Operational scope: The part of the network visible to pool users by 196 a specific instance of the reliable server pooling protocols. 198 Pool (or server pool): A collection of servers providing the same 199 application functionality. 201 Pool handle: A logical pointer to a pool. Each server pool will be 202 identifiable in the operational scope of the system by a unique 203 pool handle. 205 Pool element: A server entity having registered to a pool. 207 Pool user: A server pool user. 209 Pool element handle (or endpoint handle): A logical pointer to a 210 particular pool element in a pool, consisting of the pool handle 211 and a destination transport address of the pool element. 213 Handle space: A cohesive structure of pool handles and relations 214 that may be queried by an internal or external agent. 216 Home ENRP server: The ENRP server to which a PE or PU currently 217 sends all namespace service requests. A PE must only have one 218 home ENRP server at any given time and both the PE and its home 219 ENRP server MUST know and keep track of this relationship. A PU 220 should select one of the available ENRP servers as its Home ENRP 221 server but the collective ENRP servers may change this by the 222 sending or a ASAP_ENDPOINT_KEEP_ALIVE message. 224 ENRP client channel: The communication channel through which an ASAP 225 User sends all namespace service requests. The client channel is 226 usually defined by the transport address of the Home ENRP server 227 and a well known port number. The channel MAY make use of 228 multicast or a named list of ENRP servers. 230 Network Byte Order: Most significant byte first, a.k.a Big Endian. 232 Transport address: A Transport Address is traditionally defined by 233 Network Layer address, Transport Layer protocol and Transport 234 Layer port number. In the case of SCTP running over IP, a 235 transport address is defined by the combination of an IP address 236 and an SCTP port number (where SCTP is the Transport protocol). 238 1.2. Organization of this document 240 Section 2 details the ASAP message formats. In Section 3 we provide 241 detailed ASAP procedures for the ASAP implementer. Section 4 242 summarizes which messages needs to be supported by which nodes and 243 Section 5 describes the usage of SCTP. In Section 6 details of the 244 ASAP interface are given, focusing on the communication primitives 245 between ASAP the applications above ASAP and ASAP itself, and the 246 communications primitives between ASAP and SCTP (or other transport 247 layers). Also included in this discussion are relevant timers and 248 configurable parameters as appropriate. Section 7 provides threshold 249 and protocol variables. 251 It should be noted that variables, timers and constants are used in 252 the text when necessary. The complete list can be found in 253 Section 7. 255 1.3. Scope of ASAP 257 The requirements for high availability and scalability do not imply 258 requirements on shared state and data. ASAP does not provide 259 transaction failover. If a host or application fails during the 260 processing of a transaction, this transaction may be lost. Some 261 services MAY provide a way to handle the failure, but this is not 262 guaranteed. ASAP MAY provide hooks to assist an application in 263 building a mechanism to share state but ASAP in itself does NOT share 264 any state. 266 1.3.1. Extent of the Handlespace 268 The scope of ASAP/ENRP is NOT Internet wide. The handlespace is 269 neither hierarchical nor arbitrarily large like DNS. A flat peer-to- 270 peer model is detailed. Pools of servers will exist in different 271 administrative domains. For example, suppose the use of ASAP and 272 ENRP is wanted. First, the PU may use DNS to contact an ENRP server. 273 Suppose a PU in North America wishes to contact a server pool in 274 Japan instead of North America. The PU would use DNS to get the list 275 of IP addresses of the Japanese server pool, that is, the ENRP client 276 channel in Japan. From there the PU would query the Home ENRP server 277 it established and then directly contact the PE(s) of interest. 279 1.4. Conventions 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in [RFC2119]. 285 2. Message Definitions 287 All messages as well as their fields described below shall be in 288 Network Byte Order during transmission. For fields with a length 289 bigger than 4 bytes, a number in a pair of parentheses may follow the 290 field name to indicate the length of the field in number of bytes. 292 2.1. ASAP Parameter Formats 294 The basic message format and all parameter formats can be found in 295 [I-D.ietf-rserpool-common-param]. Note also that ALL ASAP messages 296 exchanged between an ENRP server and a PE MUST use SCTP as transport, 297 while ASAP messages exchanged between an ENRP server and a PU MUST 298 use either SCTP or TCP as transport. PE to PU data traffic MAY use 299 any transport protocol specified by the PE during registration. 301 2.2. ASAP Messages 303 This section details the individual messages used by ASAP. These 304 messages are composed of a standard message format found in Section 4 305 of [I-D.ietf-rserpool-common-param]. The parameter descriptions can 306 be found in [I-D.ietf-rserpool-common-param]. 308 The following ASAP message types are defined in this section: 310 Type Message Name 311 ----- ------------------------- 312 0x00 - (reserved by IETF) 313 0x01 - ASAP_REGISTRATION 314 0x02 - ASAP_DEREGISTRATION 315 0x03 - ASAP_REGISTRATION_RESPONSE 316 0x04 - ASAP_DEREGISTRATION_RESPONSE 317 0x05 - ASAP_HANDLE_RESOLUTION 318 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 319 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 320 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 321 0x09 - ASAP_ENDPOINT_UNREACHABLE 322 0x0a - ASAP_SERVER_ANNOUNCE 323 0x0b - ASAP_COOKIE 324 0x0c - ASAP_COOKIE_ECHO 325 0x0d - ASAP_BUSINESS_CARD 326 0x0e - ASAP_ERROR 328 Figure 1 330 2.2.1. ASAP_REGISTRATION message 332 The REGISTRATION message is sent by a PE to its Home ENRP Server to 333 either create a new pool or to add itself to an existing pool. The 334 PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle 335 parameter and the Pool Element parameter. The Pool Handle parameter 336 specifies the name to be registered. The Pool Element parameter MUST 337 be filled in by the registrant as outlined in Section 3.1. Note that 338 the PE sending the registration message MUST send the message using 339 an SCTP association. Furthermore the IP address(es) of the PE that 340 is registered within the Pool Element parameter MUST be a subset of 341 the IP address(es) used in the SCTP association regardless of the 342 registered transport protocol 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 : Pool Handle Parameter : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 : Pool Element Parameter : 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Pool Handle Parameter: 356 See [I-D.ietf-rserpool-common-param] 358 Pool Element Parameter: 360 See [I-D.ietf-rserpool-common-param] 362 2.2.2. ASAP_DEREGISTRATION message 364 The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP 365 Server to remove itself from a pool to which it registered. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 : Pool Handle Parameter : 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 : PE Identifier Parameter : 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 377 Pool Handle Parameter: 379 See [I-D.ietf-rserpool-common-param] 381 PE Identifier Parameter: 383 See [I-D.ietf-rserpool-common-param] 385 The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle 386 and the PE identifier parameter in order to allow the ENRP server to 387 verify the identity of the endpoint. Note that deregistration is NOT 388 allowed by proxy, in other words a PE may only deregister itself. 390 2.2.3. ASAP_REGISTRATION_RESPONSE message 392 The ASAP_REGISTRATION_RESPONSE message is sent in response by the 393 Home ENRP Server to the PE that sent a ASAP_REGISTRATION 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 = 0x03 |0|0|0|0|0|0|0|R| Message Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 : Pool Handle Parameter : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 : PE Identifier Parameter : 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 : Operational Error (optional) : 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 R (Reject) Flag: 409 When set to '1', this flag indicates that the ENRP server sending 410 this message has rejected the registration. Otherwise when this flag 411 is set to '0', this indicates the registration has been granted. 413 Pool Handle Parameter: 415 See [I-D.ietf-rserpool-common-param] 417 PE Identifier Parameter: 419 See [I-D.ietf-rserpool-common-param] 421 Operational Error Parameter (optional): 423 See [I-D.ietf-rserpool-common-param] 425 This parameter is included if an error or some atypical events 426 occurred during the registration process. When the R flag is set to 427 '1', this parameter, if present, indicates the cause of the 428 rejection. When the R flag is set to '0', this parameter, if 429 present, serves as a warning to the registering PE, informing it that 430 some of its registration values may have been modified by the ENRP 431 server. If the registration was successful and there is no warning, 432 this parameter is not included. 434 2.2.4. ASAP_DEREGISTRATION_RESPONSE message 436 The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP 437 Server to a PE in response to a ASAP_DEREGISTRATION message or due to 438 the expiration of the registration life of the PE in the pool 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 : Pool Handle Parameter : 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 : PE Identifier Parameter : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 : Operational Error (optional) : 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Pool Handle Parameter: 454 See [I-D.ietf-rserpool-common-param] 456 PE Identifier Parameter: 458 See [I-D.ietf-rserpool-common-param] 460 Operational Error: 462 See [I-D.ietf-rserpool-common-param] 464 This parameter is included if an error or some atypical events 465 occurred during the deregistration process. If the deregistration 466 was successful this parameter is not included. 468 2.2.5. ASAP_HANDLE_RESOLUTION message 470 The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to 471 its Home ENRP Server to resolve a pool handle into a list of pool 472 elements that are members of the pool indicated by the pool handle. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type = 0x05 |0|0|0|0|0|0|0|S| Message Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 : Pool Handle Parameter : 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 The 'S' bit: 484 The 'S' bit, if set to '1', requests the Home ENRP server to send 485 updates to this Pool dynamically when the Pool changes for the 486 lifetime of the SCTP association. Dynamic updates to the pool will 487 consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages, 488 without the user needing to send in a ASAP_HANDLE_RESOLUTION. 490 If the 'S' bit is set to '0' no dynamic updates are requested. 492 Note that if a new Home ENRP server is adopted any 'dynamic update 493 request' will need to be resent to the new Home ENPR server if the 494 endpoint would like to continue to receive updates. In other words, 495 the ENRP servers do NOT share state regarding which of its PU's are 496 requesting automatic update of state. Thus upon change of Home ENRP 497 Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message 498 with the 'S' bit set to 1. Note also, that the 'S' bit will only 499 cause dynamic update of a Pool when the Pool exists. If a negative 500 response is returned, no further updates to the Pool (when it is 501 created) will occur. 503 Pool Handle parameter: 505 See [I-D.ietf-rserpool-common-param] 507 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message 509 The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by 510 the Home ENRP server of the PU or PE that sent a 511 ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if 512 the PU as requested Dynamic updates. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type = 0x06 |0|0|0|0|0|0|0|A| Message Length | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 : Pool Handle Parameter : 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 : Overall PE Selection Policy (optional) : 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 : Pool Element Parameter 1 (optional) : 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 : ... : 526 : : 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 : Pool Element Parameter N (optional) : 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 : Operational Error (optional) : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 A bit: 535 This bit is set to '1' if the ENRP server accepts the request to send 536 automatic updates (i.e. the S bit was set on the request). If this 537 bit is set to '0' either the ENRP server does NOT support automatic 538 update, it has resource issues and cannot supply this feature or the 539 user did not request it. 541 Pool Handle parameter: 543 See [I-D.ietf-rserpool-common-param] 545 Overall PE Selection Policy (optional): 547 See [I-D.ietf-rserpool-common-param] 549 This parameter can be present when the response is positive. If 550 present, it indicates the overall pool member selection policy of the 551 pool. If not present, a round robin overall pool member selection 552 policy is assumed. This parameter is not present when the response 553 is negative. 555 Note, any load policy parameter within a Pool Element Parameter (if 556 present) MUST be ignored, and MUST NOT be used to determine the 557 overall pool member selection policy. 559 Pool Element Parameters (optional): 561 See [I-D.ietf-rserpool-common-param] 562 When the response is positive, an array of PE parameters are 563 included, indicating the current information about the PEs in the 564 named pool. At least one PE parameter MUST be present. When the 565 response is negative, no PE parameters are included. 567 Operational Error (optional): 569 See [I-D.ietf-rserpool-common-param] 571 The presence of this parameter indicates that the response is 572 negative (the handle resolution request was rejected by the ENRP 573 server). The cause code in this parameter (if present) will indicate 574 the reason the handle resolution request was rejected (e.g., the 575 requested pool handle was not found). The absence of this parmaeter 576 indicates that the response is positive. 578 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message 580 The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP Server to a 581 PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the 582 PE is reachable and requires the PE to adopt the sending server as 583 its new Home ENRP Server if the H bit is set to 1. Regardless of the 584 setting of the H bit, an ASAP endpoint MUST respond with an 585 ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages 586 that arrive. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Server Identifier | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 : Pool Handle Parameter : 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 H (Home ENRP server) flag 600 When set to '1', indicate that the ENRP server that sends this 601 message want to be the home ENRP server of the receiver of this 602 message. 604 Server Identifier: 32 bit (unsigned integer) 606 This is the ID of the ENRP server, as discussed in 607 [I-D.ietf-rserpool-enrp]. 609 Pool Handle parameter: 611 See [I-D.ietf-rserpool-common-param] . 613 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message 615 The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response 616 to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP Server. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 : Pool Handle Parameter : 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 : PE Identifier Parameter : 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Pool Handle parameter: 630 See [I-D.ietf-rserpool-common-param]. 632 PE Identifier parameter: 634 See [I-D.ietf-rserpool-common-param]. 636 2.2.9. ASAP_ENDPOINT_UNREACHABLE message 638 The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to 639 its Home ENRP Server to report an unreachable PE. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 : Pool Handle Parameter : 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 : PE Identifier Parameter : 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Pool Handle parameter: 653 See [I-D.ietf-rserpool-common-param]. 655 PE Identifier parameter: 657 See [I-D.ietf-rserpool-common-param]. 659 2.2.10. ASAP_SERVER_ANNOUNCE message 661 The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that 662 PUs and PEs know the transport information necessary to connect to 663 the ENRP server. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Server Identifier | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 : Transport param #1 : 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 : Transport param #2 : 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 : : 677 : ..... : 678 : : 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 : Transport param #n : 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Server Identifier: 32 bit (unsigned integer) 685 This is the ID of the ENRP server, as discussed in 686 [I-D.ietf-rserpool-enrp]. 688 Transport parameters (optional): 690 See [I-D.ietf-rserpool-common-param] for the SCTP and TCP Transport 691 parameters. 693 Only SCTP and TCP Transport parameters are allowed for use within the 694 SERVER_ANNOUNCE message. 696 2.2.11. ASAP_COOKIE message 698 The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to 699 convey information it wishes to share using a control channel. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 : Cookie Parameter : 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Cookie Parameter : 712 See [I-D.ietf-rserpool-common-param]. 714 2.2.12. ASAP_COOKIE_ECHO message 716 The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it 717 detects a failure with the current PE to aid in failover. The Cookie 718 Parameter sent by the PE is the latest one received from the failed 719 PE. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 : Cookie Parameter : 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Cookie Parameter: 731 See [I-D.ietf-rserpool-common-param]. 733 2.2.13. ASAP_BUSINESS_CARD message 735 The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE 736 to a PU using a control channel to convey the pool handle and a 737 preferred failover ordering. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 : Pool Handle Parameter : 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 : Pool Element Parameter-1 : 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 : .. : 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 : Pool Element Parameter-N : 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Pool Handle parameter: 755 See [I-D.ietf-rserpool-common-param]. 757 Pool Element parameters: 759 See [I-D.ietf-rserpool-common-param]. 761 2.2.14. ASAP_ERROR message 763 The ASAP_ERROR message is sent in response by an ASAP endpoint 764 receiving an unknown message or an unknown parameter to the sending 765 ASAP endpoint to report the problem or issue. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 : Operational Error Parameter : 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Operation Error parameter: 777 See [I-D.ietf-rserpool-common-param]. 779 When an ASAP endpoint receives an ASAP message with an unknown 780 message type or a message of known type that contains an unknown 781 parameter, it SHOULD handle the unknown message or the unknown 782 parameter according to the unrecognized message and parameter 783 handling rules defined in Section 3. 785 According to the rules, if an error report to the message sender is 786 needed, the ASAP endpoint that discovered the error SHOULD send back 787 an ASAP_ERROR message which includes an Operation Error parameter 788 with the proper cause code, cause length, and case specific 789 information. 791 3. Procedures 793 This section will focus on the methods and procedures used by an 794 internal ASAP endpoint. Appropriate timers and recovery actions for 795 failure detection and management are also discussed. Also please 796 note that ASAP messages, sent between a PE and PU are identified by 797 an SCTP Payload Protocol Identifier (PPID). 799 3.1. Registration 801 When a PE wishes to initiate or join a server pool it MUST use the 802 procedures outlined in this section for registration. Often, the 803 registration will be triggered by a user request primitive (discussed 804 in Section 6.1). The PE MUST register using an SCTP association 805 established between itself and the Home ENRP server. If the PE has 806 not established its Home ENRP server, it MUST follow the procedures 807 specified in Section 3.6. 809 Once the PE's ASAP endpoint has established its Home ENRP server the 810 following procedures MUST be followed to register: 812 R1) The PE's SCTP endpoint used to communicate with the Home ENRP 813 server MUST be bound to all IP addresses that will be used by the 814 PE (irregardless of what transport protocol will be used to 815 service user requests to the PE). 817 R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION 818 message as defined in Section 2.2.1. In formulating the message, 819 the PE MUST: 821 R2.1) Fill in the Pool Handle Parameter to specify which server 822 pool the ASAP endpoint wishes to join. 824 R2.2) Fill in the PE identifier using a good quality randomly 825 generated number ([RFC4086] provides some information on 826 randomness guidelines). 828 R2.3) Fill in the Registration Life time parameter with the 829 number of seconds that this registration is valid for. Note a 830 PE that wishes to continue service MUST re-register before the 831 registration expires. 833 R2.4) Fill in a User Transport Parameter to specify the type of 834 transport and the data/control channel usage the PE is willing 835 to support. Note, in joining an existing server pool, the PE 836 MUST follow the overall transport type and overall data/control 837 channel usage of the pool. Otherwise, the registration may be 838 rejected by the ENRP server. 840 R2.5) Fill in the preferred Pool Member Selection Policy 841 parameter. 843 R3) Send the Registration message to the Home ENRP server using 844 SCTP. 846 R4) Start a T2-registration timer. 848 Note: the PE does not need to fill in the optional ASAP transport 849 parameter. The ASAP transport parameter will be filled in and used 850 by the home ENRP server. 852 If the T2-registration timer expires before receiving an 853 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 854 received from the SCTP layer, the PE shall start the Server Hunt 855 procedure (see Section 3.6) in an attempt to get service from a 856 different ENRP server. After establishing a new Home ENRP server the 857 PE SHOULD restart the registration procedure. 859 At the reception of the registration response, the PE MUST stop the 860 T2-Registration timer. If the response indicates success, the PE is 861 registered and will be considered an available member of the server 862 pool. If the registration response indicates a failure, the PE must 863 either re-attempt registration after correcting the error or return a 864 failure indication to the PE's upper layer. The PE MUST NOT re- 865 attempt registration without correcting the error condition. 867 At any time a registered PE MAY wish to re-register to either update 868 its member selection policy value or registration expiration time. 869 When re-registering the PE MUST use the same PE identifier. 871 After successful registration the PE MUST start a T4-reregistration 872 timer. At its expiration a re-registration SHOULD be made starting 873 at step R1 including (at completion) restarting the T4-reregistration 874 timer. 876 Note that an implementation SHOULD keep a record of the number of 877 registration (and reregistration) attempts it makes in a local 878 variable that gets set to zero before the initial registration 879 attempt to the Home ENRP server or after a successful re- 880 registration.If repeated registration time-outs or failures occurs 881 and the local count exceeds the Threshold 'MAX-REG-ATTEMPT' the 882 implementation SHOULD report the error to its upper layer and stop 883 attempting registration. 885 The ENRP server handles the ASAP_REGISTRATION message according to 886 the following rules: 888 1. If the named pool does not exist in the handlespace, the ENRP 889 server MUST creates a new pool with that handle in the 890 handlespace and add the PE to the pool as its first PE; 892 When a new pool is created, the overall member selection policy 893 of the pool MUST be set to the policy type indicated by the first 894 PE, the overall pool transport type MUST be set to the transport 895 type indicated by the PE, and the overall pool data/control 896 channel configuration MUST be set to what is indicated in the 897 Transport Use field of the User Transport parameter by the 898 registering PE. 900 2. If the named pool already exists in the handlespace, but the 901 requesting PE is not currently a member of the pool, the ENRP 902 server will add the PE as a new member to the pool; 904 However, before adding the PE to the pool, the server MUST check 905 if the policy type, transport type, and transport usage indicated 906 by the registering PE is consistent with those of the pool. If 907 different, the ENRP server MUST reject the registration. 909 3. If the named pool already exists in the handlespace AND the 910 requesting PE is already a member of the pool, the ENRP server 911 SHOULD consider this as a re-registration case. The ENRP server 912 MUST perform the same tests on policy, transport type, transport 913 use, as described above. If the re-registration is accepted 914 after the test, the ENRP Server SHOULD replace the attributes of 915 the existing PE with the information carried in the received 916 ASAP_REGISTRATION message. 918 4. After accepting the registration, the ENRP server MUST assign 919 itself the owner of this PE. If this is a re-registration, the 920 ENRP server MUST take over ownership of this PE regardless of 921 whether the PE was previously owned by this server or by another 922 server. The ENRP server MUST also record the SCTP transport 923 address from which it received the ASAP_REGISTRATION in the ASAP 924 Transport parameter TLV inside the PE parameter of this PE. 926 5. The ENRP server may reject the registration due to other reasons 927 such as invalid values, lack of resource, authentication failure, 928 etc. 930 In all above cases, the ENRP server MUST reply to the requesting PE 931 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 932 accepted, the ENRP server MUST set the 'R' flag in the 933 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 934 the ENRP server MUST indicate the rejection by setting the 'R' flag 935 in the ASAP_REGISTRATION_RESPONSE to '1'. 937 If the registration is rejected, the ENRP server SHOULD include the 938 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 940 If the registration is granted (either a new registration or a re- 941 registration case), the ENRP server MUST assign itself to be the home 942 ENRP server of the PE, i.e., to "own" the PE. 944 Implementation note: for better performance, the ENRP server may 945 find it both efficient and convenient to internally maintain two 946 separate PE lists or tables - one is for the PEs that are "owned" 947 by the ENRP server and the other for all the PEs owned by its 948 peer(s). 950 Moreover, if the registration is granted, the ENRP server MUST take 951 the handlespace update action to inform its peers about the change 952 just made. If the registration is denied, no message will be sent to 953 its peers. 955 3.2. Deregistration 957 In the event a PE wishes to deregister from its server pool (normally 958 via an upper layer requests see Section 6.2), it SHOULD use the 959 following procedure. It should be noted that an alternate method of 960 deregistration is to NOT re-register and to allow the registration 961 life of the PE to expire. In this case a 962 ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP 963 endpoint to indicate the removal of the PE from the pool it 964 registered. 966 When deregistering the PE SHOULD use the SCTP association that was 967 used for registration with its Home ENRP server. To deregister, the 968 PE's ASAP endpoint MUST take the following actions: 970 D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION 971 message ( Section 2.2.2) using the same Pool Handle parameter sent 972 during registration. 974 D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION 975 message. The identifier MUST be the same as used during 976 registration. The use of the same Pool Handle and Pool Identifier 977 parameters used in registration allows the identity of the PE ASAP 978 endpoint be verified before deregistration can occur. 980 D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server 981 using the PE's SCTP association. 983 D4) Start a T3-Deregistration timer. 985 If the T3-Deregistration timer expires before receiving either a 986 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification 987 from the PE's SCTP endpint, the PE's ASAP endpoint shall start the 988 ENRP Server Hunt procedure (see Section 3.6) in an attempt to get 989 service from another ENRP server. After establishing a new Home ENRP 990 server, the ASAP endpoint SHOULD restart the deregistration 991 procedure. 993 At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP 994 endpoint MUST stop the T3-deregistration timer. 996 It should be noted that after a successful deregistration the PE MAY 997 still receive requests for some period of time. The PE MAY wish to 998 remain active and service these requests or to exit and ignore these 999 requests. 1001 Upon receiving the message, the ENRP server SHALL remove the PE from 1002 its handlespace. Moreover, if the PE is the last one of the named 1003 pool, the ENRP server will remove the pool from the handlespace as 1004 well. 1006 If the ENRP server fails to find any record of the PE in its 1007 handlespace, it SHOULD consider the de-registration granted and 1008 completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the 1009 PE. 1011 The ENRP server may reject the de-registration request for various 1012 reasons, such as invalid parameters, authentication failure, etc. 1014 In response, the ENRP server MUST send an 1015 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- 1016 registration is rejected, the ENRP server MUST indicate the rejection 1017 by including the proper Operational Error parameter. 1019 It should be noted that de-registration does not stop the PE from 1020 sending or receiving application messages. 1022 Once the de-registration request is granted AND the PE removed from 1023 its local copy of the handlespace, the ENRP server MUST take the 1024 handlespace update action to inform its peers about the change just 1025 made. Otherwise, the ENRP server MUST NOT inform its peers. 1027 3.3. Handle resolution 1029 At any time a PE or PU may wish to resolve a handle. This usually 1030 will occur when a ASAP Endpoint sends to a Pool handle ( 1031 Section 6.5.1) to its home ENRP server or requests a cache population 1032 (Section 6.3). It may also occur for other reasons (e.g. the 1033 internal ASAP PE wishes to know its peers for sending a message to 1034 all of them). When an ASAP Endpoint (PE or PU) wishes to resolve a 1035 pool handle to a list of accesible transport addresses of the member 1036 PEs of the pool, it MUST take the following actions: 1038 NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with 1039 the Pool Handle to be resolved. 1041 NR2) If the endpoint does not have a Home ENRP server start the ENRP 1042 Server Hunt procedures specified in Section 3.6 to obtain one. 1043 Otherwise, proceed to step NR3. 1045 NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the home 1046 ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION 1047 message to the Home ENRP server using either TCP or SCTP. If sent 1048 from a PE, the SCTP association used for registration SHOULD be 1049 used. 1051 NR4) Start a T1-ENRPrequest timer. 1053 If the T1-ENRPrequest timer expires before receiving a response 1054 message, the ASAP endpoint SHOULD take the steps described in 1055 Section 3.7.2. If a SEND.FAILURE notification is received from the 1056 SCTP or TCP layer, the ASAP endpoint SHOULD start the Server Hunt 1057 procedure (see Section 3.6) in an attempt to get service from a 1058 different ENRP server. After establishing a new Home ENRP server, 1059 the ASAP endpoint SHOULD restart the handle resolution procedure. 1061 At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message the 1062 ASAP endpoint MUST stop its T1-ENRPrequest timer. After stopping the 1063 T1-ENRPrequest timer the ASAP endpoint SHOULD process the message as 1064 appropriate (e.g. populate a local cache, give the response to the 1065 ASAP user, and/or use the response to send the ASAP users message). 1067 Note that some ASAP endpoints MAY use a cache to minimize the number 1068 of handle resolutions sent. If a cache is used, it SHOULD: 1070 C1) Be consulted before sending a handle resolution. 1072 C2) Have a stale timeout timer associated with each cache entry. If 1073 the cache entry is determined to be stale upon a cache hit, a 1074 handle resolution message SHOULD be sent so the cache can be 1075 updated. 1077 C3) In the case of a stale cache entry the implementation may in 1078 parallel update the cache and answer the request or it may block 1079 the user and wait for an updated cache before proceeding with the 1080 users request. 1082 C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a 1083 handle resolution request but instead SHOULD use the entry from 1084 the cache. 1086 It should be noted that the impact of using a cache depends on the 1087 policy and the requirements of the application. For some 1088 applications cache-usage can increase the performance of the system, 1089 for some it can decrease it. 1091 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1092 requests from PUs either over an SCTP association on the well-know 1093 SCTP port, or over a TCP connection on the well-know TCP port. 1095 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1096 MUST first look up the pool handle in its handlespace. If the pool 1097 exits, the home ENRP server MUST compose and send back an 1098 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1100 In the response message, the ENRP server SHOULD list all the PEs 1101 currently registered in this pool, in a list of PE parameters. The 1102 ENRP server MUST also include a pool member selection policy 1103 parameter to indicate the overall member selection policy for the 1104 pool, if the current pool member selection policy is not round-robin. 1106 If the named pool does not exist in the handlespace, the ENRP server 1107 MUST reject the handle resolution request by responding with an 1108 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Pool 1109 Handle error. 1111 3.4. Endpoint keep alive 1113 The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a 1114 PE in order to verify it is reachable. If the transport level heart 1115 beat mechanism is insufficient, this message can be used in a heart 1116 beat mechanism for the ASAP level whose goal is determining the 1117 health status of the ASAP level in a timely fashion. (The transport 1118 level heart beat mechanism may be insufficient due to either the time 1119 outs or the heart beat interval being set too long, or, that the 1120 transport level heart beat mechanism's coverage is limited only to 1121 the transport level at the two ends.) Additionally, the 1122 ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of 1123 fault detection if the SCTP stack is in the kernel. In such a case, 1124 while SCTP level heartbeat monitors the end-to-end connectivity 1125 between the two SCTP stacks, the ASAP level heartbeat monitors the 1126 end-to-end liveliness of the ASAP layer above it. 1128 The use of the ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7) and 1129 the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. 1130 Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following 1131 actions MUST be taken: 1133 KA1) The PE must verify that the Pool Handle is correct and matches 1134 the Pool Handle sent in its earlier ASAP_REGISTRATION message. If 1135 the Pool Handle does not match, the PE MUST silently discard the 1136 message. 1138 KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as 1139 follows: 1141 KA2.1) Fill in the Pool Handle Parameter with the PE's Pool 1142 Handle. 1144 KA2.2) Fill in the PE Identifier parameter using the PE 1145 identifier used by this PE for registration. 1147 KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the 1148 appropriate SCTP association for the ENRP server which sent the 1149 ASAP_ENDPOINT_KEEP_ALIVE message. 1151 KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE 1152 message is set, and the Server Identifier in the message is NOT 1153 the identity of your Home ENRP server (or it is not set e.g you 1154 have a no Home ENRP server) adopt the sender of the 1155 ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server. 1157 3.5. Unreachable endpoints 1159 Occasionally, an ASAP endpoint may realize a PE is unreachable. This 1160 may occur by a specific SCTP error realized by the ASAP endpoint or 1161 via an ASAP user report via the Transport.Failure Primitive 1162 (Section 6.9.2). In either case, the ASAP endpoint SHOULD report the 1163 unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE 1164 message to any ENRP server. Before sending the 1165 ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in 1166 the Pool Handle parameter and PE identifier parameter of the 1167 unreachable endpoint. If the sender is a PE, the message MUST be 1168 sent via SCTP. It should be noted that an ASAP endpoint MUST report 1169 no more than once each time it encounters such an event. 1170 Additionally, when processing a Transport.Failure Primitive 1171 (Section 6.9.2) the ASAP endpoint MUST NOT send an 1172 ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous 1173 request to send data to the PE specified by the primitive. 1175 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1176 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1177 message to the PE in question (the 'H' flag in the message SHOULD be 1178 set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails 1179 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP 1180 server MUST consider the PE as truly unreachable and MUST remove the 1181 PE from its handlespace. 1183 If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully 1184 to the PE, the ENRP server MUST retain the PE in its handlespace. 1185 Moreover, the server SHOULD keep a counter to record how many 1186 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1187 reachability problem relating to this PE. If the counter exceeds the 1188 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1189 the PE from its handlespace. 1191 Optionally, an ENRP server may also periodically send point-to-point 1192 ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each 1193 of the PEs owned by the ENRP server in order to check their 1194 reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE 1195 fails, the ENRP server MUST consider the PE as unreachable and MUST 1196 remove the PE from its handlespace . Note, if an ENRP server owns a 1197 large number of PEs, the implementation should pay attention not to 1198 flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. 1199 Instead, the implementation MUST distribute the 1200 ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This 1201 can be achieved by varying the time between two 1202 ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/ 1203 minus 50 percent. 1205 3.6. ENRP server hunt procedures 1207 Each PU and PE manages a list of transport addresses of ENRP servers 1208 it knows about. 1210 If multicast capabilities are used within the operational scope an 1211 ENRP server MUST send periodically every (N+1)*T6-Serverannounce an 1212 ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the 1213 transport addresses available for ASAP communication on the multicast 1214 ENRP client channel where N is the number of ENRP servers the server 1215 has found via receiving ASAP_SERVER_ANNOUNCE messages. This should 1216 result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per 1217 T6-Serverannounce. 1219 If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it 1220 SHOULD insert all new included transport addresses into its list of 1221 ENRP server addresses and start a T7-ENRPoutdate timer for each 1222 address. For all already known included transport addresses, the T7- 1223 ENRPoutdate timer MUST be restarted for each address. If no 1224 transport parameters are included in the ASAP_SERVER_ANNOUNCE 1225 message, the SCTP transport protocol is assumed to be used and the 1226 source IP address and the IANA registered ASAP port number is used 1227 for communication with the ENRP server. If a T7-ENRPoutdate timer 1228 for a transport address expires, the corresponding address is deleted 1229 from the managed list of transport addresses of the PU or PE. 1231 If multicast capabilities are not used within the operational scope, 1232 each PU and PE MUST have a configured list of transport addresses of 1233 ENRP servers. 1235 At its startup or when it fails to communicate with its home ENRP 1236 server (i.e., timed-out on a ENRP request), a PE or PU MUST establish 1237 a new Home ENRP server (i.e. setup a TCP connection or SCTP 1238 association with a different ENRP server). 1240 To establish a home ENRP server the following rules MUST be followed: 1242 SH1) The PE or PU SHOULD try to establish an association or 1243 connection with no more than three ENRP server's. An ASAP 1244 endpoint MUST NOT establish more than three associations or 1245 connections. 1247 SH2) The ASAP endpoint shall start a T5-Serverhunt timer. 1249 SH3) If the ASAP endpoint establishes an association or connection 1250 it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD 1251 also reset the T5-Serverhunt timer to its initial value and then 1252 proceed to step SH6. 1254 SH4) If an association or connection establishment fails, the ASAP 1255 endpoint SHOULD try to establish an association or connection 1256 using a different transport address. 1258 SH5) If the T5-Serverhunt timer expires the following should be 1259 performed: 1261 SH5.1) The ASAP endpoint MUST double the value of the T5- 1262 Serverhunt timer. Note that this doubling is capped at the 1263 value RETRAN.max 1265 SH5.2) The ASAP endpoint SHOULD stop the establishment of 1266 associations and connections with the transport addresses 1267 selected in step SH1. 1269 SH5.2) The ASAP endpoint SHOULD repeat trying to establish an 1270 association or connection by proceeding to step SH1. It SHOULD 1271 attempt to select a different set of transport addresses with 1272 which to connect. 1274 SH6) The PE or PU shall pick one of the ENRP servers with which it 1275 was able to establish an association or connection, and send all 1276 subsequent ENRP request messages to this new Home ENRP server. 1278 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures 1280 Three types of failure may occur when the ASAP endpoint at ether PE 1281 or PU tries to communicate with an ENRP server: 1283 A) SCTP send failure 1285 B) T1-ENRPrequest timer expiration 1287 C) Registration failure 1289 3.7.1. SCTP Send Failure 1291 This communication failure indicates that the SCTP layer was unable 1292 to deliver a message sent to an ENRP server. In other words, the 1293 ENRP server is unreachable. 1295 In such a case, the ASAP endpoint MUST NOT re-send the undeliverable 1296 message. Instead, it SHOULD discard the message and start the ENRP 1297 server hunt procedure as described in Section 3.6 . After finding a 1298 new Home ENRP server, the ASAP endpoint should re-send the request. 1300 Note that an ASAP endpoint MAY also choose to NOT discard the 1301 message, but to queue it for retransmission after a new Home ENRP 1302 server is found. If an ASAP endpoint does choose to discard the 1303 message, after a new Home ENRP server is found, the ASAP endpoint 1304 MUST be capable of reconstructing the original request. 1306 3.7.2. T1-ENRPrequest Timer Expiration 1308 When the T1-ENRPrequest timer expires, the ASAP endpoint should 1309 resend the original request to the ENRP server and restart the T1- 1310 ENRPrequest timer. In parallel, the ASAP endpoint should begin the 1311 ENRP server hunt procedures described in Section 3.6. 1313 This should be repeated up to MAX-REQUEST-RETRANSMIT times. After 1314 that, an Error.Report notification should be generated to inform the 1315 ASAP user and the ENRP request message associated with the T1- 1316 ENRPrequest timer should be discarded. It should be noted that if an 1317 alternate ENRP server responds the ASAP endpoint SHOULD adopt the 1318 responding ENRP server as its new Home ENRP server and resend the 1319 request to the new Home ENRP server. 1321 3.7.3. Registration Failure 1323 Registration failure is discussed in Section 3.1. 1325 3.8. Cookie handling procedures 1327 Whenever a PE wants, and a control channel exists, it can send an 1328 ASAP_COOKIE message to a PU via the control channel. The PU's ASAP 1329 endpoint stores the Cookie parameter and discards an older cookie if 1330 it is previously stored. 1332 Note: a control channel is a communication channel between a PU and 1333 PE that does not carry data passed to the user. This is accomplished 1334 with SCTP by using a PPID to separate the ASAP messages (Cookie and 1335 Business Card) from normal data messages. 1337 If the PU's ASAP endpoint detects a failure and initiates a failover 1338 to a different PE, it SHOULD send the lastest received cookie 1339 parameter in an ASAP_COOKIE_ECHO message to the new PE as the first 1340 message on the control channel. Upper layers may be involved in the 1341 failover procedure. 1343 The cookie handling procedure can be used for state sharing. 1344 Therefore a cookie should be signed by the sending PE ASAP endpoint 1345 and the cookie should be verified by the receiving PE's ASAP 1346 endpoint. The details of the verification procedure are out of scope 1347 for this document. It is only important that the PU always stores 1348 the last received Cookie Parameter and sends that back unmodified in 1349 case of a PE failure. 1351 3.9. Business Card handling procedures 1353 When communication begins between a PU and a PE either of which could 1354 be part of a PU/PE combination (i.e. a message is sent between the 1355 entities), a PE should always send a ASAP_BUSINESS_CARD message to a 1356 PU. A PU should send a ASAP_BUSINESS_CARD message to a PE only if it 1357 is part of a PU/PE combination. A ASAP_BUSINESS_CARD message MUST 1358 ONLY be sent if a control channel exists between a PU and PE. After 1359 communication as been established between a PE and PU, a new 1360 ASAP_BUSINESS_CARD message may be sent at any time by either entity 1361 to update its failover order. 1363 The ASAP_BUSINESS_CARD message serves two purposes. First it lists 1364 the pool handle. For a PU which is part of a PU/PE combination which 1365 is contacting a PE this is essential so that the PE learns the pool 1366 handle of the PU/PE combination requesting service. Secondly the 1367 ASAP_BUSINESS_CARD message tells the receiving entity a failover 1368 order that is recommended to follow. This should facilitate 1369 rendezvous between entities that have been working together as well 1370 to control the load redistribution upon the failure of any PE. 1372 Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13) 1373 the receiving ASAP endpoint SHOULD: 1375 BC1) Unpack the message and if no entry exists in the translation 1376 cache of the receiving ASAP endpoint for the pool handle listed 1377 within the ASAP_BUSINESS_CARD message perform a 1378 ASAP_HANDLE_RESOLUTION for that pool handle. If the translation 1379 cache does hold an entry for the pool handle, then it may be 1380 necessary to update the peer endpoint. 1382 BC2) Unpack the message and populate a preferred list for failover 1383 order. If the peers PE should fail this preferred list will be 1384 used guide the ASAP endpoint in the selection of an alternate PE. 1386 4. Roles of Endpoints 1388 A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION, and 1389 ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore it MUST 1390 support the handling of ASAP_ERROR messages. It MAY implement the 1391 handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD 1392 messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE 1393 messages. 1395 A PE MUST implement the handling of ASAP_REGISTRATION, 1396 ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and 1397 ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support 1398 the handling of ASAP_ENDPOINT_KEEP_ALIVE, 1399 ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and 1400 ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE, 1401 ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore it 1402 MAY support the handling of ASAP_SERVER_ANNOUNCE messages. 1404 An ENRP server MUST implement the handling of ASAP_REGISTRATION, 1405 ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and 1406 ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support 1407 the handling of ASAP_ENDPOINT_KEEP_ALIVE, 1408 ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and 1409 ASAP_ERROR messages. Furthermore it MAY support the handling of 1410 ASAP_SERVER_ANNOUNCE messages. 1412 If a node acts as a PU and a PE, it MUST fullfil both roles. 1414 5. SCTP Considerations 1416 Each ASAP message is considered as an SCTP user message. The PPID 1417 registered for ASAP SHOULD be used. The SCTP port used at the ENRP 1418 server might be preconfigured or announced in the 1419 ASAP_SERVER_ANNOUNCE message or the well known ASAP port. 1421 ASAP messages beloning to the control channel MUST be sent using the 1422 PPID registered for ASAP. Messages belonging to the data channel 1423 MUST NOT use the PPID registered for ASAP. 1425 6. The ASAP Interfaces 1427 This chapter will focus primarily on the primitives and notifications 1428 that form the interface between the ASAP-user and ASAP and that 1429 between ASAP and its lower layer transport protocol (e.g., SCTP). 1431 Note, the following primitive and notification descriptions are shown 1432 for illustrative purposes. We believe that including these 1433 descriptions in this document is important to the understanding of 1434 the operation of many aspects of ASAP. But an ASAP implementation is 1435 not required to use the exact syntax described in this section. 1437 An ASAP User passes primitives to the ASAP sub-layer to request 1438 certain actions. Upon the completion of those actions or upon the 1439 detection of certain events, the ASAP layer will notify the ASAP 1440 user. 1442 6.1. Registration.Request Primitive 1444 Format: registration.request(poolHandle, 1445 User Transport parameter(s)) 1447 The poolHandle parameter contains a NULL terminated ASCII string of 1448 fixed length. The optional User Transport parameter(s) indicate 1449 specific transport parameters and types to register with. If this 1450 optional parameter is left off, then the SCTP endpoint used to 1451 communicate with the ENRP server is used as the default User 1452 Transport parameter. Note that any IP address contained within a 1453 User Transport parameter MUST be a bound IP address in the SCTP 1454 endpoint used to communicate with the ENRP server. 1456 The ASAP user invokes this primitive to add itself to the 1457 handlespace, thus becoming a Pool Element of a pool. The ASAP user 1458 must register itself with the ENRP server by using this primitive 1459 before other ASAP users using the handlespace can send message(s) to 1460 this ASAP user by Pool Handle or by PE handle (see Section 6.5.1 and 1461 Section 6.5.3). 1463 In response to the registration primitive, the ASAP endpoint will 1464 send an ASAP_REGISTRATION message to the home ENRP server (See 1465 Section 2.2.1 and Section 3.1), and start a T2-registration timer. 1467 6.2. Deregistration.Request Primitive 1469 Format: deregistration.request(poolHandle) 1471 The ASAP PE invokes this primitive to remove itself from the Server 1472 Pool. This should be used as a part of the graceful shutdown process 1473 by the application. 1475 A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the 1476 home ENRP server (see Section 2.2.2 and Section 3.2). 1478 6.3. CachePopulateRequest Primitive 1480 Format: cache_populate_request([Pool-Handle | 1481 Pool-Element-Handle]) 1483 If the address type is a Pool handle and a local handle translation 1484 cache exists, the ASAP endpoint should initiate a mapping information 1485 query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle 1486 and update it local cache when the response comes back from the ENRP 1487 server. 1489 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 1490 from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message 1491 is sent to the ENRP server for resolution. When the response message 1492 returns from the ENRP server the local cache is updated. 1494 Note that if the ASAP service does NOT support a local cache this 1495 primitive performs NO action. 1497 6.4. CachePurgeRequest Primitive 1499 Format: cache_purge_request([Pool-Handle | Pool-Element-Handle]) 1501 If the user passes a Pool handle and local handle translation cache 1502 exists, the ASAP endpoint should remove the mapping information on 1503 the Pool handle from its local cache. If the user passes a Pool- 1504 Element-Handle then the Pool handle within is used for the 1505 cache_purge_request. 1507 Note that if the ASAP service does NOT support a local cache this 1508 primitive performs NO action. 1510 6.5. DataSendRequest Primitive 1512 Format: data_send_request(destinationAddress, typeOfAddress, 1513 message, sizeOfMessage, Options); 1515 This primitive requests ASAP to send a message to some specified Pool 1516 or Pool Element within the current Operational scope. 1518 Depending on the address type used for the send request, the senders 1519 ASAP endpoint may perform address translation and Pool Element 1520 selection before sending the message out. This also MAY dictate the 1521 creation of a local transport endpoint in order to meet the required 1522 transport type. 1524 The data_send_request primitive can take different forms of address 1525 types as described in the following sections. 1527 6.5.1. Sending to a Pool Handle 1529 In this case the destinationAddress and typeOfAddress together 1530 indicates a pool handle. 1532 This is the simplest form of send_data_request primitive. By 1533 default, this directs ASAP to send the message to one of the Pool 1534 Elements in the specified pool. 1536 Before sending the message out to the pool, the senders ASAP endpoint 1537 MUST first perform a pool handle to address translation. It may also 1538 need to perform Pool Element selection if multiple Pool Elements 1539 exist in the pool. 1541 If the senders ASAP implementation does not support a local cache of 1542 the mapping information or if it does not have the mapping 1543 information on the pool in its local cache, it will transmit a 1544 ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to 1545 the current home ENRP server, and MUST hold the outbound message in 1546 queue while awaiting the response from the ENRP server (any further 1547 send request to this pool before the ENRP server responds SHOULD also 1548 be queued). 1550 Once the necessary mapping information arrives from the ENRP server, 1551 the senders ASAP will: 1553 A) map the pool handle into a list of transport addresses of the 1554 destination PE(s), 1556 B) if multiple PEs exist in the pool, ASAP will choose one of them 1557 and transmit the message to it. In that case, the choice of the 1558 PE is made by ASAP endpoint of the sender based on the server 1559 pooling policy as discussed in Section 6.5.2 1561 C) Optionally create any transport endpoint that may be needed to 1562 communicate with the PE selected. 1564 D) if no transport association or connection exists towards the 1565 destination PE, ASAP will establish any needed transport state, 1567 E) send out the queued message(s) to the appropriate transport 1568 connection using the appropriate send mechanism (e.g. for SCTP the 1569 SEND primitive in [RFC4960] would be used), and, 1571 F) if the local cache is implemented, append/update the local cache 1572 with the mapping information received in the ENRP server's 1573 response. Also, record the local transport information (e.g. the 1574 SCTP association id) if any new transport state was created. 1576 For more on the ENRP server request procedures see 1577 [I-D.ietf-rserpool-enrp]. 1579 Optionally, the ASAP endpoint of the sender may return a Pool Element 1580 handle of the selected PE to the application after sending the 1581 message. This PE handle can then be used for future transmissions to 1582 that same PE (see Section 6.5.3). 1584 Section 3.7 defines the fail-over procedures for cases where the 1585 selected PE is found unreachable. 1587 6.5.2. Pool Element Selection 1589 Each time an ASAP user sends a message to a pool that contains more 1590 than one PE, the senders ASAP endpoint must select one of the PEs in 1591 the pool as the receiver of the current message. The selection is 1592 done according to the current server pooling policy of the pool to 1593 which the message is sent. 1595 Note, no selection is needed if the ASAP_SEND_TOALL option is set 1596 (see Section 6.5.5). 1598 Together with the server pooling policy, each PE can also specify a 1599 Policy Value for itself at the registration time. The meaning of the 1600 policy value depends on the current server pooling policy of the 1601 group. A PE can also change its policy value whenever it desires, by 1602 re-registering itself with the handlespace with a new policy value. 1603 Re-registration shall be done by simply sending another 1604 ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). 1606 One basic policy is defined in this document, others can be found in 1607 [I-D.ietf-rserpool-policies] 1609 6.5.2.1. Round Robin Policy 1611 When an ASAP endpoint sends messages by Pool Handle and Round-Robin 1612 is the current policy of that Pool, the ASAP endpoint of the sender 1613 will select the receiver for each outbound message by round-Robining 1614 through all the registered PEs in that Pool, in an attempt to achieve 1615 an even distribution of outbound messages. Note that in a large 1616 server pool, the ENRP server might not send back all PEs to the ASAP 1617 client. In this case the client or PU will be performing a round 1618 robin policy on a subset of the entire Pool. 1620 6.5.3. Sending to a Pool Element Handle 1622 In this case the destinationAddress and typeOfAddress together 1623 indicate an ASAP Pool Element handle. 1625 This requests the ASAP endpoint to deliver the message to the PE 1626 identified by the Pool Element handle. 1628 The Pool Element handle should contain the Pool Handle and a 1629 destination transport address of the destination PE or the Pool 1630 Handle and the transport type. Other implementation dependent 1631 elements may also be cached in a Pool Element handle. 1633 The ASAP endpoint shall use the transport address and transport type 1634 to identify the endpoint to communicate with. If no communication 1635 state exists with the peer endpoint (and is required by the transport 1636 protocol) the ASAP endpoint MAY setup the needed state and then 1637 invoke the SEND primitive for the particular transport protocol to 1638 send the message to the PE. 1640 In addition, if a local translation cache is supported the endpoint 1641 will: 1643 A) send out the message to the transport address (or association id) 1644 designated by the PE handle. 1646 B) determine if the Pool Handle is in the local cache. 1648 If it is NOT, the endpoint will: 1650 i) ask the home ENRP server for handle resolution on pool handle 1651 by sending an ASAP_HANDLE_RESOLUTION message (see 1652 Section 2.2.5), and 1654 ii) use the response to update the local cache. 1656 If the pool handle is in the cache, the endpoint will only 1657 update the pool handle if the cache is stale. A stale cache is 1658 indicated by it being older than the protocol parameter 1659 'stale.cache.value' (see Section 7.2). 1661 Section 3.5 and Section 6.9 defines the fail-over procedures for 1662 cases where the PE pointed to by the Pool Element handle is found 1663 unreachable. 1665 Optionally, the ASAP endpoint may return the actual Pool Element 1666 handle to which the message was sent (this may be different from the 1667 Pool Element handle specified when the primitive is invoked, due to 1668 the possibility of automatic fail-over). 1670 6.5.4. Send by Transport Address 1672 In this case the destinationAddress and typeOfAddress together 1673 indicate a transport address and transport type. 1675 This directs the senders ASAP endpoint to send the message out to the 1676 specified transport address. 1678 No endpoint fail-over is support when this form of send request is 1679 used. This form of send request effectively by-passes the ASAP 1680 endpoint. 1682 6.5.5. Message Delivery Options 1684 The Options parameter passed in the various forms of the above 1685 data_send_request primitive gives directions to the senders ASAP 1686 endpoint on special handling of the message delivery. 1688 The value of the Options parameter is generated by bit-wise "OR"ing 1689 of the following pre-defined constants: 1691 ASAP_USE_DEFAULT: 0x0000 Use default setting. 1693 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 1694 case where the first selected PE or the PE pointed to by the PE 1695 handle is found unreachable, the sender's ASAP endpoint SHOULD re- 1696 select an alternate PE from the same pool if one exists, and 1697 silently re-send the message to this newly selected endpoint. 1699 Note that this is a best-effort service. Applications should be 1700 aware that messages can be lost during the failover process, even 1701 if the underlying transport supports retrieval of unacknowledged 1702 data (e.g. SCTP) (Example: messages acknowledged by the SCTP 1703 layer at a PE, but not yet read by the PE when a PE failure 1704 occurs.) In the case where the underlying transport does not 1705 support such retrieval (e.g. TCP), any data already submitted by 1706 ASAP to the transport layer may be lost upon failover. 1708 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP 1709 endpoint from re-sending the message to any alternate PE in case 1710 that the first selected PE or the PE pointed to by the PE handle 1711 is found unreachable. Instead, the senders ASAP endpoint shall 1712 notify its upper layer about the unreachability with an 1713 Error.Report and return any unsent data. 1715 ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 1716 endpoint to send the message to the same PE in the pool that the 1717 previous message destined to this pool was sent to. 1719 ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option 1720 directs the senders ASAP endpoint to send a copy of the message to 1721 all the PEs, except for the sender itself if the sender is a PE, 1722 in that pool. 1724 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination 1725 with ASAP_SEND_TO_ALL option. It permits the senders ASAP 1726 endpoint also deliver a copy of the message to itself if the 1727 sender is a PE of the pool (i.e., loop-back). 1729 ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer 1730 to send the current message using un-ordered delivery (note the 1731 underlying transport must support un-ordered delivery for this 1732 option to be effective). 1734 6.6. Data.Received Notification 1736 Format: data.received(messageReceived, sizeOfMessage, 1737 senderAddress, typeOfAddress) 1739 When a new user message is received, the ASAP endpoint of the 1740 receiver uses this notification to pass the message to its upper 1741 layer. 1743 Along with the message being passed, the ASAP endpoint of the 1744 receiver should also indicate to its upper layer the message senders 1745 address. The senders address can be in the form of either an SCTP 1746 association id, TCP transport address, UDP transport address, or an 1747 ASAP Pool Element handle. 1749 A) If the handle translation local cache is implemented at the 1750 receiver's ASAP endpoint, a reverse mapping from the senders IP 1751 address to the pool handle should be performed and if the mapping 1752 is successful, the senders ASAP Pool Element handle should be 1753 constructed and passed in the senderAddress field. 1755 B) If there is no local cache or the reverse mapping is not 1756 successful, the SCTP association id or other transport specific 1757 identification (if SCTP is not being used) should be passed in the 1758 senderAddress field. 1760 6.7. Error.Report Notification 1762 Format: error.report(destinationAddress, typeOfAddress, 1763 failedMessage, sizeOfMessage) 1765 An error.report should be generated to notify the ASAP user about 1766 failed message delivery as well as other abnormalities. 1768 The destinationAddress and typeOfAddress together indicates to whom 1769 the message was originally sent. The address type can be either a 1770 ASAP Pool Element handle, association id, or a transport address. 1772 The original message (or the first portion of it if the message is 1773 too big) and its size should be passed in the failedMessage and 1774 sizeOfMessage fields, respectively. 1776 6.8. Examples 1778 These examples assume an underlying SCTP transport between the PE and 1779 PU. Other transports are possible but SCTP is utilized in the 1780 examples for illustrative purposes. Note that all communication 1781 between PU and ENRP server and PE and ENRP servers would be using 1782 SCTP. 1784 6.8.1. Send to a New Pool 1786 This example shows the event sequence when a Pool User sends the 1787 message "hello" to a pool which is not in the local translation cache 1788 (assuming local caching is supported). 1790 ENRP Server PU new-handle:PEx 1792 | | | 1793 | +---+ | 1794 | | 1 | | 1795 |2. ASAP_HANDLE_RESOLUTION +---+ | 1796 |<-------------------------------| | 1797 | +---+ | 1798 | | 3 | | 1799 |4. ASAP_HANDLE_RESOLUTION_RSP +---+ | 1800 |------------------------------->| | 1801 | +---+ | 1802 | | 5 | | 1803 | +---+ 6. "hello1" | 1804 | |---------------->| 1805 | | | 1807 1) The user at PU invokes: 1809 data_send_request("new-handle", handle-type, "hello1", 6, 0); 1811 The ASAP endpoint, in response, looks up the pool "new-handle" in 1812 its local cache but fails to find it. 1814 2) The ASAP endpoint of PU queues the message, and sends an 1815 ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all 1816 information about pool "new-handle". 1818 3) A T1-ENRPrequest timer is started while the ASAP endpoint is 1819 waiting for the response from the ENRP server. 1821 4) The ENRP Server responds to the query with an 1822 ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the 1823 information about pool "new-handle". 1825 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 1826 cache with information on pool "new-handle". 1828 6) Based on the server pooling policy of pool "new-handle", ASAP at 1829 PU selects the destination PE (PEx), sets up, if necessary, an 1830 SCTP association towards PEx (explicitly or implicitly), and send 1831 out the queued "hello1" user message. 1833 6.8.2. Send to a Cached Pool Handle 1835 This shows the event sequence when the ASAP user PU sends another 1836 message to the pool "new-handle" after what happened in 1837 Section 6.8.1. 1839 ENRP Server PU new-handle:PEx 1841 | | | 1842 | +---+ | 1843 | | 1 | | 1844 | +---+ 2. "hello2" | 1845 | |---------------->| 1846 | | | 1848 1) The user at PU invokes: 1850 pdata_send_request("new-handle", handle-type, "hello2", 6, 0); 1852 The ASAP endpoint, in response, looks up the pool "new-handle" in 1853 its local cache and find the mapping information. 1855 2) Based on the server pooling policy of "new-handle", ASAP at PU 1856 selects the PE (assume EPx is selected again), and sends out 1857 "hello2" message (assume the SCTP association is already set up). 1859 6.9. PE send failure 1861 When the ASAP endpoint in a PE or PU attempts to send a message to a 1862 PE and fails the failed sender will report the event as described in 1863 Section 3.5 . 1865 Additional primitive are also defined in this section to support 1866 those user applications that do not wish to use ASAP as the actual 1867 transport. 1869 6.9.1. Translation.Request Primitive 1871 Format: translation.request(Pool-Handle) 1873 If the address type is a Pool handle and a local handle translation 1874 cache exists, the ASAP endpoint should look within its translation 1875 cache and return the current known transport types, ports and 1876 addresses to the caller. 1878 If the Pool handle does not exist in the local handle cache or no 1879 handle cache exists, the ASAP endpoint will send an 1880 ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon 1881 completion of the handle resolution, the ASAP endpoint should 1882 populate the local handle cache (if a local handle cache is 1883 supported) and return the transport types, ports and addresses to the 1884 caller. 1886 6.9.2. Transport.Failure Primitive 1888 Format: transport.failure(Pool-Handle, Transport-address) 1890 If an external user encounters a failure in sending to a PE and is 1891 NOT using ASAP it can use this primitive to report the failure to the 1892 ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the 1893 "home" ENRP server in response to this primitive. Note ASAP SHOULD 1894 NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually 1895 made a previous request to send data to the PE. 1897 7. Timers, Variables, and Thresholds 1899 The following is a summary of the timers, variables, and pre-set 1900 protocol constants used in ASAP. 1902 7.1. Timers 1904 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1905 the ENRP server (providing application information is queued). 1906 Normally set to 15 seconds. 1908 T2-registration - A timer started when sending an ASAP_REGISTRATION 1909 request to the home ENRP server, normally set to 30 seconds. 1911 T3-deregistration - A timer started when sending a deregistration 1912 request to the home ENRP server, normally set to 30 seconds. 1914 T4-reregistration - This timer is started after successful 1915 registration into the ENRP handle space and is used to cause a re- 1916 registration at a periodic interval. This timer is normally set 1917 to 10 minutes or 20 seconds less than the Life Timer parameter 1918 used in the registration request (whichever is less). 1920 T5-Serverhunt - This timer is used during the ENRP server hunt 1921 procedure and is normally set to 10 seconds. 1923 T6-Serverannounce - This timer gives the time between the sending of 1924 consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1925 1 second. 1927 T7-ENRPoutdate - This timer gives the time a server announcement is 1928 valid. It is normally set to 5 seconds. 1930 7.2. Variables 1932 stale_cache_value - A threshold variable that indicates how long a 1933 cache entry is valid for. 1935 7.3. Thresholds 1937 MAX-REG-ATTEMPT - The maximum number of registration attempts to be 1938 made before a server hunt is issued. The default value of this is 1939 set to 2. 1941 MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made 1942 when requesting information from the local ENRP server before a 1943 server hunt is issued. The default value for this is 2. 1945 RETRAN-MAX - This value represents the maximum time between 1946 registration attmempts and puts a ceiling on how far the 1947 registration timer will back-off. The default value for this is 1948 normally set to 60 seconds. 1950 8. IANA Considerations 1952 [NOTE to RFC-Editor: 1954 "RFCXXXX" is to be replaced by the RFC number you assign this 1955 document. 1957 ] 1959 This document (RFCXXX) is the reference for all registrations 1960 described in this section. All registrations need to be listed on an 1961 RSerPool specific page. 1963 8.1. A New Table for ASAP Message Types 1965 ASAP Message Types have to be maintained by IANA. Fourteen initial 1966 values should be assigned by IANA as described in Figure 1. This 1967 requires a new table "ASAP Message Types": 1969 Type Message Name Reference 1970 ----- ------------------------- --------- 1971 0x00 (reserved by IETF) RFCXXXX 1972 0x01 ASAP_REGISTRATION RFCXXXX 1973 0x02 ASAP_DEREGISTRATION RFCXXXX 1974 0x03 ASAP_REGISTRATION_RESPONSE RFCXXXX 1975 0x04 ASAP_DEREGISTRATION_RESPONSE RFCXXXX 1976 0x05 ASAP_HANDLE_RESOLUTION RFCXXXX 1977 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFCXXXX 1978 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFCXXXX 1979 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFCXXXX 1980 0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX 1981 0x0a ASAP_SERVER_ANNOUNCE RFCXXXX 1982 0x0b ASAP_COOKIE RFCXXXX 1983 0x0c ASAP_COOKIE_ECHO RFCXXXX 1984 0x0d ASAP_BUSINESS_CARD RFCXXXX 1985 0x0e ASAP_ERROR RFCXXXX 1986 0x0b-0xff (reserved by IETF) RFCXXXX 1988 For registering at IANA an ASAP Message Type in this table a request 1989 has to be made to assign such a number. This number must be unique. 1990 The "Specification Required" policy of [RFC5226] MUST be applied. 1992 8.2. Port numbers 1994 The references for the already assigned port numbers 1996 asap-tcp 3863/tcp 1997 asap-udp 3863/udp 1999 asap-sctp 3863/sctp 2001 asap-tcp-tls 3864/tcp 2003 asap-sctp-tls 3864/sctp 2005 should be updated to RFCXXXX. 2007 8.3. SCTP payload protocol identifier 2009 The reference for the already assigned ASAP payload protocol 2010 identifier 11 should be updated to RFCXXXX. 2012 8.4. Multicast addresses 2014 IANA needs to assign an IPv4 and an IPv6 mulitcast address. The IPv4 2015 address should be part of the Internetwork Control Block 2016 (224.0.1/24). 2018 9. Security Considerations 2020 We present a summary of the of the threats to the Rserpool 2021 architecture and describe security requirements in response to 2022 mitigate the threats. Next we present the security mechanisms, based 2023 on TLS, that are implementation requirements in response to the 2024 threats. Finally, we present a chain of trust argument that examines 2025 critical data paths in Rserpool and shows how these paths are 2026 protected by the TLS implementation. 2028 9.1. Summary of Rserpool Security Threats 2030 Threats Introduced by Rserpool and Requirements for Security in 2031 Response to Threats [I-D.ietf-rserpool-threats] describes the threats 2032 to the Rserpool architecture in detail lists the security 2033 requirements in response to each threat. From the threats described 2034 in this document, the security services required for the Rserpool 2035 protocol are enumerated below. 2037 Threat 1) PE registration/deregistration flooding or spoofing 2038 ----------- 2039 Security mechanism in response: ENRP server authenticates the PE 2041 Threat 2) PE registers with a malicious ENRP server 2042 ----------- 2043 Security mechanism in response: PE authenticates the ENRP server 2045 Threat 1 and 2 taken together results in mutual authentication of the 2046 ENRP server and the PE. 2048 Threat 3) Malicious ENRP server joins the ENRP server pool 2049 ----------- 2050 Security mechanism in response: ENRP servers mutually authenticate 2052 Threat 4) A PU communicates with a malicious ENRP server for handle 2053 resolution 2054 ----------- 2055 Security mechanism in response: The PU authenticates the ENRP server 2057 Threat 5) Replay attack 2058 ----------- 2059 Security mechanism in response: Security protocol which has 2060 protection from replay attacks 2062 Threat 6) Corrupted data which causes a PU to have misinformation 2063 concerning a pool handle resolution 2064 ----------- 2065 Security mechanism in response: Security protocol which supports 2066 integrity protection 2068 Threat 7) Eavesdropper snooping on handlespace information 2069 ----------- 2070 Security mechanism in response: Security protocol which supports data 2071 confidentiality 2073 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 2074 ENRP server 2075 ----------- 2076 Security mechanism in response: ASAP must control the number of ASAP 2077 endpoint unreachable messages transmitted from the PU to the ENRP 2078 server. 2080 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 2081 the ENRP server 2082 ----------- 2083 Security mechanism in response: ENRP server must control the number 2084 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 2086 To summarize the threats 1-7 require security mechanisms which 2087 support authentication, integrity, data confidentiality, protection 2088 from replay attacks. 2090 For Rserpool we need to authenticate the following: 2092 PU <---- ENRP Server (PU authenticates the ENRP server) 2093 PE <----> ENRP Server (mutual authentication) 2094 ENRP server <-----> ENRP Server (mutual authentication) 2096 9.2. Implementing Security Mechanisms 2098 We do not define any new security mechanisms specifically for 2099 responding to threats 1-7. Rather we use an existing IETF security 2100 protocol, specifically [RFC3237], to provide the security services 2101 required. TLS supports all these requirements and MUST be 2102 implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 2103 supported at a minimum by implementors of TLS for Rserpool. For 2104 purposes of backwards compatibility, ENRP SHOULD support 2105 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 2106 other IETF approved ciphersuites. 2108 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs MUST 2109 support mutual authentication using PSK. ENRP servers MUST support 2110 mutual authentication among themselves using PSK. PUs MUST 2111 authenticate ENRP servers using certificates. 2113 TLS with PSK is mandatory to implement as the authentication 2114 mechanism for ENRP to ENRP authentication and PE to ENRP 2115 authentication. For PSK, having a pre-shared-key constitutes 2116 authorization.The network administrators of a pool need to decide 2117 which nodes are authorized to participate in the pool. The 2118 justification for PSK is that we assume that one administrative 2119 domain will control and manage the server pool. This allows for PSK 2120 to be implemented and managed by a central security administrator. 2122 TLS with certificates is mandatory to implement as the authentication 2123 mechanism for PU to ENRP server. PUs MUST autnthenticate ENRP 2124 servers using certificates. ENRP servers MUST possess a site 2125 certificate whose subject corresponds to their canonical hostname. 2126 PUs MAY have certificates of their own for mutual authentication with 2127 TLS, but no provisions are set forth in this document for their use. 2128 All Rserpool elements that support TLS MUST have a mechanism for 2129 validating certificates received during TLS negotiation; this entails 2130 possession of one or more root certificates issued by certificate 2131 authorities (preferably well-known distributors of site certificates 2132 comparable to those that issue root certificates for web browsers). 2134 In order to prevent man-in-the-middle attacks, the client MUST verify 2135 the server's identity (as presented in the server's Certificate 2136 message). The client's understanding of the server's identity 2137 (typically the identity used to establish the transport connection) 2138 is called the "reference identity". The client determines the type 2139 (e.g., DNS name or IP address) of the reference identity and performs 2140 a comparison between the reference identity and each subjectAltName 2141 value of the corresponding type until a match is produced. Once a 2142 match is produced, the server's identity has been verified, and the 2143 server identity check is complete. Different subjectAltName types 2144 are matched in different ways. The client may map the reference 2145 identity to a different type prior to performing a comparison. 2146 Mappings may be performed for all available subjectAltName types to 2147 which the reference identity can be mapped; however, the reference 2148 identity should only be mapped to types for which the mapping is 2149 either inherently secure (e.g., extracting the DNS name from a URI to 2150 compare with a subjectAltName of type dNSName) or for which the 2151 mapping is performed in a secure manner (e.g., using DNSSEC, or using 2152 user- or admin-configured host- to-address/address-to-host lookup 2153 tables).. 2155 If the server identity check fails, user-oriented clients SHOULD 2156 either notify the user or close the transport connection and indicate 2157 that the server's identity is suspect. Automated clients SHOULD 2158 close the transport connection and then return or log an error 2159 indicating that the server's identity is suspect or both. Beyond the 2160 server identity check described in this section, clients should be 2161 prepared to do further checking to ensure that the server is 2162 authorized to provide the service it is requested to provide. The 2163 client may need to make use of local policy information in making 2164 this determination. 2166 If the reference identity is an internationalized domain name, 2167 conforming implementations MUST convert it to the ASCII Compatible 2168 Encoding (ACE) format as specified in Section 4 of [RFC3490] before 2169 comparison with subjectAltName values of type dNSName. Specifically, 2170 conforming implementations MUST perform the conversion operation 2171 specified in Section 4 of [RFC3490] as follows: * in step 1, the 2172 domain name SHALL be considered a "stored string"; * in step 3, set 2173 the flag called "UseSTD3ASCIIRules"; * in step 4, process each label 2174 with the "ToASCII" operation; and * in step 5, change all label 2175 separators to U+002E (full stop). 2177 After performing the "to-ASCII" conversion, the DNS labels and names 2178 MUST be compared for equality according to the rules specified in 2179 Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is 2180 allowed in subjectAltName values of type dNSName, and then only as 2181 the left-most (least significant) DNS label in that value. This 2182 wildcard matches any left-most DNS label in the server name. That 2183 is, the subject *.example.com matches the server names a.example.com 2184 and b.example.com, but does not match example.com or a.b.example.com. 2186 When the reference identity is an IP address, the identity MUST be 2187 converted to the "network byte order" octet string representation RFC 2188 791[RFC0791][RFC2460][RFC2460]. For IP Version 4, as specified in 2189 RFC 791, the octet string will contain exactly four octets. For IP 2190 Version 6, as specified in RFC 2460, the octet string will contain 2191 exactly sixteen octets. This octet string is then compared against 2192 subjectAltName values of type iPAddress. A match occurs if the 2193 reference identity octet string and value octet strings are 2194 identical. 2196 After a TLS layer is established in an session, both parties are to 2197 each independently decide whether or not to continue based on local 2198 policy and the security level achieved. If either party decides that 2199 the security level is inadequate for it to continue, it SHOULD remove 2200 the TLS layer immediately after the TLS (re)negotiation has completed 2201 (see RFC4511)[RFC4511]. Implementations may reevaluate the security 2202 level at any time and, upon finding it inadequate, should remove the 2203 TLS layer. 2205 Implementations MUST support TLS with SCTP as described in [RFC3436] 2206 or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we 2207 must ensure that RSerPool does not use any features of SCTP that are 2208 not available to an TLS/SCTP user. This is not a difficult technical 2209 problem, but simply a requirement. When describing an API of the 2210 RSerPool lower layer we have also to take into account the 2211 differences between TLS and SCTP. 2213 Threat 8 requires the ASAP protocol to limit the number of 2214 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) 2215 to the ENRP server. 2217 Threat 9 requires the ENRP protocol to limit the number of 2218 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see 2219 [I-D.ietf-rserpool-enrp]). 2221 There is no security mechanism defined for the multicast 2222 announcements. Therefore a receiver of such an announcement can not 2223 consider the source address of such a message to be a trustworthy 2224 address of an ENRP server. A receiver must also be prepared to 2225 receive a large number of multicast announcements from attackers. 2227 9.3. Chain of trust 2229 Security is mandatory to implement in Rserpool and is based on TLS 2230 implementation in all three architecture components that comprise 2231 Rserpool -- namely PU, PE and ENRP server. We define an ENRP server 2232 that uses TLS for all communication and authenticates ENRP peers and 2233 PE registrants to be a secured ENRP server. 2235 Here is a description of all possible data paths and a description of 2236 the security. 2238 PU <---> secured ENRP Server (authentication of ENRP server; 2239 queries over TLS) 2240 PE <---> secured ENRP server (mutual authentication; 2241 registration/deregistration over TLS) 2242 secured ENRP server <---> secured ENRP server (mutual authentication; 2243 database updates using TLS) 2245 If all components of the system authenticate and communicate using 2246 TLS, the chain of trust is sound. The root of the trust chain is the 2247 ENRP server. If that is secured using TLS, then security will be 2248 enforced for all ENRP and PE components that try to connect to it. 2250 Summary of interaction between secured and unsecured components: If 2251 the PE does not use TLS and tries to register with a secure ENRP 2252 server, it will receive an error message response indicated as error 2253 due to security considerations and the registration will be rejected. 2254 If an ENRP server which does not use TLS tries to update the database 2255 of a secure ENRP server, then the update will be rejected. If an PU 2256 does not use TLS and communicates with a secure ENRP server, it will 2257 get a response with the understanding that the response is not secure 2258 as the response can be tampered with in transit even if the ENRP 2259 database is secured. 2261 The final case is the PU sending a secure request to ENRP. It might 2262 be that ENRP and PEs are not secured and this is an allowable 2263 configuration. The intent is to secure the communication over the 2264 Internet between the PU and the ENRP server. 2266 Summary: 2268 Rserpool architecture components can communicate with each other to 2269 establish a chain of trust. Secured PE and ENRP servers reject any 2270 communications with unsecured ENRP or PE servers. 2272 If the above is enforced, then a chain of trust is established for 2273 the Rserpool user. 2275 10. Acknowledgments 2277 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 2278 Thomas Dreibholz, and many others for their invaluable comments and 2279 feedback. 2281 11. References 2283 11.1. Normative References 2285 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2286 September 1981. 2288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2289 Requirement Levels", BCP 14, RFC 2119, March 1997. 2291 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2292 (IPv6) Specification", RFC 2460, December 1998. 2294 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 2295 Loughney, J., and M. Stillman, "Requirements for Reliable 2296 Server Pooling", RFC 3237, January 2002. 2298 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2299 Layer Security over Stream Control Transmission Protocol", 2300 RFC 3436, December 2002. 2302 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2303 "Internationalizing Domain Names in Applications (IDNA)", 2304 RFC 3490, March 2003. 2306 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2307 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2309 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2310 (LDAP): The Protocol", RFC 4511, June 2006. 2312 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2313 RFC 4960, September 2007. 2315 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2316 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2317 May 2008. 2319 [I-D.ietf-rserpool-policies] 2320 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 2321 Policies", draft-ietf-rserpool-policies-09 (work in 2322 progress), May 2008. 2324 [I-D.ietf-rserpool-common-param] 2325 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 2326 "Aggregate Server Access Protocol (ASAP) and Endpoint 2327 Handlespace Redundancy Protocol (ENRP) Parameters", 2328 draft-ietf-rserpool-common-param-17 (work in progress), 2329 May 2008. 2331 [I-D.ietf-rserpool-enrp] 2332 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 2333 Silverton, "Endpoint Handlespace Redundancy Protocol 2334 (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), 2335 May 2008. 2337 [I-D.ietf-rserpool-threats] 2338 Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. 2339 Sengodan, "Threats Introduced by RSerPool and Requirements 2340 for Security in Response to Threats", 2341 draft-ietf-rserpool-threats-15 (work in progress), 2342 July 2008. 2344 11.2. Informative References 2346 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2347 Requirements for Security", BCP 106, RFC 4086, June 2005. 2349 Authors' Addresses 2351 Randall R. Stewart 2352 4875 Forest Drive 2353 Suite 200 2354 Columbia, SC 29206 2355 USA 2357 Phone: 2358 Email: randall@lakerest.net 2360 Qiaobing Xie 2361 USA 2363 Phone: +1 224-465-5954 2364 Email: Qiaobing.Xie@gmail.org 2366 Maureen Stillman 2367 Nokia 2368 127 W. State Street 2369 Ithaca, NY 14850 2370 USA 2372 Phone: 2373 Email: maureen.stillman@nokia.com 2375 Michael Tuexen 2376 Muenster Univ. of Applied Sciences 2377 Stegerwaldstr. 39 2378 48565 Steinfurt 2379 Germany 2381 Email: tuexen@fh-muenster.de 2383 Full Copyright Statement 2385 Copyright (C) The IETF Trust (2008). 2387 This document is subject to the rights, licenses and restrictions 2388 contained in BCP 78, and except as set forth therein, the authors 2389 retain all their rights. 2391 This document and the information contained herein are provided on an 2392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2393 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2394 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2395 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2396 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2399 Intellectual Property 2401 The IETF takes no position regarding the validity or scope of any 2402 Intellectual Property Rights or other rights that might be claimed to 2403 pertain to the implementation or use of the technology described in 2404 this document or the extent to which any license under such rights 2405 might or might not be available; nor does it represent that it has 2406 made any independent effort to identify any such rights. Information 2407 on the procedures with respect to rights in RFC documents can be 2408 found in BCP 78 and BCP 79. 2410 Copies of IPR disclosures made to the IETF Secretariat and any 2411 assurances of licenses to be made available, or the result of an 2412 attempt made to obtain a general license or permission for the use of 2413 such proprietary rights by implementers or users of this 2414 specification can be obtained from the IETF on-line IPR repository at 2415 http://www.ietf.org/ipr. 2417 The IETF invites any interested party to bring to its attention any 2418 copyrights, patents or patent applications, or other proprietary 2419 rights that may cover technology that may be required to implement 2420 this standard. Please address the information to the IETF at 2421 ietf-ipr@ietf.org.