idnits 2.17.1 draft-ietf-rserpool-asap-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2321. 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 (March 28, 2008) is 5872 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-08 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-16 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-18 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-09 Summary: 5 errors (**), 0 flaws (~~), 5 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 Cisco Systems, Inc. 4 Intended status: Experimental Q. Xie 5 Expires: September 29, 2008 Motorola, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 March 28, 2008 12 Aggregate Server Access Protocol (ASAP) 13 draft-ietf-rserpool-asap-19.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 29, 2008. 40 Abstract 42 Aggregate Server Access Protocol (ASAP) in conjunction with the 43 Endpoint Handlespace Redundancy Protocol (ENRP) 44 [I-D.ietf-rserpool-enrp] provides a high availability data transfer 45 mechanism over IP networks. ASAP uses a handle-based addressing 46 model which isolates a logical communication endpoint from its IP 47 address(es), thus effectively eliminating the binding between the 48 communication endpoint and its physical IP address(es) which normally 49 constitutes a single point of failure. 51 In addition, ASAP defines each logical communication destination as a 52 pool, providing full transparent support for server-pooling and load 53 sharing. It also allows dynamic system scalability - members of a 54 server pool can be added or removed at any time without interrupting 55 the service. 57 ASAP is designed to take full advantage of the network level 58 redundancy provided by the Stream Transmission Control Protocol 59 (SCTP) [RFC4960]. Each transport protocol, other than SCTP, MUST 60 have an accompanying transport mapping document. It should be noted 61 that ASAP messages passed between PE's and ENRP servers MUST use the 62 SCTP transport protocol. 64 The high availability server pooling is gained by combining two 65 protocols, namely ASAP and ENRP, in which ASAP provides the user 66 interface for pool handle to address translation, load sharing 67 management, and fault management while ENRP defines the high 68 availability pool handle translation service. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Organization of this document . . . . . . . . . . . . . . 6 75 1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 76 1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 77 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 79 2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 80 2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 81 2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 82 2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 83 2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 84 2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 11 85 2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 86 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 12 87 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 14 88 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 15 89 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 15 90 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 16 91 2.2.11. ASAP_COOKIE message . . . . . . . . . . . . . . . . . 16 92 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 17 93 2.2.13. ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . 17 94 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 18 95 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 19 97 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 22 98 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 23 99 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 25 100 3.5. Unreachable endpoints . . . . . . . . . . . . . . . . . . 26 101 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 27 102 3.7. Handling ASAP Endpoint to ENRP Server Communication 103 Failures . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 29 105 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 29 106 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 30 107 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 30 108 3.9. Business Card handling procedures . . . . . . . . . . . . 30 109 4. Roles of Endpoints . . . . . . . . . . . . . . . . . . . . . . 32 110 5. SCTP considerations . . . . . . . . . . . . . . . . . . . . . 33 111 6. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 34 112 6.1. Registration.Request Primitive . . . . . . . . . . . . . . 34 113 6.2. Deregistration.Request Primitive . . . . . . . . . . . . . 34 114 6.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 35 115 6.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 35 116 6.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 35 117 6.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 36 118 6.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 37 119 6.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 38 120 6.5.4. Send by Transport Address . . . . . . . . . . . . . . 39 121 6.5.5. Message Delivery Options . . . . . . . . . . . . . . . 39 122 6.6. Data.Received Notification . . . . . . . . . . . . . . . . 40 123 6.7. Error.Report Notification . . . . . . . . . . . . . . . . 41 124 6.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 125 6.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 41 126 6.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 43 127 6.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 43 128 6.9.1. Translation.Request Primitive . . . . . . . . . . . . 43 129 6.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 44 130 7. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 45 131 7.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 132 7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45 133 7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45 134 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 135 8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47 136 8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47 137 8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48 138 8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48 139 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 140 9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49 141 9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50 142 9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 51 143 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 144 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 145 11.1. Normative References . . . . . . . . . . . . . . . . . . . 54 146 11.2. Informative References . . . . . . . . . . . . . . . . . . 55 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 148 Intellectual Property and Copyright Statements . . . . . . . . . . 57 150 1. Introduction 152 The Aggregate Server Access Protocol (ASAP) when used in conjunction 153 with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp] 154 provides a high availability data transfer mechanism over IP 155 networks. ASAP uses a handle-based addressing model which isolates a 156 logical communication endpoint from its IP address(es), thus 157 effectively eliminating the binding between the communication 158 endpoint and its physical IP address(es) which normally constitutes a 159 single point of failure. 161 When multiple receiver instances exist under the same handle (a.k.a, 162 a server pool),an ASAP endpoint will select one Pool Element (PE), 163 based on the current load sharing policy indicated by the server 164 pool, and deliver its message to the selected PE. 166 While delivering the message, ASAP can be used to monitor the 167 reachability of the selected PE. If it is found unreachable, before 168 notifying the message sender (an ASAP user) of the failure, ASAP can 169 automatically select another PE (if one exists) under that pool and 170 attempt to deliver the message to that PE. In other words, ASAP is 171 capable of transparent fail-over amongst PE instances within a server 172 pool. 174 ASAP depends on ENRP which provides a high availability pool handle 175 space. ASAP is responsible for the abstraction of the underlying 176 transport technologies, load distribution management, fault 177 management, as well as presentation to the upper layer (aka an ASAP 178 user) via a unified primitive interface. 180 When SCTP [RFC4960] is used as the transport layer protocol, ASAP can 181 seamlessly incorporate the link-layer redundancy provided by SCTP. 183 This document defines the ASAP portion of the high availability 184 server pool. 186 1.1. Definitions 188 This document uses the following terms: 190 ASAP user: Either a PE or PU that uses ASAP. 192 Operational scope: The part of the network visible to pool users by 193 a specific instance of the reliable server pooling protocols. 195 Pool (or server pool): A collection of servers providing the same 196 application functionality. 198 Pool handle: A logical pointer to a pool. Each server pool will be 199 identifiable in the operational scope of the system by a unique 200 pool handle. 202 Pool element: A server entity having registered to a pool. 204 Pool user: A server pool user. 206 Pool element handle (or endpoint handle): A logical pointer to a 207 particular pool element in a pool, consisting of the pool handle 208 and a destination transport address of the pool element. 210 Handle space: A cohesive structure of pool handles and relations 211 that may be queried by an internal or external agent. 213 Home ENRP server: The ENRP server to which a PE or PU currently 214 sends all namespace service requests. A PE MUST only have one 215 home ENRP server at any given time and both the PE and its home 216 ENRP server MUST know and keep track of this relationship. A PU 217 SHOULD select one of the available ENRP servers as its Home ENRP 218 server but the collective ENRP servers may change this by the 219 sending or a ASAP_ENDPOINT_KEEP_ALIVE message. 221 ENRP client channel: The communication channel through which an ASAP 222 User sends all namespace service requests. The client channel is 223 usually defined by the transport address of the Home ENRP server 224 and a well known port number. The channel MAY make use of 225 multicast or a named list of ENRP servers. 227 Network Byte Order: Most significant byte first, a.k.a Big Endian. 229 Transport address: A Transport Address is traditionally defined by 230 Network Layer address, Transport Layer protocol and Transport 231 Layer port number. In the case of SCTP running over IP, a 232 transport address is defined by the combination of an IP address 233 and an SCTP port number (where SCTP is the Transport protocol). 235 1.2. Organization of this document 237 Section 2 details the ASAP message formats. In Section 3 we provide 238 detailed ASAP procedures for for the ASAP implementer. In Section 6 239 we give details of the ASAP interface, focusing on the communication 240 primitives between ASAP the applications above ASAP and ASAP itself, 241 and the communications primitives between ASAP and SCTP (or other 242 transport layers). Also included in this discussion are relevant 243 timers and configurable parameters as appropriate. Section 7 244 provides threshold and protocol variables. 246 Variables, timers and constants are used in the text when necessary. 247 A complete list can be found in Section 7 249 1.3. Scope of ASAP 251 The requirements for high availability and scalability do not imply 252 requirements on shared state and data. ASAP does not provide 253 transaction failover. If a host or application fails during the 254 processing of a transaction, this transaction may be lost. Some 255 services MAY provide a way to handle the failure, but this is not 256 guaranteed. ASAP MAY provide hooks to assist an application in 257 building a mechanism to share state but ASAP in itself does NOT share 258 any state. 260 1.3.1. Extent of the Handlespace 262 The scope of ASAP/ENRP is NOT Internet wide. The handlespace is 263 neither hierarchical nor arbitrarily large like DNS. A flat peer-to- 264 peer model is detailed. Pools of servers will exist in different 265 administrative domains. For example, suppose the use of ASAP and 266 ENRP is wanted. First, the PU may use DNS to contact an ENRP server. 267 Suppose a PU in North America wishes to contact a server pool in 268 Japan instead of North America. The PU would use DNS to get the list 269 of IP addresses of the Japanese server pool, that is, the ENRP client 270 channel in Japan. From there the PU would query the Home ENRP server 271 it established and then directly contact the PE(s) of interest. 273 1.4. Conventions 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 277 document are to be interpreted as described in [RFC2119]. 279 2. Message Definitions 281 All messages as well as their fields described below shall be in 282 Network Byte Order during transmission. For fields with a length 283 bigger than 4 bytes, a number in a pair of parentheses may follow the 284 field name to indicate the length of the field in number of bytes. 286 2.1. ASAP Parameter Formats 288 The basic message format and all parameter formats can be found in 289 [I-D.ietf-rserpool-common-param]. Note also that ALL ASAP messages 290 exchanged between an ENRP server and a PE MUST use SCTP as transport, 291 while ASAP messages exchanged between an ENRP server and a PU MUST 292 use either SCTP or TCP as transport. PE to PU data traffic MAY use 293 any transport protocol specified by the PE during registration. 295 2.2. ASAP Messages 297 This section details the individual messages used by ASAP. These 298 messages are composed of a standard message format found in Section 4 299 of [I-D.ietf-rserpool-common-param]. The parameter descriptions can 300 be found in [I-D.ietf-rserpool-common-param]. 302 The following ASAP message types are defined in this section: 304 Type Message Name 305 ----- ------------------------- 306 0x00 - (reserved by IETF) 307 0x01 - ASAP_REGISTRATION 308 0x02 - ASAP_DEREGISTRATION 309 0x03 - ASAP_REGISTRATION_RESPONSE 310 0x04 - ASAP_DEREGISTRATION_RESPONSE 311 0x05 - ASAP_HANDLE_RESOLUTION 312 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 313 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 314 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 315 0x09 - ASAP_ENDPOINT_UNREACHABLE 316 0x0a - ASAP_SERVER_ANNOUNCE 317 0x0b - ASAP_COOKIE 318 0x0c - ASAP_COOKIE_ECHO 319 0x0d - ASAP_BUSINESS_CARD 320 0x0e - ASAP_ERROR 322 Figure 1 324 2.2.1. ASAP_REGISTRATION message 326 The REGISTRATION message is sent by a PE to its Home ENRP Server to 327 either create a new pool or to add itself to an existing pool. The 328 PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle 329 parameter and the Pool Element parameter. The Pool Handle parameter 330 specifies the name to be registered. The Pool Element parameter MUST 331 be filled in by the registrant as outlined in Section 3.1. Note that 332 the PE sending the registration message MUST send the message using 333 an SCTP association. Furthermore the IP address(es) of the PE that 334 is registered within the Pool Element parameter MUST be a subset of 335 the IP address(es) used in the SCTP association regardless of the 336 registered transport protocol 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 : Pool Handle Parameter : 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 : Pool Element Parameter : 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Pool Handle Parameter: 350 See [I-D.ietf-rserpool-common-param] 352 Pool Element Parameter: 354 See [I-D.ietf-rserpool-common-param] 356 2.2.2. ASAP_DEREGISTRATION message 358 The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP 359 Server to remove itself from a pool to which it registered. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : Pool Handle Parameter : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 : PE Identifier Parameter : 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 371 Pool Handle Parameter: 373 See [I-D.ietf-rserpool-common-param] 375 PE Identifier Parameter: 377 See [I-D.ietf-rserpool-common-param] 379 The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle 380 and the PE identifier parameter in order to allow the ENRP server to 381 verify the identity of the endpoint. Note that deregistration is NOT 382 allowed by proxy, in other words a PE may only deregister itself. 384 2.2.3. ASAP_REGISTRATION_RESPONSE message 386 The ASAP_REGISTRATION_RESPONSE message is sent in response by the 387 Home ENRP Server to the PE that sent a ASAP_REGISTRATION message. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type = 0x03 |0|0|0|0|0|0|0|R| Message Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 : Pool Handle Parameter : 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 : PE Identifier Parameter : 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : Operational Error (optional) : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 R (Reject) Flag: 403 When set to '1', this flag indicates that the ENRP server sending 404 this message has rejected the registration. Otherwise when this flag 405 is set to '0', this indicates the registration has been granted. 407 Pool Handle Parameter: 409 See [I-D.ietf-rserpool-common-param] 411 PE Identifier Parameter: 413 See [I-D.ietf-rserpool-common-param] 415 Operational Error Parameter (optional): 417 See [I-D.ietf-rserpool-common-param] 419 This parameter is included if an error or some atypical events 420 occurred during the registration process. When the R flag is set to 421 '1', this parameter, if present, indicates the cause of the 422 rejection. When the R flag is set to '0', this parameter, if 423 present, serves as a warning to the registering PE, informing it that 424 some of its registration values may have been modified by the ENRP 425 server. If the registration was successful and there is no warning, 426 this parameter is not included. 428 2.2.4. ASAP_DEREGISTRATION_RESPONSE message 430 The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP 431 Server to a PE in response to a ASAP_DEREGISTRATION message or due to 432 the expiration of the registration life of the PE in the pool 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 : Pool Handle Parameter : 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 : PE Identifier Parameter : 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 : Operational Error (optional) : 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Pool Handle Parameter: 448 See [I-D.ietf-rserpool-common-param] 450 PE Identifier Parameter: 452 See [I-D.ietf-rserpool-common-param] 454 Operational Error: 456 See [I-D.ietf-rserpool-common-param] 458 This parameter is included if an error or some atypical events 459 occurred during the deregistration process. If the deregistration 460 was successful this parameter is not included. 462 2.2.5. ASAP_HANDLE_RESOLUTION message 464 The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to 465 its Home ENRP Server to resolve a pool handle into a list of pool 466 elements that are members of the pool indicated by the pool handle. 468 0 1 2 3 469 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type = 0x05 |0|0|0|0|0|0|0|S| Message Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 : Pool Handle Parameter : 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 The 'S' bit: 478 The 'S' bit, if set to '1', requests the Home ENRP server to send 479 updates to this Pool dynamically when the Pool changes for the 480 lifetime of the SCTP association. Dynamic updates to the pool will 481 consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages, 482 without the user needing to send in a ASAP_HANDLE_RESOLUTION. 484 If the 'S' bit is set to '0' no dynamic updates are requested. 486 Note that if a new Home ENRP server is adopted any 'dynamic update 487 request' will need to be resent to the new Home ENPR server if the 488 endpoint would like to continue to receive updates. In other words, 489 the ENRP servers do NOT share state regarding which of its PU's are 490 requesting automatic update of state. Thus upon change of Home ENRP 491 Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message 492 with the 'S' bit set to 1. Note also, that the 'S' bit will only 493 cause dynamic update of a Pool when the Pool exists. If a negative 494 response is returned, no further updates to the Pool (when it is 495 created) will occur. 497 Pool Handle parameter: 499 See [I-D.ietf-rserpool-common-param] 501 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message 503 The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by 504 the Home ENRP server of the PU or PE that sent a 505 ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if 506 the PU as requested Dynamic updates. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type = 0x06 |0|0|0|0|0|0|0|A| Message Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 : Pool Handle Parameter : 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 : Overall PE Selection Policy (optional) : 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 : Pool Element Parameter 1 (optional) : 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 : ... : 520 : : 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 : Pool Element Parameter N (optional) : 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 : Operational Error (optional) : 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 A bit: 529 This bit is set to '1' if the ENRP server accepts the request to send 530 automatic updates (i.e. the S bit was set on the request). If this 531 bit is set to '0' either the ENRP server does NOT support automatic 532 update, it has resource issues and cannot supply this feature or the 533 user did not request it. 535 Pool Handle parameter: 537 See [I-D.ietf-rserpool-common-param] 539 Overall PE Selection Policy (optional): 541 See [I-D.ietf-rserpool-common-param] 543 This parameter can be present when the response is positive. If 544 present, it indicates the overall pool member selection policy of the 545 pool. If not present, a round robin overall pool member selection 546 policy is assumed. This parameter is not present when the response 547 is negative. 549 Note, any load policy parameter within a Pool Element Parameter (if 550 present) MUST be ignored, and MUST NOT be used to determine the 551 overall pool member selection policy. 553 Pool Element Parameters (optional): 555 See [I-D.ietf-rserpool-common-param] 556 When the response is positive, an array of PE parameters are 557 included, indicating the current information about the PEs in the 558 named pool. At least one PE parameter MUST be present. When the 559 response is negative, no PE parameters are included. 561 Operational Error (optional): 563 See [I-D.ietf-rserpool-common-param] 565 The presence of this parameter indicates that the response is 566 negative (the handle resolution request was rejected by the ENRP 567 server). The cause code in this parameter (if present) will indicate 568 the reason the handle resolution request was rejected (e.g., the 569 requested pool handle was not found). The absence of this parmaeter 570 indicates that the response is positive. 572 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message 574 The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP Server to a 575 PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the 576 PE is reachable and requires the PE to adopt the sending server as 577 its new Home ENRP Server if the H bit is set to 1. Regardless of the 578 setting of the H bit, an ASAP endpoint MUST respond with an 579 ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages 580 that arrive. 582 0 1 2 3 583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Server Identifier | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 : Pool Handle Parameter : 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 H (Home ENRP server) flag 594 When set to '1', indicate that the ENRP server that sends this 595 message want to be the home ENRP server of the receiver of this 596 message. 598 Server Identifier: 32 bit (unsigned integer) 600 This is the ID of the ENRP server, as discussed in 601 [I-D.ietf-rserpool-enrp]. 603 Pool Handle parameter: 605 See [I-D.ietf-rserpool-common-param] . 607 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message 609 The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response 610 to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP Server. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 : Pool Handle Parameter : 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 : PE Identifier Parameter : 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Pool Handle parameter: 624 See [I-D.ietf-rserpool-common-param]. 626 PE Identifier parameter: 628 See [I-D.ietf-rserpool-common-param]. 630 2.2.9. ASAP_ENDPOINT_UNREACHABLE message 632 The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to 633 its Home ENRP Server to report an unreachable PE. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 : Pool Handle Parameter : 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 : PE Identifier Parameter : 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Pool Handle parameter: 647 See [I-D.ietf-rserpool-common-param]. 649 PE Identifier parameter: 651 See [I-D.ietf-rserpool-common-param]. 653 2.2.10. ASAP_SERVER_ANNOUNCE message 655 The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that 656 PUs and PEs know the transport information necessary to connect to 657 the ENRP server. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Server Identifier | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 : Transport param #1 : 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 : Transport param #2 : 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 : : 671 : ..... : 672 : : 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 : Transport param #n : 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Server Identifier: 32 bit (unsigned integer) 679 This is the ID of the ENRP server, as discussed in 680 [I-D.ietf-rserpool-enrp]. 682 Transport parameters (optional): 684 See [I-D.ietf-rserpool-common-param] for the SCTP and TCP Transport 685 parameters. 687 Only SCTP and TCP Transport parameters are allowed for use within the 688 SERVER_ANNOUNCE message. 690 2.2.11. ASAP_COOKIE message 692 The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to 693 convey information it wishes to share using a control channel. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 : Cookie Parameter : 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Cookie Parameter : 706 See [I-D.ietf-rserpool-common-param]. 708 2.2.12. ASAP_COOKIE_ECHO message 710 The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it 711 detects a failure with the current PE to aid in failover. The Cookie 712 Parameter sent by the PE is the latest one received from the failed 713 PE. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 : Cookie Parameter : 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Cookie Parameter: 725 See [I-D.ietf-rserpool-common-param]. 727 2.2.13. ASAP_BUSINESS_CARD message 729 The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE 730 to a PU using a control channel to convey the pool handle and a 731 preferred failover ordering. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 : Pool Handle Parameter : 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 : Pool Element Parameter-1 : 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 : .. : 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 : Pool Element Parameter-N : 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Pool Handle parameter: 749 See [I-D.ietf-rserpool-common-param]. 751 Pool Element parameters: 753 See [I-D.ietf-rserpool-common-param]. 755 2.2.14. ASAP_ERROR message 757 The ASAP_ERROR message is sent in response by an ASAP endpoint 758 receiving an unknown message or an unknown parameter to the sending 759 ASAP endpoint to report the problem or issue. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 : Operational Error Parameter : 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Operation Error parameter: 771 See [I-D.ietf-rserpool-common-param]. 773 When an ASAP endpoint receives an ASAP message with an unknown 774 message type or a message of known type that contains an unknown 775 parameter, it SHOULD handle the unknown message or the unknown 776 parameter according to the unrecognized message and parameter 777 handling rules defined in Section 3. 779 According to the rules, if an error report to the message sender is 780 needed, the ASAP endpoint that discovered the error SHOULD send back 781 an ASAP_ERROR message which includes an Operation Error parameter 782 with the proper cause code, cause length, and case specific 783 information. 785 3. Procedures 787 This section will focus on the methods and procedures used by an 788 internal ASAP endpoint. Appropriate timers and recovery actions for 789 failure detection and management are also discussed. Also please 790 note that ASAP messages, sent between a PE and PU are identified by 791 an SCTP Payload Protocol Identifier (PPID). 793 3.1. Registration 795 When a PE wishes to initiate or join a server pool it MUST use the 796 procedures outlined in this section for registration. Often, the 797 registration will be triggered by a user request primitive (discussed 798 in Section 6.1). The PE MUST register using an SCTP association 799 established between itself and the Home ENRP server. If the PE has 800 not established its Home ENRP server, it MUST follow the procedures 801 specified in Section 3.6. 803 Once the PE's ASAP endpoint has established its Home ENRP server the 804 following procedures MUST be followed to register: 806 R1) The PE's SCTP endpoint used to communicate with the Home ENRP 807 server MUST be bound to all IP addresses that will be used by the 808 PE (irregardless of what transport protocol will be used to 809 service user requests to the PE). 811 R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION 812 message as defined in Section 2.2.1. In formulating the message, 813 the PE MUST: 815 R2.1) Fill in the Pool Handle Parameter to specify which server 816 pool the ASAP endpoint wishes to join. 818 R2.2) Fill in the PE identifier using a good quality randomly 819 generated number ([RFC4086] provides some information on 820 randomness guidelines). 822 R2.3) Fill in the Registration Life time parameter with the 823 number of seconds that this registration is valid for. Note a 824 PE that wishes to continue service MUST re-register before the 825 registration expires. 827 R2.4) Fill in a User Transport Parameter to specify the type of 828 transport and the data/control channel usage the PE is willing 829 to support. Note, in joining an existing server pool, the PE 830 MUST follow the overall transport type and overall data/control 831 channel usage of the pool. Otherwise, the registration may be 832 rejected by the ENRP server. 834 R2.5) Fill in the preferred Pool Member Selection Policy 835 parameter. 837 R3) Send the Registration message to the Home ENRP server using 838 SCTP. 840 R4) Start a T2-registration timer. 842 Note: the PE does not need to fill in the optional ASAP transport 843 parameter. The ASAP transport parameter will be filled in and used 844 by the home ENRP server. 846 If the T2-registration timer expires before receiving an 847 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 848 received from the SCTP layer, the PE shall start the Server Hunt 849 procedure (see Section 3.6) in an attempt to get service from a 850 different ENRP server. After establishing a new Home ENRP server the 851 PE SHOULD restart the registration procedure. 853 At the reception of the registration response, the PE MUST stop the 854 T2-Registration timer. If the response indicates success, the PE is 855 registered and will be considered an available member of the server 856 pool. If the registration response indicates a failure, the PE must 857 either re-attempt registration after correcting the error or return a 858 failure indication to the PE's upper layer. The PE MUST NOT re- 859 attempt registration without correcting the error condition. 861 At any time a registered PE MAY wish to re-register to either update 862 its member selection policy value or registration expiration time. 863 When re-registering the PE MUST use the same PE identifier. 865 After successful registration the PE MUST start a T4-reregistration 866 timer. At its expiration a re-registration SHOULD be made starting 867 at step R1 including (at completion) restarting the T4-reregistration 868 timer. 870 Note that an implementation SHOULD keep a record of the number of 871 registration (and reregistration) attempts it makes in a local 872 variable that gets set to zero before the initial registration 873 attempt to the Home ENRP server or after a successful re- 874 registration.If repeated registration time-outs or failures occurs 875 and the local count exceeds the Threshold 'MAX-REG-ATTEMPT' the 876 implementation SHOULD report the error to its upper layer and stop 877 attempting registration. 879 The ENRP server handles the ASAP_REGISTRATION message according to 880 the following rules: 882 1. If the named pool does not exist in the handlespace, the ENRP 883 server MUST creates a new pool with that handle in the 884 handlespace and add the PE to the pool as its first PE; 886 When a new pool is created, the overall member selection policy 887 of the pool MUST be set to the policy type indicated by the first 888 PE, the overall pool transport type MUST be set to the transport 889 type indicated by the PE, and the overall pool data/control 890 channel configuration MUST be set to what is indicated in the 891 Transport Use field of the User Transport parameter by the 892 registering PE. 894 2. If the named pool already exists in the handlespace, but the 895 requesting PE is not currently a member of the pool, the ENRP 896 server will add the PE as a new member to the pool; 898 However, before adding the PE to the pool, the server MUST check 899 if the policy type, transport type, and transport usage indicated 900 by the registering PE is consistent with those of the pool. If 901 different, the ENRP server MUST reject the registration. 903 3. If the named pool already exists in the handlespace AND the 904 requesting PE is already a member of the pool, the ENRP server 905 SHOULD consider this as a re-registration case. The ENRP server 906 MUST perform the same tests on policy, transport type, transport 907 use, as described above. If the re-registration is accepted 908 after the test, the ENRP Server SHOULD replace the attributes of 909 the existing PE with the information carried in the received 910 ASAP_REGISTRATION message. 912 4. After accepting the registration, the ENRP server MUST assign 913 itself the owner of this PE. If this is a re-registration, the 914 ENRP server MUST take over ownership of this PE regardless of 915 whether the PE was previously owned by this server or by another 916 server. The ENRP server MUST also record the SCTP transport 917 address from which it received the ASAP_REGISTRATION in the ASAP 918 Transport parameter TLV inside the PE parameter of this PE. 920 5. The ENRP server may reject the registration due to other reasons 921 such as invalid values, lack of resource, authentication failure, 922 etc. 924 In all above cases, the ENRP server MUST reply to the requesting PE 925 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 926 accepted, the ENRP server MUST set the 'R' flag in the 927 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 928 the ENRP server MUST indicate the rejection by setting the 'R' flag 929 in the ASAP_REGISTRATION_RESPONSE to '1'. 931 If the registration is rejected, the ENRP server SHOULD include the 932 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 934 If the registration is granted (either a new registration or a re- 935 registration case), the ENRP server MUST assign itself to be the home 936 ENRP server of the PE, i.e., to "own" the PE. 938 Implementation note: for better performance, the ENRP server may 939 find it both efficient and convenient to internally maintain two 940 separate PE lists or tables - one is for the PEs that are "owned" 941 by the ENRP server and the other for all the PEs owned by its 942 peer(s). 944 Moreover, if the registration is granted, the ENRP server MUST take 945 the handlespace update action to inform its peers about the change 946 just made. If the registration is denied, no message will be sent to 947 its peers. 949 3.2. Deregistration 951 In the event a PE wishes to deregister from its server pool (normally 952 via an upper layer requests see Section 6.2), it SHOULD use the 953 following procedure. It should be noted that an alternate method of 954 deregistration is to NOT re-register and to allow the registration 955 life of the PE to expire. In this case a 956 ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP 957 endpoint to indicate the removal of the PE from the pool it 958 registered. 960 When deregistering the PE SHOULD use the SCTP association that was 961 used for registration with its Home ENRP server. To deregister, the 962 PE's ASAP endpoint MUST take the following actions: 964 D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION 965 message ( Section 2.2.2) using the same Pool Handle parameter sent 966 during registration. 968 D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION 969 message. The identifier MUST be the same as used during 970 registration. The use of the same Pool Handle and Pool Identifier 971 parameters used in registration allows the identity of the PE ASAP 972 endpoint be verified before deregistration can occur. 974 D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server 975 using the PE's SCTP association. 977 D4) Start a T3-Deregistration timer. 979 If the T3-Deregistration timer expires before receiving either a 980 ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification 981 from the PE's SCTP endpint, the PE's ASAP endpoint shall start the 982 ENRP Server Hunt procedure (see Section 3.6) in an attempt to get 983 service from another ENRP server. After establishing a new Home ENRP 984 server, the ASAP endpoint SHOULD restart the deregistration 985 procedure. 987 At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP 988 endpoint MUST stop the T3-deregistration timer. 990 It should be noted that after a successful deregistration the PE MAY 991 still receive requests for some period of time. The PE MAY wish to 992 remain active and service these requests or to exit and ignore these 993 requests. 995 Upon receiving the message, the ENRP server SHALL remove the PE from 996 its handlespace. Moreover, if the PE is the last one of the named 997 pool, the ENRP server will remove the pool from the handlespace as 998 well. 1000 If the ENRP server fails to find any record of the PE in its 1001 handlespace, it SHOULD consider the de-registration granted and 1002 completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the 1003 PE. 1005 The ENRP server may reject the de-registration request for various 1006 reasons, such as invalid parameters, authentication failure, etc. 1008 In response, the ENRP server MUST send an 1009 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- 1010 registration is rejected, the ENRP server MUST indicate the rejection 1011 by including the proper Operational Error parameter. 1013 It should be noted that de-registration does not stop the PE from 1014 sending or receiving application messages. 1016 Once the de-registration request is granted AND the PE removed from 1017 its local copy of the handlespace, the ENRP server MUST take the 1018 handlespace update action to inform its peers about the change just 1019 made. Otherwise, the ENRP server MUST NOT inform its peers. 1021 3.3. Handle resolution 1023 At any time a PE or PU may wish to resolve a handle. This usually 1024 will occur when a ASAP Endpoint sends to a Pool handle ( 1025 Section 6.5.1) to its home ENRP server or requests a cache population 1026 (Section 6.3). It may also occur for other reasons (e.g. the 1027 internal ASAP PE wishes to know its peers for sending a message to 1028 all of them). When an ASAP Endpoint (PE or PU) wishes to resolve a 1029 pool handle to a list of accesible transport addresses of the member 1030 PEs of the pool, it MUST take the following actions: 1032 NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with 1033 the Pool Handle to be resolved. 1035 NR2) If the endpoint does not have a Home ENRP server start the ENRP 1036 Server Hunt procedures specified in Section 3.6 to obtain one. 1037 Otherwise, proceed to step NR3. 1039 NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the home 1040 ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION 1041 message to the Home ENRP server using either TCP or SCTP. If sent 1042 from a PE, the SCTP association used for registration SHOULD be 1043 used. 1045 NR4) Start a T1-ENRPrequest timer. 1047 If the T1-ENRPrequest timer expires before receiving a response 1048 message, the ASAP endpoint SHOULD take the steps described in 1049 Section 3.7.2. If a SEND.FAILURE notification is received from the 1050 SCTP or TCP layer, the ASAP endpoint SHOULD start the Server Hunt 1051 procedure (see Section 3.6) in an attempt to get service from a 1052 different ENRP server. After establishing a new Home ENRP server, 1053 the ASAP endpoint SHOULD restart the handle resolution procedure. 1055 At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message the 1056 ASAP endpoint MUST stop its T1-ENRPrequest timer. After stopping the 1057 T1-ENRPrequest timer the ASAP endpoint SHOULD process the message as 1058 appropriate (e.g. populate a local cache, give the response to the 1059 ASAP user, and/or use the response to send the ASAP users message). 1061 Note that some ASAP endpoints MAY use a cache to minimize the number 1062 of handle resolutions sent. If a cache is used, it SHOULD: 1064 C1) Be consulted before sending a handle resolution. 1066 C2) Have a stale timeout timer associated with each cache entry. If 1067 the cache entry is determined to be stale upon a cache hit, a 1068 handle resolution message SHOULD be sent so the cache can be 1069 updated. 1071 C3) In the case of a stale cache entry the implementation may in 1072 parallel update the cache and answer the request or it may block 1073 the user and wait for an updated cache before proceeding with the 1074 users request. 1076 C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a 1077 handle resolution request but instead SHOULD use the entry from 1078 the cache. 1080 It should be noted that the impact of using a cache depends on the 1081 policy and the requirements of the application. For some 1082 applications cache-usage can increase the performance of the system, 1083 for some it can decrease it. 1085 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1086 requests from PUs either over an SCTP association on the well-know 1087 SCTP port, or over a TCP connection on the well-know TCP port. 1089 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1090 MUST first look up the pool handle in its handlespace. If the pool 1091 exits, the home ENRP server MUST compose and send back an 1092 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1094 In the response message, the ENRP server SHOULD list all the PEs 1095 currently registered in this pool, in a list of PE parameters. The 1096 ENRP server MUST also include a pool member selection policy 1097 parameter to indicate the overall member selection policy for the 1098 pool, if the current pool member selection policy is not round-robin. 1100 If the named pool does not exist in the handlespace, the ENRP server 1101 MUST reject the handle resolution request by responding with an 1102 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Pool 1103 Handle error. 1105 3.4. Endpoint keep alive 1107 The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a 1108 PE in order to verify it is reachable. If the transport level heart 1109 beat mechanism is insufficient, this message can be used in a heart 1110 beat mechanism for the ASAP level whose goal is determining the 1111 health status of the ASAP level in a timely fashion. (The transport 1112 level heart beat mechanism may be insufficient due to either the time 1113 outs or the heart beat interval being set too long, or, that the 1114 transport level heart beat mechanism's coverage is limited only to 1115 the transport level at the two ends.) Additionally, the 1116 ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of 1117 fault detection if the SCTP stack is in the kernel. In such a case, 1118 while SCTP level heartbeat monitors the end-to-end connectivity 1119 between the two SCTP stacks, the ASAP level heartbeat monitors the 1120 end-to-end liveliness of the ASAP layer above it. 1122 The use of the ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7) and 1123 the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. 1124 Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following 1125 actions MUST be taken: 1127 KA1) The PE must verify that the Pool Handle is correct and matches 1128 the Pool Handle sent in its earlier ASAP_REGISTRATION message. If 1129 the Pool Handle does not match, the PE MUST silently discard the 1130 message. 1132 KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as 1133 follows: 1135 KA2.1) Fill in the Pool Handle Parameter with the PE's Pool 1136 Handle. 1138 KA2.2) Fill in the PE Identifier parameter using the PE 1139 identifier used by this PE for registration. 1141 KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the 1142 appropriate SCTP association for the ENRP server which sent the 1143 ASAP_ENDPOINT_KEEP_ALIVE message. 1145 KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE 1146 message is set, and the Server Identifier in the message is NOT 1147 the identity of your Home ENRP server (or it is not set e.g you 1148 have a no Home ENRP server) adopt the sender of the 1149 ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server. 1151 3.5. Unreachable endpoints 1153 Occasionally, an ASAP endpoint may realize a PE is unreachable. This 1154 may occur by a specific SCTP error realized by the ASAP endpoint or 1155 via an ASAP user report via the Transport.Failure Primitive 1156 (Section 6.9.2). In either case, the ASAP endpoint SHOULD report the 1157 unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE 1158 message to any ENRP server. Before sending the 1159 ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in 1160 the Pool Handle parameter and PE identifier parameter of the 1161 unreachable endpoint. If the sender is a PE, the message MUST be 1162 sent via SCTP. It should be noted that an ASAP endpoint MUST report 1163 no more than once each time it encounters such an event. 1164 Additionally, when processing a Transport.Failure Primitive 1165 (Section 6.9.2) the ASAP endpoint MUST NOT send an 1166 ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous 1167 request to send data to the PE specified by the primitive. 1169 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1170 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1171 message to the PE in question (the 'H' flag in the message SHOULD be 1172 set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails 1173 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP 1174 server MUST consider the PE as truly unreachable and MUST remove the 1175 PE from its handlespace. 1177 If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully 1178 to the PE, the ENRP server MUST retain the PE in its handlespace. 1179 Moreover, the server SHOULD keep a counter to record how many 1180 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1181 reachability problem relating to this PE. If the counter exceeds the 1182 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1183 the PE from its handlespace. 1185 Optionally, an ENRP server may also periodically send point-to-point 1186 ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each 1187 of the PEs owned by the ENRP server in order to check their 1188 reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE 1189 fails, the ENRP server MUST consider the PE as unreachable and MUST 1190 remove the PE from its handlespace . Note, if an ENRP server owns a 1191 large number of PEs, the implementation should pay attention not to 1192 flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. 1193 Instead, the implementation MUST distribute the 1194 ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. 1196 3.6. ENRP server hunt procedures 1198 Each PU and PE manages a list of transport addresses of ENRP servers 1199 it knows about. 1201 If multicast capabilities are used within the operational scope an 1202 ENRP server MUST send periodically every (N+1)*T6-Serverannounce an 1203 ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the 1204 transport addresses available for ASAP communication on the multicast 1205 ENRP client channel where N is the number of ENRP servers the server 1206 has found via receiving ASAP_SERVER_ANNOUNCE messages. This should 1207 result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per 1208 T6-Serverannounce. 1210 If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it 1211 SHOULD insert all new included transport addresses into its list of 1212 ENRP server addresses and start a T7-ENRPoutdate timer for each 1213 address. For all already known included transport addresses, the T7- 1214 ENRPoutdate timer MUST be restarted for each address. If no 1215 transport parameters are included in the ASAP_SERVER_ANNOUNCE 1216 message, the SCTP transport protocol is assumed to be used and the 1217 source IP address and the IANA registered ASAP port number is used 1218 for communication with the ENRP server. If a T7-ENRPoutdate timer 1219 for a transport address expires, the corresponding address is deleted 1220 from the managed list of transport addresses of the PU or PE. 1222 If multicast capabilities are not used within the operational scope, 1223 each PU and PE MUST have a configured list of transport addresses of 1224 ENRP servers. 1226 At its startup or when it fails to communicate with its home ENRP 1227 server (i.e., timed-out on a ENRP request), a PE or PU MUST establish 1228 a new Home ENRP server (i.e. setup a TCP connection or SCTP 1229 association with a different ENRP server). 1231 To establish a home ENRP server the following rules MUST be followed: 1233 SH1) The PE or PU SHOULD try to establish an association or 1234 connection with no more than three ENRP server's. An ASAP 1235 endpoint MUST NOT establish more than three associations or 1236 connections. 1238 SH2) The ASAP endpoint shall start a T5-Serverhunt timer. 1240 SH3) If the ASAP endpoint establishes an association or connection 1241 it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD 1242 also reset the T5-Serverhunt timer to its initial value and then 1243 proceed to step SH6. 1245 SH4) If an association or connection establishment fails, the ASAP 1246 endpoint SHOULD try to establish an association or connection 1247 using a different transport address. 1249 SH5) If the T5-Serverhunt timer expires the following should be 1250 performed: 1252 SH5.1) The ASAP endpoint MUST double the value of the T5- 1253 Serverhunt timer. Note that this doubling is capped at the 1254 value RETRAN.max 1256 SH5.2) The ASAP endpoint SHOULD stop the establishment of 1257 associations and connections with the transport addresses 1258 selected in step SH1. 1260 SH5.2) The ASAP endpoint SHOULD repeat trying to establish an 1261 association or connection by proceeding to step SH1. It SHOULD 1262 attempt to select a different set of transport addresses with 1263 which to connect. 1265 SH6) The PE or PU shall pick one of the ENRP servers with which it 1266 was able to establish an association or connection, and send all 1267 subsequent ENRP request messages to this new Home ENRP server. 1269 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures 1271 Three types of failure may occur when the ASAP endpoint at ether PE 1272 or PU tries to communicate with an ENRP server: 1274 A) SCTP send failure 1276 B) T1-ENRPrequest timer expiration 1278 C) Registration failure 1280 3.7.1. SCTP Send Failure 1282 This communication failure indicates that the SCTP layer was unable 1283 to deliver a message sent to an ENRP server. In other words, the 1284 ENRP server is unreachable. 1286 In such a case, the ASAP endpoint should not re-send the 1287 undeliverable message. Instead, it should discard the message and 1288 start the ENRP server hunt procedure as described in Section 3.6 . 1289 After finding a new Home ENRP server, the ASAP endpoint should 1290 reconstruct and retransmit the request. 1292 Note that an ASAP endpoint MAY also choose to NOT discard the 1293 message, but to queue it for retransmission after a new Home ENRP 1294 server is found. If an ASAP endpoint does choose to discard the 1295 message, after a new Home ENRP server is found, the ASAP endpoint 1296 MUST be capable of reconstructing the original request. 1298 3.7.2. T1-ENRPrequest Timer Expiration 1300 When the T1-ENRPrequest timer expires, the ASAP endpoint should 1301 resend the original request to the ENRP server and restart the T1- 1302 ENRPrequest timer. In parallel, the ASAP endpoint should begin the 1303 ENRP server hunt procedures described in Section 3.6. 1305 This should be repeated up to MAX-REQUEST-RETRANSMIT times. After 1306 that, an Error.Report notification should be generated to inform the 1307 ASAP user and the ENRP request message associated with the T1- 1308 ENRPrequest timer should be discarded. It should be noted that if an 1309 alternate ENRP server responds the ASAP endpoint SHOULD adopt the 1310 responding ENRP server as its new Home ENRP server and resend the 1311 request to the new Home ENRP server. 1313 3.7.3. Registration Failure 1315 Registration failure is discussed in Section 3.1. 1317 3.8. Cookie handling procedures 1319 Whenever a PE wants, and a control channel exists, it can send an 1320 ASAP_COOKIE message to a PU via the control channel. The PU's ASAP 1321 endpoint stores the Cookie parameter and discards an older cookie if 1322 it is previously stored. 1324 Note: a control channel is a communication channel between a PU and 1325 PE that does not end in data passed to the user. This is 1326 accomplished with SCTP by using a PPID to separate the ASAP messages 1327 (Cookie and Business Card) from normal data messages. 1329 If the PU's ASAP endpoint detects a failure and initiates a failover 1330 to a different PE, it SHOULD send the lastest received cookie 1331 parameter in an ASAP_COOKIE_ECHO message to the new PE as the first 1332 message on the control channel. Upper layers may be involved in the 1333 failover procedure. 1335 The cookie handling procedure can be used for state sharing. 1336 Therefore a cookie should be signed by the sending PE ASAP endpoint 1337 and the cookie should be verified by the receiving PE's ASAP 1338 endpoint. The details of the verification procedure are out of scope 1339 for this document. It is only important that the PU always stores 1340 the last received Cookie Parameter and sends that back unmodified in 1341 case of a PE failure. 1343 3.9. Business Card handling procedures 1345 When communication begins between a PU and a PE either of which could 1346 be part of a PU/PE combination (i.e. a message is sent between the 1347 entities), a PE should always send a ASAP_BUSINESS_CARD message to a 1348 PU. A PU should send a ASAP_BUSINESS_CARD message to a PE only if it 1349 is part of a PU/PE combination. A ASAP_BUSINESS_CARD message MUST 1350 ONLY be sent if a control channel exists between a PU and PE. After 1351 communication as been established between a PE and PU, a new 1352 ASAP_BUSINESS_CARD message may be sent at any time by either entity 1353 to update its failover order. 1355 The ASAP_BUSINESS_CARD message serves two purposes. First it lists 1356 the pool handle. For a PU which is part of a PU/PE combination which 1357 is contacting a PE this is essential so that the PE learns the pool 1358 handle of the PU/PE combination requesting service. Secondly the 1359 ASAP_BUSINESS_CARD message tells the receiving entity a failover 1360 order that is recommended to follow. This should facilitate 1361 rendezvous between entities that have been working together as well 1362 to control the load redistribution upon the failure of any PE. 1364 Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13) 1365 the receiving ASAP endpoint SHOULD: 1367 BC1) Unpack the message and if no entry exists in the translation 1368 cache of the receiving ASAP endpoint for the pool handle listed 1369 within the ASAP_BUSINESS_CARD message perform a 1370 ASAP_HANDLE_RESOLUTION for that pool handle. If the translation 1371 cache does hold an entry for the pool handle, then it may be 1372 necessary to update the peer endpoint. 1374 BC2) Unpack the message and populate a preferred list for failover 1375 order. If the peers PE should fail this preferred list will be 1376 used guide the ASAP endpoint in the selection of an alternate PE. 1378 4. Roles of Endpoints 1380 A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION, and 1381 ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore it MUST 1382 support the handling of ASAP_ERROR messages. It MAY implement the 1383 handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD 1384 messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE 1385 messages. 1387 A PE MUST implement the handling of ASAP_REGISTRATION, 1388 ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and 1389 ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support 1390 the handling of ASAP_ENDPOINT_KEEP_ALIVE, 1391 ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and 1392 ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE, 1393 ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore it 1394 MAY support the handling of ASAP_SERVER_ANNOUNCE messages. 1396 An ENRP server MUST implement the handling of ASAP_REGISTRATION, 1397 ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and 1398 ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support 1399 the handling of ASAP_ENDPOINT_KEEP_ALIVE, 1400 ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and 1401 ASAP_ERROR messages. Furthermore it MAY support the handling of 1402 ASAP_SERVER_ANNOUNCE messages. 1404 If a node acts as a PU and a PE, it MUST fullfil both roles. 1406 5. SCTP considerations 1408 Each ASAP message is considered as an SCTP user message. The PPID 1409 registered for ASAP SHOULD be used. The SCTP port used at the ENRP 1410 server might be preconfigured or announced in the 1411 ASAP_SERVER_ANNOUNCE message or the well known ASAP port. 1413 ASAP messages beloning to the control channel MUST be sent using the 1414 PPID registered for ASAP. Messages belonging to the data channel 1415 MUST NOT use the PPID registered for ASAP. 1417 6. The ASAP Interfaces 1419 This chapter will focus primarily on the primitives and notifications 1420 that form the interface between the ASAP-user and ASAP and that 1421 between ASAP and its lower layer transport protocol (e.g., SCTP). 1423 Note, the following primitive and notification descriptions are shown 1424 for illustrative purposes. We believe that including these 1425 descriptions in this document is important to the understanding of 1426 the operation of many aspects of ASAP. But an ASAP implementation is 1427 not required to use the exact syntax described in this section. 1429 An ASAP User passes primitives to the ASAP sub-layer to request 1430 certain actions. Upon the completion of those actions or upon the 1431 detection of certain events, the ASAP layer will notify the ASAP 1432 user. 1434 6.1. Registration.Request Primitive 1436 Format: registration.request(poolHandle, 1437 User Transport parameter(s)) 1439 The poolHandle parameter contains a NULL terminated ASCII string of 1440 fixed length. The optional User Transport parameter(s) indicate 1441 specific transport parameters and types to register with. If this 1442 optional parameter is left off, then the SCTP endpoint used to 1443 communicate with the ENRP server is used as the default User 1444 Transport parameter. Note that any IP address contained within a 1445 User Transport parameter MUST be a bound IP address in the SCTP 1446 endpoint used to communicate with the ENRP server. 1448 The ASAP user invokes this primitive to add itself to the 1449 handlespace, thus becoming a Pool Element of a pool. The ASAP user 1450 must register itself with the ENRP server by using this primitive 1451 before other ASAP users using the handlespace can send message(s) to 1452 this ASAP user by Pool Handle or by PE handle (see Section 6.5.1 and 1453 Section 6.5.3). 1455 In response to the registration primitive, the ASAP endpoint will 1456 send an ASAP_REGISTRATION message to the home ENRP server (See 1457 Section 2.2.1 and Section 3.1), and start a T2-registration timer. 1459 6.2. Deregistration.Request Primitive 1461 Format: deregistration.request(poolHandle) 1463 The ASAP PE invokes this primitive to remove itself from the Server 1464 Pool. This should be used as a part of the graceful shutdown process 1465 by the application. 1467 A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the 1468 home ENRP server (see Section 2.2.2 and Section 3.2). 1470 6.3. CachePopulateRequest Primitive 1472 Format: cache_populate_request([Pool-Handle | 1473 Pool-Element-Handle]) 1475 If the address type is a Pool handle and a local handle translation 1476 cache exists, the ASAP endpoint should initiate a mapping information 1477 query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle 1478 and update it local cache when the response comes back from the ENRP 1479 server. 1481 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 1482 from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message 1483 is sent to the ENRP server for resolution. When the response message 1484 returns from the ENRP server the local cache is updated. 1486 Note that if the ASAP service does NOT support a local cache this 1487 primitive performs NO action. 1489 6.4. CachePurgeRequest Primitive 1491 Format: cache_purge_request([Pool-Handle | Pool-Element-Handle]) 1493 If the user passes a Pool handle and local handle translation cache 1494 exists, the ASAP endpoint should remove the mapping information on 1495 the Pool handle from its local cache. If the user passes a Pool- 1496 Element-Handle then the Pool handle within is used for the 1497 cache_purge_request. 1499 Note that if the ASAP service does NOT support a local cache this 1500 primitive performs NO action. 1502 6.5. DataSendRequest Primitive 1504 Format: data_send_request(destinationAddress, typeOfAddress, 1505 message, sizeOfMessage, Options); 1507 This primitive requests ASAP to send a message to some specified Pool 1508 or Pool Element within the current Operational scope. 1510 Depending on the address type used for the send request, the senders 1511 ASAP endpoint may perform address translation and Pool Element 1512 selection before sending the message out. This also MAY dictate the 1513 creation of a local transport endpoint in order to meet the required 1514 transport type. 1516 The data_send_request primitive can take different forms of address 1517 types as described in the following sections. 1519 6.5.1. Sending to a Pool Handle 1521 In this case the destinationAddress and typeOfAddress together 1522 indicates a pool handle. 1524 This is the simplest form of send_data_request primitive. By 1525 default, this directs ASAP to send the message to one of the Pool 1526 Elements in the specified pool. 1528 Before sending the message out to the pool, the senders ASAP endpoint 1529 MUST first perform a pool handle to address translation. It may also 1530 need to perform Pool Element selection if multiple Pool Elements 1531 exist in the pool. 1533 If the senders ASAP implementation does not support a local cache of 1534 the mapping information or if it does not have the mapping 1535 information on the pool in its local cache, it will transmit a 1536 ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to 1537 the current home ENRP server, and MUST hold the outbound message in 1538 queue while awaiting the response from the ENRP server (any further 1539 send request to this pool before the ENRP server responds SHOULD also 1540 be queued). 1542 Once the necessary mapping information arrives from the ENRP server, 1543 the senders ASAP will: 1545 A) map the pool handle into a list of transport addresses of the 1546 destination PE(s), 1548 B) if multiple PEs exist in the pool, ASAP will choose one of them 1549 and transmit the message to it. In that case, the choice of the 1550 PE is made by ASAP endpoint of the sender based on the server 1551 pooling policy as discussed in Section 6.5.2 1553 C) Optionally create any transport endpoint that may be needed to 1554 communicate with the PE selected. 1556 D) if no transport association or connection exists towards the 1557 destination PE, ASAP will establish any needed transport state, 1559 E) send out the queued message(s) to the appropriate transport 1560 connection using the appropriate send mechanism (e.g. for SCTP the 1561 SEND primitive in [RFC4960] would be used), and, 1563 F) if the local cache is implemented, append/update the local cache 1564 with the mapping information received in the ENRP server's 1565 response. Also, record the local transport information (e.g. the 1566 SCTP association id) if any new transport state was created. 1568 For more on the ENRP server request procedures see 1569 [I-D.ietf-rserpool-enrp]. 1571 Optionally, the ASAP endpoint of the sender may return a Pool Element 1572 handle of the selected PE to the application after sending the 1573 message. This PE handle can then be used for future transmissions to 1574 that same PE (see Section 6.5.3). 1576 Section 3.7 defines the fail-over procedures for cases where the 1577 selected PE is found unreachable. 1579 6.5.2. Pool Element Selection 1581 Each time an ASAP user sends a message to a pool that contains more 1582 than one PE, the senders ASAP endpoint must select one of the PEs in 1583 the pool as the receiver of the current message. The selection is 1584 done according to the current server pooling policy of the pool to 1585 which the message is sent. 1587 Note, no selection is needed if the ASAP_SEND_TOALL option is set 1588 (see Section 6.5.5). 1590 Together with the server pooling policy, each PE can also specify a 1591 Policy Value for itself at the registration time. The meaning of the 1592 policy value depends on the current server pooling policy of the 1593 group. A PE can also change its policy value whenever it desires, by 1594 re-registering itself with the handlespace with a new policy value. 1595 Re-registration shall be done by simply sending another 1596 ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). 1598 One basic policy is defined in this document, others can be found in 1599 [I-D.ietf-rserpool-policies] 1601 6.5.2.1. Round Robin Policy 1603 When an ASAP endpoint sends messages by Pool Handle and Round-Robin 1604 is the current policy of that Pool, the ASAP endpoint of the sender 1605 will select the receiver for each outbound message by round-Robining 1606 through all the registered PEs in that Pool, in an attempt to achieve 1607 an even distribution of outbound messages. Note that in a large 1608 server pool, the ENRP server MAY not send back all PEs to the ASAP 1609 client. In this case the client or PU will be performing a round 1610 robin policy on a subset of the entire Pool. 1612 6.5.3. Sending to a Pool Element Handle 1614 In this case the destinationAddress and typeOfAddress together 1615 indicate an ASAP Pool Element handle. 1617 This requests the ASAP endpoint to deliver the message to the PE 1618 identified by the Pool Element handle. 1620 The Pool Element handle should contain the Pool Handle and a 1621 destination transport address of the destination PE or the Pool 1622 Handle and the transport type. Other implementation dependent 1623 elements may also be cached in a Pool Element handle. 1625 The ASAP endpoint shall use the transport address and transport type 1626 to identify the endpoint to communicate with. If no communication 1627 state exists with the peer endpoint (and is required by the transport 1628 protocol) the ASAP endpoint MAY setup the needed state and then 1629 invoke the SEND primitive for the particular transport protocol to 1630 send the message to the PE. 1632 In addition, if a local translation cache is supported the endpoint 1633 will: 1635 A) send out the message to the transport address (or association id) 1636 designated by the PE handle. 1638 B) determine if the Pool Handle is in the local cache. 1640 If it is NOT, the endpoint will: 1642 i) ask the home ENRP server for handle resolution on pool handle 1643 by sending an ASAP_HANDLE_RESOLUTION message (see 1644 Section 2.2.5), and 1646 ii) use the response to update the local cache. 1648 If the pool handle is in the cache, the endpoint will only 1649 update the pool handle if the cache is stale. A stale cache is 1650 indicated by it being older than the protocol parameter 1651 'stale.cache.value' (see Section 7.2). 1653 Section 3.5 and Section 6.9 defines the fail-over procedures for 1654 cases where the PE pointed to by the Pool Element handle is found 1655 unreachable. 1657 Optionally, the ASAP endpoint may return the actual Pool Element 1658 handle to which the message was sent (this may be different from the 1659 Pool Element handle specified when the primitive is invoked, due to 1660 the possibility of automatic fail-over). 1662 6.5.4. Send by Transport Address 1664 In this case the destinationAddress and typeOfAddress together 1665 indicate a transport address and transport type. 1667 This directs the senders ASAP endpoint to send the message out to the 1668 specified transport address. 1670 No endpoint fail-over is support when this form of send request is 1671 used. This form of send request effectively by-passes the ASAP 1672 endpoint. 1674 6.5.5. Message Delivery Options 1676 The Options parameter passed in the various forms of the above 1677 data_send_request primitive gives directions to the senders ASAP 1678 endpoint on special handling of the message delivery. 1680 The value of the Options parameter is generated by bit-wise "OR"ing 1681 of the following pre-defined constants: 1683 ASAP_USE_DEFAULT: 0x0000 Use default setting. 1685 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 1686 case where the first selected PE or the PE pointed to by the PE 1687 handle is found unreachable, the sender's ASAP endpoint SHOULD re- 1688 select an alternate PE from the same pool if one exists, and 1689 silently re-send the message to this newly selected endpoint. 1691 Note that this is a best-effort service. Applications should be 1692 aware that messages can be lost during the failover process, even 1693 if the underlying transport supports retrieval of unacknowledged 1694 data (e.g. SCTP) (Example: messages acknowledged by the SCTP 1695 layer at a PE, but not yet read by the PE when a PE failure 1696 occurs.) In the case where the underlying transport does not 1697 support such retrieval (e.g. TCP), any data already submitted by 1698 ASAP to the transport layer MAY be lost upon failover. 1700 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP 1701 endpoint from re-sending the message to any alternate PE in case 1702 that the first selected PE or the PE pointed to by the PE handle 1703 is found unreachable. Instead, the senders ASAP endpoint shall 1704 notify its upper layer about the unreachability with an 1705 Error.Report and return any unsent data. 1707 ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 1708 endpoint to send the message to the same PE in the pool that the 1709 previous message destined to this pool was sent to. 1711 ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option 1712 directs the senders ASAP endpoint to send a copy of the message to 1713 all the PEs, except for the sender itself if the sender is a PE, 1714 in that pool. 1716 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination 1717 with ASAP_SEND_TO_ALL option. It permits the senders ASAP 1718 endpoint also deliver a copy of the message to itself if the 1719 sender is a PE of the pool (i.e., loop-back). 1721 ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer 1722 to send the current message using un-ordered delivery (note the 1723 underlying transport must support un-ordered delivery for this 1724 option to be effective). 1726 6.6. Data.Received Notification 1728 Format: data.received(messageReceived, sizeOfMessage, 1729 senderAddress, typeOfAddress) 1731 When a new user message is received, the ASAP endpoint of the 1732 receiver uses this notification to pass the message to its upper 1733 layer. 1735 Along with the message being passed, the ASAP endpoint of the 1736 receiver should also indicate to its upper layer the message senders 1737 address. The senders address can be in the form of either an SCTP 1738 association id, TCP transport address, UDP transport address, or an 1739 ASAP Pool Element handle. 1741 A) If the handle translation local cache is implemented at the 1742 receiver's ASAP endpoint, a reverse mapping from the senders IP 1743 address to the pool handle should be performed and if the mapping 1744 is successful, the senders ASAP Pool Element handle should be 1745 constructed and passed in the senderAddress field. 1747 B) If there is no local cache or the reverse mapping is not 1748 successful, the SCTP association id or other transport specific 1749 identification (if SCTP is not being used) should be passed in the 1750 senderAddress field. 1752 6.7. Error.Report Notification 1754 Format: error.report(destinationAddress, typeOfAddress, 1755 failedMessage, sizeOfMessage) 1757 An error.report should be generated to notify the ASAP user about 1758 failed message delivery as well as other abnormalities. 1760 The destinationAddress and typeOfAddress together indicates to whom 1761 the message was originally sent. The address type can be either a 1762 ASAP Pool Element handle, association id, or a transport address. 1764 The original message (or the first portion of it if the message is 1765 too big) and its size should be passed in the failedMessage and 1766 sizeOfMessage fields, respectively. 1768 6.8. Examples 1770 These examples assume an underlying SCTP transport between the PE and 1771 PU. Other transports are possible but SCTP is utilized in the 1772 examples for illustrative purposes. Note that all communication 1773 between PU and ENRP server and PE and ENRP servers would be using 1774 SCTP. 1776 6.8.1. Send to a New Pool 1778 This example shows the event sequence when a Pool User sends the 1779 message "hello" to a pool which is not in the local translation cache 1780 (assuming local caching is supported). 1782 ENRP Server PU new-handle:PEx 1784 | | | 1785 | +---+ | 1786 | | 1 | | 1787 |2. ASAP_HANDLE_RESOLUTION +---+ | 1788 |<-------------------------------| | 1789 | +---+ | 1790 | | 3 | | 1791 |4. ASAP_HANDLE_RESOLUTION_RSP +---+ | 1792 |------------------------------->| | 1793 | +---+ | 1794 | | 5 | | 1795 | +---+ 6. "hello1" | 1796 | |---------------->| 1797 | | | 1799 1) The user at PU invokes: 1801 data_send_request("new-handle", handle-type, "hello1", 6, 0); 1803 The ASAP endpoint, in response, looks up the pool "new-handle" in 1804 its local cache but fails to find it. 1806 2) The ASAP endpoint of PU queues the message, and sends an 1807 ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all 1808 information about pool "new-handle". 1810 3) A T1-ENRPrequest timer is started while the ASAP endpoint is 1811 waiting for the response from the ENRP server. 1813 4) The ENRP Server responds to the query with an 1814 ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the 1815 information about pool "new-handle". 1817 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 1818 cache with information on pool "new-handle". 1820 6) Based on the server pooling policy of pool "new-handle", ASAP at 1821 PU selects the destination PE (PEx), sets up, if necessary, an 1822 SCTP association towards PEx (explicitly or implicitly), and send 1823 out the queued "hello1" user message. 1825 6.8.2. Send to a Cached Pool Handle 1827 This shows the event sequence when the ASAP user PU sends another 1828 message to the pool "new-handle" after what happened in 1829 Section 6.8.1. 1831 ENRP Server PU new-handle:PEx 1833 | | | 1834 | +---+ | 1835 | | 1 | | 1836 | +---+ 2. "hello2" | 1837 | |---------------->| 1838 | | | 1840 1) The user at PU invokes: 1842 pdata_send_request("new-handle", handle-type, "hello2", 6, 0); 1844 The ASAP endpoint, in response, looks up the pool "new-handle" in 1845 its local cache and find the mapping information. 1847 2) Based on the server pooling policy of "new-handle", ASAP at PU 1848 selects the PE (assume EPx is selected again), and sends out 1849 "hello2" message (assume the SCTP association is already set up). 1851 6.9. PE send failure 1853 When the ASAP endpoint in a PE or PU attempts to send a message to a 1854 PE and fails the failed sender will report the event as described in 1855 Section 3.5 . 1857 Additional primitive are also defined in this section to support 1858 those user applications that do not wish to use ASAP as the actual 1859 transport. 1861 6.9.1. Translation.Request Primitive 1863 Format: translation.request(Pool-Handle) 1865 If the address type is a Pool handle and a local handle translation 1866 cache exists, the ASAP endpoint should look within its translation 1867 cache and return the current known transport types, ports and 1868 addresses to the caller. 1870 If the Pool handle does not exist in the local handle cache or no 1871 handle cache exists, the ASAP endpoint will send an 1872 ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon 1873 completion of the handle resolution, the ASAP endpoint should 1874 populate the local handle cache (if a local handle cache is 1875 supported) and return the transport types, ports and addresses to the 1876 caller. 1878 6.9.2. Transport.Failure Primitive 1880 Format: transport.failure(Pool-Handle, Transport-address) 1882 If an external user encounters a failure in sending to a PE and is 1883 NOT using ASAP it can use this primitive to report the failure to the 1884 ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the 1885 "home" ENRP server in response to this primitive. Note ASAP SHOULD 1886 NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually 1887 made a previous request to send data to the PE. 1889 7. Timers, Variables, and Thresholds 1891 The following is a summary of the timers, variables, and pre-set 1892 protocol constants used in ASAP. 1894 7.1. Timers 1896 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1897 the ENRP server (providing application information is queued). 1898 Normally set to 15 seconds. 1900 T2-registration - A timer started when sending an ASAP_REGISTRATION 1901 request to the home ENRP server, normally set to 30 seconds. 1903 T3-deregistration - A timer started when sending a deregistration 1904 request to the home ENRP server, normally set to 30 seconds. 1906 T4-reregistration - This timer is started after successful 1907 registration into the ENRP handle space and is used to cause a re- 1908 registration at a periodic interval. This timer is normally set 1909 to 10 minutes or 20 seconds less than the Life Timer parameter 1910 used in the registration request (whichever is less). 1912 T5-Serverhunt - This timer is used during the ENRP server hunt 1913 procedure and is normally set to 10 seconds. 1915 T6-Serverannounce - This timer gives the time between the sending of 1916 consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1917 1 second. 1919 T7-ENRPoutdate - This timer gives the time a server announcement is 1920 valid. It is normally set to 5 seconds. 1922 7.2. Variables 1924 stale_cache_value - A threshold variable that indicates how long a 1925 cache entry is valid for. 1927 7.3. Thresholds 1929 MAX-REG-ATTEMPT - The maximum number of registration attempts to be 1930 made before a server hunt is issued. The default value of this is 1931 set to 2. 1933 MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made 1934 when requesting information from the local ENRP server before a 1935 server hunt is issued. The default value for this is 2. 1937 RETRAN-MAX - This value represents the maximum time between 1938 registration attmempts and puts a ceiling on how far the 1939 registration timer will back-off. The default value for this is 1940 normally set to 60 seconds. 1942 8. IANA Considerations 1944 [NOTE to RFC-Editor: 1946 "RFCXXXX" is to be replaced by the RFC number you assign this 1947 document. 1949 ] 1951 This document (RFCXXX) is the reference for all registrations 1952 described in this section. All registrations need to be listed on an 1953 RSerPool specific page. 1955 8.1. A New Table for ASAP Message Types 1957 ASAP Message Types have to be maintained by IANA. Fourteen initial 1958 values should be assigned by IANA as described in Figure 1. This 1959 requires a new table "ASAP Message Types": 1961 Type Message Name Reference 1962 ----- ------------------------- --------- 1963 0x00 (reserved by IETF) RFCXXXX 1964 0x01 ASAP_REGISTRATION RFCXXXX 1965 0x02 ASAP_DEREGISTRATION RFCXXXX 1966 0x03 ASAP_REGISTRATION_RESPONSE RFCXXXX 1967 0x04 ASAP_DEREGISTRATION_RESPONSE RFCXXXX 1968 0x05 ASAP_HANDLE_RESOLUTION RFCXXXX 1969 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFCXXXX 1970 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFCXXXX 1971 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFCXXXX 1972 0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX 1973 0x0a ASAP_SERVER_ANNOUNCE RFCXXXX 1974 0x0b ASAP_COOKIE RFCXXXX 1975 0x0c ASAP_COOKIE_ECHO RFCXXXX 1976 0x0d ASAP_BUSINESS_CARD RFCXXXX 1977 0x0e ASAP_ERROR RFCXXXX 1978 0x0b-0xff (reserved by IETF) RFCXXXX 1980 For registering at IANA an ASAP Message Type in this table a request 1981 has to be made to assign such a number. This number must be unique. 1982 The "Specification Required" policy of [RFC2434] MUST be applied. 1984 8.2. Port numbers 1986 The references for the already assigned port numbers 1988 asap-tcp 3863/tcp 1989 asap-udp 3863/udp 1991 asap-sctp 3863/sctp 1993 asap-tcp-tls 3864/tcp 1995 asap-sctp-tls 3864/sctp 1997 should be updated to RFCXXXX. 1999 8.3. SCTP payload protocol identifier 2001 The reference for the already assigned ASAP payload protocol 2002 identifier 11 should be updated to RFCXXXX. 2004 8.4. Multicast addresses 2006 IANA needs to assign an IPv4 and an IPv6 mulitcast address. The IPv4 2007 address should be part of the Internetwork Control Block 2008 (224.0.1/24). 2010 9. Security Considerations 2012 We present a summary of the of the threats to the Rserpool 2013 architecture and describe security requirements in response to 2014 mitigate the threats. Next we present the security mechanisms, based 2015 on TLS, that are implementation requirements in response to the 2016 threats. Finally, we present a chain of trust argument that examines 2017 critical data paths in Rserpool and shows how these paths are 2018 protected by the TLS implementation. 2020 9.1. Summary of Rserpool Security Threats 2022 Threats Introduced by Rserpool and Requirements for Security in 2023 Response to Threats [I-D.ietf-rserpool-threats] describes the threats 2024 to the Rserpool architecture in detail lists the security 2025 requirements in response to each threat. From the threats described 2026 in this document, the security services required for the Rserpool 2027 protocol are enumerated below. 2029 Threat 1) PE registration/deregistration flooding or spoofing 2030 ----------- 2031 Security mechanism in response: ENRP server authenticates the PE 2033 Threat 2) PE registers with a malicious ENRP server 2034 ----------- 2035 Security mechanism in response: PE authenticates the ENRP server 2037 Threat 1 and 2 taken together results in mutual authentication of the 2038 ENRP server and the PE. 2040 Threat 3) Malicious ENRP server joins the ENRP server pool 2041 ----------- 2042 Security mechanism in response: ENRP servers mutually authenticate 2044 Threat 4) A PU communicates with a malicious ENRP server for handle 2045 resolution 2046 ----------- 2047 Security mechanism in response: The PU authenticates the ENRP server 2049 Threat 5) Replay attack 2050 ----------- 2051 Security mechanism in response: Security protocol which has 2052 protection from replay attacks 2054 Threat 6) Corrupted data which causes a PU to have misinformation 2055 concerning a pool handle resolution 2056 ----------- 2057 Security mechanism in response: Security protocol which supports 2058 integrity protection 2060 Threat 7) Eavesdropper snooping on handlespace information 2061 ----------- 2062 Security mechanism in response: Security protocol which supports data 2063 confidentiality 2065 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 2066 ENRP server 2067 ----------- 2068 Security mechanism in response: ASAP must control the number of ASAP 2069 endpoint unreachable messages transmitted from the PU to the ENRP 2070 server. 2072 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 2073 the ENRP server 2074 ----------- 2075 Security mechanism in response: ENRP server must control the number 2076 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 2078 To summarize the threats 1-7 require security mechanisms which 2079 support authentication, integrity, data confidentiality, protection 2080 from replay attacks. 2082 For Rserpool we need to authenticate the following: 2084 PU <---- ENRP Server (PU authenticates the ENRP server) 2085 PE <----> ENRP Server (mutual authentication) 2086 ENRP server <-----> ENRP Server (mutual authentication) 2088 9.2. Implementing Security Mechanisms 2090 We do not define any new security mechanisms specifically for 2091 responding to threats 1-7. Rather we use an existing IETF security 2092 protocol, specifically [RFC3237], to provide the security services 2093 required. TLS supports all these requirements and MUST be 2094 implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 2095 supported at a minimum by implementors of TLS for Rserpool. For 2096 purposes of backwards compatibility, ENRP SHOULD support 2097 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 2098 other IETF approved ciphersuites. 2100 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 2101 support mutual authentication. ENRP servers must support mutual 2102 authentication among themselves. PUs MUST authenticate ENRP servers. 2104 ENRP servers and PEs SHOULD possess a site certificate whose subject 2105 corresponds to their canonical hostname. PUs MAY have certificates 2106 of their own for mutual authentication with TLS, but no provisions 2107 are set forth in this document for their use. All Rserpool elements 2108 that support TLS MUST have a mechanism for validating certificates 2109 received during TLS negotiation; this entails possession of one or 2110 more root certificates issued by certificate authorities (preferably 2111 well-known distributors of site certificates comparable to those that 2112 issue root certificates for web browsers). 2114 Implementations MUST support TLS with SCTP as described in [RFC3436] 2115 or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we 2116 must ensure that RSerPool does not use any features of SCTP that are 2117 not available to an TLS/SCTP user. This is not a difficult technical 2118 problem, but simply a requirement. When describing an API of the 2119 RSerPool lower layer we have also to take into account the 2120 differences between TLS and SCTP. 2122 Threat 8 requires the ASAP protocol to limit the number of 2123 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) 2124 to the ENRP server. 2126 Threat 9 requires the ENRP protocol to limit the number of 2127 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see 2128 [I-D.ietf-rserpool-enrp]). 2130 There is no security mechanism defined for the multicast 2131 announcements. Therefore a receiver of such an announcement can not 2132 consider the source address of such a message to be a trustworthy 2133 address of an ENRP server. A receiver must also be prepared to 2134 receive a large number of multicast announcements from attackers. 2136 9.3. Chain of trust 2138 Security is mandatory to implement in Rserpool and is based on TLS 2139 implementation in all three architecture components that comprise 2140 Rserpool -- namely PU, PE and ENRP server. We define an ENRP server 2141 that uses TLS for all communication and authenticates ENRP peers and 2142 PE registrants to be a secured ENRP server. 2144 Here is a description of all possible data paths and a description of 2145 the security. 2147 PU <---> secured ENRP Server (authentication of ENRP server; 2148 queries over TLS) 2149 PE <---> secured ENRP server (mutual authentication; 2150 registration/deregistration over TLS) 2151 secured ENRP server <---> secured ENRP server (mutual authentication; 2152 database updates using TLS) 2154 If all components of the system authenticate and communicate using 2155 TLS, the chain of trust is sound. The root of the trust chain is the 2156 ENRP server. If that is secured using TLS, then security will be 2157 enforced for all ENRP and PE components that try to connect to it. 2159 Summary of interaction between secured and unsecured components: If 2160 the PE does not use TLS and tries to register with a secure ENRP 2161 server, it will receive an error message response indicated as error 2162 due to security considerations and the registration will be rejected. 2163 If an ENRP server which does not use TLS tries to update the database 2164 of a secure ENRP server, then the update will be rejected. If an PU 2165 does not use TLS and communicates with a secure ENRP server, it will 2166 get a response with the understanding that the response is not secure 2167 as the response can be tampered with in transit even if the ENRP 2168 database is secured. 2170 The final case is the PU sending a secure request to ENRP. It might 2171 be that ENRP and PEs are not secured and this is an allowable 2172 configuration. The intent is to secure the communication over the 2173 Internet between the PU and the ENRP server. 2175 Summary: 2177 Rserpool architecture components can communicate with each other to 2178 establish a chain of trust. Secured PE and ENRP servers reject any 2179 communications with unsecured ENRP or PE servers. 2181 If the above is enforced, then a chain of trust is established for 2182 the Rserpool user. 2184 10. Acknowledgments 2186 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 2187 Thomas Dreibholz, and many others for their invaluable comments and 2188 feedback. 2190 11. References 2192 11.1. Normative References 2194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2195 Requirement Levels", BCP 14, RFC 2119, March 1997. 2197 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2198 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2199 October 1998. 2201 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 2202 Loughney, J., and M. Stillman, "Requirements for Reliable 2203 Server Pooling", RFC 3237, January 2002. 2205 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2206 Layer Security over Stream Control Transmission Protocol", 2207 RFC 3436, December 2002. 2209 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2210 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2212 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2213 RFC 4960, September 2007. 2215 [I-D.ietf-rserpool-policies] 2216 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 2217 Policies", draft-ietf-rserpool-policies-08 (work in 2218 progress), March 2008. 2220 [I-D.ietf-rserpool-common-param] 2221 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 2222 "Aggregate Server Access Protocol (ASAP) and Endpoint 2223 Handlespace Redundancy Protocol (ENRP) Parameters", 2224 draft-ietf-rserpool-common-param-16 (work in progress), 2225 March 2008. 2227 [I-D.ietf-rserpool-enrp] 2228 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 2229 Silverton, "Endpoint Handlespace Redundancy Protocol 2230 (ENRP)", draft-ietf-rserpool-enrp-18 (work in progress), 2231 November 2007. 2233 [I-D.ietf-rserpool-threats] 2234 Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. 2235 Sengodan, "Threats Introduced by RSerPool and Requirements 2236 for Security in Response to Threats", 2237 draft-ietf-rserpool-threats-09 (work in progress), 2238 October 2007. 2240 11.2. Informative References 2242 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2243 Requirements for Security", BCP 106, RFC 4086, June 2005. 2245 Authors' Addresses 2247 Randall R. Stewart 2248 Cisco Systems, Inc. 2249 4875 Forest Drive 2250 Suite 200 2251 Columbia, SC 29206 2252 USA 2254 Phone: 2255 Email: rrs@cisco.com 2257 Qiaobing Xie 2258 Motorola, Inc. 2259 1501 W. Shure Drive, #2309 2260 Arlington Heights, IL 60004 2261 USA 2263 Phone: 2264 Email: qxie1@email.mot.com 2266 Maureen Stillman 2267 Nokia 2268 127 W. State Street 2269 Ithaca, NY 14850 2270 USA 2272 Phone: 2273 Email: maureen.stillman@nokia.com 2275 Michael Tuexen 2276 Muenster Univ. of Applied Sciences 2277 Stegerwaldstr. 39 2278 48565 Steinfurt 2279 Germany 2281 Email: tuexen@fh-muenster.de 2283 Full Copyright Statement 2285 Copyright (C) The IETF Trust (2008). 2287 This document is subject to the rights, licenses and restrictions 2288 contained in BCP 78, and except as set forth therein, the authors 2289 retain all their rights. 2291 This document and the information contained herein are provided on an 2292 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2293 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2294 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2295 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2296 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2297 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2299 Intellectual Property 2301 The IETF takes no position regarding the validity or scope of any 2302 Intellectual Property Rights or other rights that might be claimed to 2303 pertain to the implementation or use of the technology described in 2304 this document or the extent to which any license under such rights 2305 might or might not be available; nor does it represent that it has 2306 made any independent effort to identify any such rights. Information 2307 on the procedures with respect to rights in RFC documents can be 2308 found in BCP 78 and BCP 79. 2310 Copies of IPR disclosures made to the IETF Secretariat and any 2311 assurances of licenses to be made available, or the result of an 2312 attempt made to obtain a general license or permission for the use of 2313 such proprietary rights by implementers or users of this 2314 specification can be obtained from the IETF on-line IPR repository at 2315 http://www.ietf.org/ipr. 2317 The IETF invites any interested party to bring to its attention any 2318 copyrights, patents or patent applications, or other proprietary 2319 rights that may cover technology that may be required to implement 2320 this standard. Please address the information to the IETF at 2321 ietf-ipr@ietf.org.