idnits 2.17.1 draft-ietf-rserpool-asap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 43 instances of lines with control characters in the document. ** The abstract seems to contain references ([ENRP], [SCTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When a ASAP endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP endpoint of the sender will select the receiver for each outbound message by round-Robining through all the registered PEs in that Pool, in an attempt to achieve an even distribution of outbound messages. Note that in a large server pool, the ENRP server MAY NOT send back all PEs to the ASAP client. In this case the client or PU will be performing a round robin policy on a subset of the entire Pool. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2002) is 8028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SCTP' is mentioned on line 46, but not defined == Missing Reference: 'RFC1750' is mentioned on line 1410, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Missing Reference: 'TBD' is mentioned on line 1019, but not defined == Unused Reference: 'SCTPAPI' is defined on line 1392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. 'ENRP') == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-01 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-sctpsocket (ref. 'SCTPAPI') == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-sctp-03 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'ENRP-ASAP' Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. R. Stewart 3 INTERNET-DRAFT Cisco Systems Inc. 4 Q. Xie 5 Motorola 6 M. Stillman 7 Nokia 9 expires in six months May 3, 2002 11 Aggregate Server Access Protocol (ASAP) 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Aggregate Server Access Protocol (ASAP) in conjunction with the 31 Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high 32 availability data transfer mechanism over IP networks. ASAP uses a 33 name-based addressing model which isolates a logical communication 34 endpoint from its IP address(es), thus effectively eliminating the 35 binding between the communication endpoint and its physical IP 36 address(es) which normally constitutes a single point of failure. 38 In addition, ASAP defines each logical communication destination 39 as a pool, providing full transparent support for server-pooling 40 and load sharing. It also allows dynamic system scalability - 41 members of a server pool can be added or removed at any time 42 without interrupting the service. 44 ASAP is designed to take full advantage of the network level 45 redundancy provided by the Stream Transmission Control Protocol 46 (SCTP) [SCTP]. Each transport protocol to be used by Pool 47 Elements (PE) and Pool Users (PU) MUST have an accompanying 48 transports mapping document. Note that ASAP messages passed 49 between PE's and ENRP servers MUST use SCTP. 51 The high availability server pooling is gained by combining two 52 protocols, namely ASAP and ENRP, in which ASAP provides the user 53 interface for name to address translation, load sharing 54 management, and fault management while ENRP defines the high 55 availability name translation service. 57 Table Of Contents 59 1. Introduction............................................... 3 60 1.1 Definitions............................................ 3 61 1.2 Organization of this document.......................... 5 62 1.3 Scope of ASAP.......................................... 5 63 1.3.1 Extent of the Namespace.......................... 5 64 1.4 Conventions........................................... 5 65 2. Message Definitions........................................ 6 66 2.1 ASAP Parameter Formats................................. 6 67 2.2 ASAP Message Formats................................... 6 68 2.2.1 REGISTRATION message............................. 6 69 2.2.2 DEREGISTRATION message........................... 7 70 2.2.3 REGISTRATION_RESPONSE message.................... 7 71 2.2.4 NAME_RESOLUTION message.......................... 8 72 2.2.5 NAME_RESOLUTION_RESPONSE message................. 8 73 2.2.6 NAME_UNKNOWN message............................. 9 74 2.2.7 ENDPOINT_KEEP_ALIVE message...................... 9 75 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message.................. 9 76 2.2.9 ENDPOINT_UNREACHABLE message ....................10 77 2.2.10 SERVER_HUNT message ............................10 78 2.2.11 SERVER_HUNT_RESPONSE message....................10 79 3. Procedures.................................................11 80 3.1 Registration............................................11 81 3.2 Deregistration..........................................12 82 3.3 Name resolution.........................................13 83 3.4 Endpoint keep alive.....................................14 84 3.5 Reporting unreachable endpoints.........................14 85 3.6 ENRP server hunt procedures.............................14 86 3.7 Handle ASAP to ENRP Communication Failures..............15 87 3.7.1 SCTP Send Failure................................15 88 3.7.2 T1-ENRPrequest Timer Expiration..................15 89 4. The ASAP Interfaces........................................16 90 4.1 Registration.Request Primitive.........................16 91 4.2 Deregistration.Request Primitive.......................16 92 4.3 Cache.Populate.Request Primitive.......................17 93 4.4 Cache.Purge.Request Primitive..........................17 94 4.5 Data.Send.Request Primitive............................17 95 4.5.1 Sending to a Pool Handle.........................18 96 4.5.2 Pool Element Selection...........................19 97 4.5.2.1 Round Robin Policy.......................19 98 4.5.2.2 Least Used Policy........................19 99 4.5.2.3 Least Used with Degradation Policy.......20 100 4.5.2.4 Weighted Round Robin Policy..............20 101 4.5.3 Sending to a Pool Element Handle.................20 102 4.5.4 Send by Transport Address........................21 103 4.5.5 Message Delivery Options........................21 104 4.6 Data.Received Notification.............................22 105 4.7 Error.Report Notification..............................23 106 4.8 Examples...............................................23 107 4.8.1 Send to a New Pool Handle........................23 108 4.8.2 Send to a Cached Pool Handle.....................24 109 4.9 PE send failure........................................25 110 4.9.1 Translation.Request Primitive....................25 111 4.9.2 Transport.Failure Primitive......................25 112 5. Variables, Timers, and Constants...........................25 113 5.1 Timers.................................................25 114 5.2 Thresholds.............................................26 115 6. Security Considerations....................................26 116 7. References.................................................27 117 8. Acknowledgments............................................27 118 9. Authors' Addresses.........................................28 120 1. Introduction 122 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP 123 [ENRP] provides a high availability data transfer mechanism over IP 124 networks. ASAP uses a name-based addressing model which isolates a 125 logical communication endpoint from its IP address(es), thus 126 effectively eliminating the binding between the communication 127 endpoint and its physical IP address(es) which normally constitutes 128 a single point of failure. 130 When multiple receiver instances exist under the same name, a.k.a, a 131 server pool, ASAP will select one Pool Element (PE), based on the 132 current load sharing policy indicated by the server pool, and 133 deliver the message to the selected PE. 135 While delivering the message, ASAP monitors the reachability of the 136 selected PE. If it is found unreachable, before notifying the sender 137 of the failure, ASAP can automatically select another PE (if one 138 exists) under that pool and attempt to deliver the message to that 139 PE. In other words, ASAP is capable of transparent fail-over amongst 140 instances of a server pool. 142 ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a high 143 availability name space. ASAP is responsible for the abstraction of 144 the underlying transport technologies, load distribution management, 145 fault management, as well as the presentation to the upper layer 146 (i.e., the ASAP user) a unified primitive interface. 148 When SCTP [RFC2960] is used as the transport layer protocol, ASAP can 149 seamlessly incorporate the link-layer redundancy provided by the 150 SCTP. 152 This document defines the ASAP portion of the high availability server 153 pool. ASAP depends on the services of a high availability name space 154 a.k.a. ENRP. 156 1.1 Definitions 158 This document uses the following terms: 160 ASAP User: 161 Either a PE or PU that uses ASAP. 163 Operation scope: 165 The part of the network visible to Pool Users by a specific 166 instance of the reliable server pooling protocols. 168 Server pool (or Pool): 169 A collection of servers providing the same application 170 functionality. 172 Pool handle (or pool name): 173 A logical pointer to a pool. Each server pool will be 174 identifiable in the operation scope of the system by a unique 175 pool handle or "name". 177 Pool Element (PE): 178 A server entity having registered to a pool. 180 Pool User (PU): 181 A server Pool User. 183 Pool Element handle (PE handle): 184 A logical pointer to a particular Pool Element in a pool, 186 ENRP server: 187 A server program running on a host that manages the 188 name space collectively with its peer ENRP servers and 189 replies to the service requests from any Pool User or 190 Pool Element. 192 Home ENRP server: 193 The ENRP server to which a Pool Element currently uses. A PU 194 or PE normally chooses the ENRP server on their local host as 195 the home ENRP server (if one exists). A PU or PE should only 196 have one home ENRP server at any given time. Note that the 197 "home" ENRP server concept exists only within ASAP. ENRP 198 servers provide no special handling of PE's or PU's. Having 199 a "home" ENRP server only provides a mechanism to minimize 200 the number of associations a given PE will have. 202 ENRP client channel: 203 The communication channel through which an ASAP User (either a 204 PE or PU) requests ENRP namespace service. The client channel 205 is usually defined by the transport address of the 206 home server and a well known port number. The channel MAY 207 make use of multi-cast or a named list of ENRP servers. 209 ENRP server channel: 210 Defined by a well known multicast IP address and a well known port 211 number, OR a well known list of transport addresses for a group of 212 ENRP servers spanning an operational scope. All ENRP servers in an 213 operation scope can communicate with one another through this 214 channel via either multicast OR direct point to point SCTP 215 associations. 217 ENRP name domain: 218 Defined by the combination of the ENRP client channel and the 219 ENRP server channel in the operation scope. 221 Network Byte Order: 222 Most significant byte first, a.k.a Big Endian. 224 Transport address: 225 A Transport Address is traditionally defined by Network Layer 226 address, Transport Layer protocol and Transport Layer port 227 number. In the case of SCTP running over IP, a transport 228 address is defined by the combination of an IP address and an 229 SCTP port number (where SCTP is the Transport protocol). 231 1.2 Organization of this document 233 Chapter 3 details ASAP message formats. In Chapter 4 we give the 234 details of the ASAP interface, focusing on the communication 235 primitives between the applications above ASAP and ASAP itself, and 236 the communications primitives between ASAP and SCTP (or other 237 transport layer). Also included in this discussion is relevant 238 timers and configurable parameters as appropriate. Chapter 5 239 provides settable protocol values. 241 1.3 Scope of ASAP 243 The requirements for high availability and scalability do not imply 244 requirements on shared state and data. ASAP does not provide 245 transaction failover. If a host or application fails during 246 processing of a transaction this transaction may be lost. Some 247 services may provide a way to handle the failure, but this is not 248 guaranteed. ASAP MAY provide hooks to assist an application in 249 building a mechanism to share state but ASAP in itself will NOT 250 share any state. 252 1.3.1 Extent of the Namespace 254 The scope of the ASAP/ENRP is NOT Internet wide. The namespace is 255 neither hierarchical nor arbitrarily large like DNS. We propose a 256 flat peer-to-peer model. Pools of servers will exist in different 257 administrative domains. For example, suppose we want to use 258 ASAP/ENRP. First, the PU may use DNS to contact an ENRP server. 259 Suppose a PU in North America wishes to contact the server pool in 260 Japan instead of North America. The PU would use DNS to get the list of 261 IP addresses of the Japanese server pool domain, that is, 262 the ENRP client channel in Japan. From there the PU would query the 263 ENRP server and then directly contact the PE(s) of interest. 265 1.4 Conventions 267 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 268 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 269 they appear in this document, are to be interpreted as described in 270 [RFC2119]. 272 2. Message Definitions 274 All messages as well as their fields described below shall be in 275 Network Byte Order during transmission. For fields with a length 276 bigger than 4 octets, a number in a pair of parentheses may follow 277 the filed name to indicate the length of the field in number of 278 octets. 280 2.1 ASAP Parameter Formats 282 The basic message format and all parameter formats can be found 283 in [ENRP-ASAP]. Note also that ALL ASAP message exchanged between 284 the ENRP server and either a PE or PU MUST user SCTP. PE to PU 285 data traffic MAY use any transport protocol specified by the PE 286 during registration. 288 2.2 ASAP Messages 290 This section details the individual messages used by ASAP. These 291 messages are composed of a standard message format found in 292 Section 4 or [ENRP-ASAP], elements and parameters. The parameter 293 descriptions may also be found in Section 3 of [ENRP-ASAP]. 295 The following ASAP message types are defined in this section: 297 Type Message Name 298 ----- ------------------------- 299 0x00 - (reserved by IETF) 300 0x01-0x06 - defined by [ENRP] 301 0x07 - Registration 302 0x08 - Deregistration 303 0x09 - Registration Response 304 0x0a - Name Resolution 305 0x0b - Name Resolution Response 306 0x0c - Name Unknown 307 0x0d - Endpoint Keep Alive 308 0x0e - Endpoint Keep Alive Acknowledgement 309 0x0f - Endpoint Unreachable 310 0x10 - Server Hunt 311 0x11 - Server Hunt Response 313 2.2.1 REGISTRATION message 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 : Pool Handle : 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 : Pool Element Parameter : 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 : Authorization Parameter (optional) : 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 The pool handle parameter field specifies the name to be registered. 328 The PE Parameter field shall be filled in by the registrant endpoint 329 to declare its transports and addresses, server pooling policy and 330 value, and other operation preferences. Note that the registration 331 message MUST use SCTP and the IP addresses of the PE registered 332 within the Pool Element Parameter MUST be a subset of the addresses 333 of the SCTP association irrespective of the transport protocol 334 regestered by the PE. 336 2.2.2 DEREGISTRATION message 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 = 0x8 |0|0|0|0|0|0|0|0| Message Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 : Pool Handle Parameter : 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | PE Identifier | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 347 : Authorization Parameter (optional) : 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 The PE sending the DEREGISTRATION shall fill in the pool handle 351 and the PE identifier in order to allow the ENRP server to verify 352 the identity of the endpoint. Note that deregistration is NOT 353 allowed by proxy, in other words only a PE may only deregister 354 itself. 356 2.2.3 REGISTRATION_RESPONSE message 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 : Pool Handle Parameter : 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 : Pool Element Parameter : 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Action code | (reserved) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Operational Error (optional) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 : Authorization Parameter (optional) : 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Action: (8 bits) 376 The message that this results code is in response to: 378 0x0 -- registration 379 0x1 -- de-registration 381 Reserved: (24 bits) 383 Ignored by the receiver and set to 0 by the sender. 385 Operational Error 387 This optional TLV parameter is included if an error 388 occured during the registration/deregistration process. 389 If the registration/deregistration was sucessful this 390 parameter is not included. 392 2.2.4 NAME_RESOLUTION message 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : Pool Handle Parameter : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 : Authorization Parameter (optional) : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 This message is sent to a ENRP server via an SCTP association to 404 request translation of the Pool Handle to a list of Pool Elements. 406 2.2.5 NAME_RESOLUTION_RESPONSE message 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 : Pool Handle Parameter : 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 : Overall PE Selection Policy : 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 : Pool Element Parameter 1 : 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 : ... : 418 : : 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 : Pool Element Parameter N : 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 : Authorization Parameter (optional) : 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Overall PE Selection Policy: 428 This is a PE selection policy parameter. Indicates the overall selection 429 policy of the pool. If not present, round-robin is assumed. 431 Note, any load policy parameter inside the Pool Element Parameter 432 (if present) MUST be ignored, and MUST NOT be used to determine 433 the overall pool policy. 435 2.2.6 NAME_UNKNOWN message 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type = 0xc |0|0|0|0|0|0|0|0| Message Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 : Pool Handle Parameter : 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 : Authorization Parameter (optional) : 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 This message is returned by the ENRP server to indicate that 447 the requested Pool Handle hold no registered PE's. 449 2.2.7 ENDPOINT_KEEP_ALIVE message 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type = 0xd |0|0|0|0|0|0|0|0| Message Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 : Pool Handle Parameter : 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : Authorization Parameter (optional) : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 This message is sent to a PE by the ENRP server has a "health" 461 check. If the transport level Heart Beat mechanism is insufficient 462 (usually this means that time outs are set for too long or 463 heartbeats are not frequent enough), this adds heartbeat messages 464 with the goal of determining health status in a more timely fashion. 466 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type = 0xe |0|0|0|0|0|0|0|0| Message Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 : Pool Handle Parameter : 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | PE Identifier | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 : Authorization Parameter (optional) : 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 This message is sent by the PE to the ENRP server has an 480 acknowledgment to the ENDPOINT_KEEP_ALIVE message. 482 2.2.9 ENDPOINT_UNREACHABLE message 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 : Pool Handle Parameter : 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | PE Identifier | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 : Authorization Parameter (optional) : 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 A PE or PU will send this message to an ENRP server to report the 496 unreachability of the specified PE. 498 2.2.10 SERVER_HUNT message 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type = 0x10 |0|0|0|0|0|0|0|0| Message Length : 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 : Authorization Parameter (optional) : 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 This message is used by either a PE or PU to request service. It 508 is sent on the ENRP client channel. 510 2.2.11 SERVER_HUNT_RESPONSE message 512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type = 0x11 |0|0|0|0|0|0|0|0| Message Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : Authorization Parameter (optional) : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 This message is used by a ENRP server to respond to a PU or PE. It 520 is sent over a specific SCTP association which is established using 521 the IP address and Port number received by the ENRP server in the 522 respective Server Hunt message that this message is in response to. 524 3. Procedures 526 This chapter will focus on the methods and procedures used by an 527 internal ASAP endpoint. Appropriate timers and recovery actions for 528 failure detection and management are also discussed. 530 3.1 Registration 532 When a PE wishes to join its server pool it MUST use the procedures 533 outlined in this section to register. Often the registration will 534 be triggered by a user request primitive (discussed in Section 4.1). 535 The ASAP endpoint MUST register using an SCTP association between 536 the ASAP endpoint and the ENRP server. If the ASAP endpoint has not 537 established its Home ENRP server it MUST follow the procedures 538 specified in Section 3.6 to establish its Home ENRP server. 540 Once the ASAP endpoint has established its Home ENRP server the 541 following procedures MUST be followed to register: 543 R1) The SCTP endpoint used to communicate with the ENRP server 544 MUST be bound to all IP addresses that will be used by 545 the PE (irregardless of what protocol will be used to 546 service user requests to the PE). 548 R2) The ASAP endpoint MUST formulate a Registration message 549 as defined in Section 2.2.1. In formulating the message 550 the ASAP endpoint MUST: 552 R2.1) Fill in the the Pool Handle to specify which 553 server pool the ASAP endpoint wishes to join. 554 R2.2) Fill in a PE identifier using a good quality randomly 555 generated number ([RFC1750] provides some information 556 on randomness guidelines). 557 R2.3) Fill in the registration life time parameter with 558 the number of seconds that this registration is 559 good for. Note a PE that wishes to continue service 560 MUST re-register after the registration expires. 561 R2.4) Fill in a User Transport Parameter for EACH type 562 of transport the PE is willing to support. 563 R2.5) Fill in the preferred Member selection policy. 564 R2.6) Fill in any optional authorization parameter, 565 if required. 566 R3) Send the Registration request to the Home ENRP server 567 using SCTP. 568 R4) Start a T2-registration timer. 570 If the T2-registration timer expires before receiving a 571 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 572 received from the SCTP layer, the ASAP endpoint shall start the Server 573 Hunt procedure (see Section 3.6) in an attempt to get service 574 from a different ENRP server. After establishing a new Home 575 ENRP server the ASAP endpoint SHOULD restart the registration 576 procedure. 578 At the reception of the registration response, the ASAP endpoint 579 MUST stop the T2-Registration timer. If the response indicated 580 success, then the PE is now registered and will be considered an 581 available member of the server pool. If the registration response 582 indicates a failure, the ASAP endpoint must either re-attempt 583 registration after correcting the error or return a failure 584 indication to the ASAP endpoints upper layer. The ASAP endpoint MUST 585 NOT re-attempt registration without correcting the error condition. 587 At any time a registered PE MAY wish to re-register to either update 588 its member selection policy value or registration expiration 589 time. When re-registering the PE MUST use the same PE identifier. 591 After successful registration the PE MUST start a T4-reregistration 592 timer. At its expiration a re-registration SHOULD be made starting 593 at step R1 including (at completion) restarting the T4-reregistration 594 timer. 596 Note that an implementation SHOULD keep a record of the number of 597 registration attempts it makes in a local variable. If repeated 598 registration time-outs or failures occurs and the local count 599 exceeds the Threshold 'max-reg-attempt' the implementation SHOULD 600 report the error to its upper layer and stop attempting 601 registration. 603 3.2 Deregistration 605 In the event the PE wishes to deregister from its server pool 606 (normally via an upper layer requests see section 4.2) it SHOULD use 607 the following procedures. Note that an alternate method of 608 deregistration is to NOT re-register and to allow the registration 609 lift time to expire. 611 When deregistering the PE SHOULD use the same SCTP association with 612 its Home ENRP server that was used for registration. To deregister 613 the ASAP endpoint MUST take the following actions: 615 D1) Fill in the Pool Handle parameter of the Deregistration 616 message (Section 2.2.2) using the same Pool Handle parameter 617 sent during registration. 618 D2) Fill in the PE Identifier. The identifier MUST be the same 619 one used during registration. 620 D3) Fill in any optional authorization parameter, if required. 621 D4) Send the deregistration message to the Home ENRP server 622 using the SCTP association. 623 D5) Start a T3-Deregistration timer. 625 If the T3-Deregistration timer expires before receiving a 626 REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 627 received from the SCTP layer, the ASAP endpoint shall start the 628 Server Hunt procedure (see Section 3.6) in an attempt to get service 629 from a different ENRP server. After establishing a new Home ENRP 630 server the ASAP endpoint SHOULD restart the deregistration 631 procedure. 633 At the reception of the deregistration response, the ASAP 634 endpoint MUST stop the T3-deregistration timer. 636 Note that after a successful deregistration the PE MAY still receive 637 requests for some period of time. The PE MAY wish to still remain 638 active and service these requests or may wish to ignore these 639 requests and exit. 641 3.3 Name resolution 643 At any time a PE or PU may wish to resolve a name. This usually 644 will occur when a Endpoint sends to a Pool handle (Section 4.5) 645 or requests a cache population (4.3) but may occur for other 646 reasons (e.g. the internal ASAP PE wishes to know its peers for 647 sending a message to all of them). When an Endpoint (PE or PU) 648 wishes to resolve a name it MUST take the following actions: 650 NR1) Fill in a NAME_RESOLUTION message (section 2.4) with 651 the Pool Handle to be resolved. 652 NR2) Fill in any optional authorization parameter, as required. 653 NR2.1) If the endpoint does not have a Home ENRP server start 654 the ENRP Server Hunt procedures specified in section 655 3.6 to obtain one. Otherwise proceed to step NR3. 656 NR3) Send the NAME_RESOLUTION message to the Home ENRP server 657 using SCTP. 658 NR4) Start a T1-ENRPrequest timer. 660 If the T1-ENRPrequest timer expires before receiving a response 661 message, or a SEND.FAILURE notification is received from the SCTP 662 layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see 663 Section 3.6) in an attempt to get service from a different ENRP 664 server. After establishing a new Home ENRP server the ASAP endpoint 665 SHOULD restart the name resolution procedure. 667 At the reception of the response message (either a 668 NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its 669 T1-ENRPrequest timer. After stopping the T1 timer the endpoint 670 SHOULD process the name response as appropriate (e.g. populate a 671 local cache, give the response to the ASAP user, and/or use the 672 response to send the ASAP users message). 674 Note that some ASAP endpoints MAY use a cache to minimize 675 the number of name resolutions made. If such a cache is used 676 it SHOULD: 678 C1) Be consulted before requesting a name resolution. 679 C2) Have a stale timeout time associated with the cache 680 so that even in the event of a cache-hit, if the 681 cache is "stale" it will cause a new name_resolution 682 to be issued to update the cache. 683 C3) In the case of a "stale" cache the implementation may 684 in parallel request an update and answer the request or 685 block the user and wait for an updated cache before 686 proceeding with the users request. 687 C4) If the cache is NOT stale, the endpoint SHOULD NOT 688 make a name_resolution request but instead return 689 the entry from the cache. 691 3.4 Endpoint keep alive 693 Periodically an ENRP server may choose to "audit" a PE. It 694 does this by sending a ENDPOINT_KEEP_ALIVE message 695 (Section 2.2.7). Upon reception of an ENDPOINT_KEEP_ALIVE 696 message the following actions MUST be taken: 698 KA1) The PE must verify that the Pool Handle is correct 699 and matches the Pool Handle sent in its earlier 700 Registration. If the Pool Handle does not match 701 silently discard the message. 702 KA2) If an authorization parameter is included the 703 endpoint SHOULD verify that the message is authentic. If 704 the verification fails, silently discard the message. 705 KA3) Send a ENDPOINT_KEEP_ALIVE_ACK (section 2.2.8) by: 706 KA3.1) Filling in the Pool Handle Parameter with the 707 PE's Pool Handle. 708 KA3.2) Fill in the PE Identifier that was used with this 709 PE for registration. 710 KA3.3) Fill in any optional authorization parameter, 711 as required. 712 KA3.4) Send off the ENDPOINT_KEEP_ALIVE_ACK message via 713 the appropriate SCTP association for that ENRP server. 715 3.5 Reporting unreachable endpoints 717 Occasionally an ASAP endpoint may realize that a PE is unreachable. 718 This may occur by a specific SCTP error realized by the ASAP 719 endpoint or via a ASAP user report via the Error.Report primitive 720 (section 4.7). In either case the ASAP endpoint SHOULD report the 721 unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message 722 to its home ENRP server. The Endpoint should fill in the Pool Handle 723 and PE identifier of the unreachable endpoint and any authorization 724 parameter that may be required. The message MUST be sent via SCTP to 725 the Endpoints Home ENRP server. 727 3.6 ENRP server hunt procedures 729 At its startup, or when it fails to send to (i.e., timed-out on a 730 service request) with its current home ENRP server, a PE or PU shall 731 initiate the following home ENRP server hunt procedure to find a 732 new home server. 734 SH1) The PE or PU shall send a SERVER_HUNT message (Section 735 2.2.10) over the ENRP client channel. If the client channel 736 is a multi-cast destination only one message is needed. If 737 the client channel is a set of uni-cast addresses then a 738 message SHOULD be sent to no more than three ENRP server unicast 739 address. A Endpoint MUST NOT send to more than three at 740 any single time. 742 SH2) The Endpoint shall start a T5-Serverhunt timer. 744 SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message 745 the endpoint MUST stop its T5-Serverhunt timer. 746 The Endpoint SHOULD also reset the T5-Serverhunt value 747 to its initial value and then proceed to step SH5. 749 SH4) If the T5-Serverhunt timer expires the following should be 750 performed: 751 SH4.1) The endpoint MUST double the value of the T5-Serverhunt timer. 752 SH4.2) The endpoint SHOULD Repeat sending a server hunt 753 message by proceeding to step SH1. Note that 754 if the server hunt procedure are using a unicast channel 755 the endpoint SHOULD attempt to select a different set 756 of ENRP servers to send the SERVER_HUNT message to. 758 SH5) The PE or PU shall pick one of the ENRP servers that have 759 responded as its new home ENRP server, and send all 760 its subsequent the namespace service requests to 761 this new home ENRP server. 763 Upon the reception of the SERVER_HUNT message, an ENRP server shall 764 always reply to the PE with a SERVER_HUNT_RESPONSE message. 766 3.7 Handle ASAP to ENRP Communication Failures 768 Three types of failure may occur when the ASAP endpoint at an endpoint 769 tries to communicate with the ENRP server: 771 A) SCTP send failure 772 B) T1-ENRPrequest timer expiration 773 C) Registration failure 775 Registration failure is discussed in section 4.1. 777 3.7.1 SCTP Send Failure 779 This indicates that the SCTP layer failed to deliver a message sent 780 to the ENRP server. In other words, the ENRP server is currently 781 unreachable. 783 In such a case, the ASAP endpoint should not re-send the failed 784 message. Instead, it should discard the failed message and start the 785 ENRP server hunt procedure as described in Section 3.6. 787 3.7.2 T1-ENRPrequest Timer Expiration 789 When a T1-ENRPrequest timer expires, the ASAP should re-send the 790 original request to the ENRP server and re-start the T1-ENRPrequest 791 timer. In parallel, a SERVER_HUNT message should be issued per 792 Section 3.6. 794 This should be repeated up to 'max-request-retransmit' times. After 795 that, an Error.Report notification should be generated to inform the 796 ASAP user and the ENRP request message associated with the timer 797 should be discarded. Note that if an alternate ENRP server responds 798 the ASAP endpoint SHOULD adopt the responding ENRP server as its 799 new "home" server and resend the request to the new "home" server. 801 4. The ASAP Interfaces 803 This chapter will focus primarily on the primitives and 804 notifications that form the interface between the ASAP-user and 805 ASAP and that between ASAP and its lower layer transport protocol 806 (e.g., SCTP). 808 An ASAP User passes primitives to the ASAP sub-layer to 809 request certain actions. Upon the completion of those actions or 810 upon the detection of certain events, the ASAP will notify the 811 ASAP user. 813 4.1 Registration.Request Primitive 815 Format: registration.request(poolHandle, 816 User Transport parameter(s)) 818 The poolHandle parameter contains a NULL terminated ASCII 819 string of fixed length. The optional User Transport parameter(s) 820 indicate specific transport parameters and types to register with. 821 If this optional parameter is left off, then the SCTP endpoint 822 used to communicate with the ENRP server is used as the default 823 User Transport parameter. Note that any IP address contained 824 within a User Transport parameter MUST be a bound IP address in 825 the SCTP endpoint used to communicate with the ENRP server. 827 The ASAP user invokes this primitive to add itself to the 828 namespace, thus becoming a Pool Element of a pool. The ASAP user 829 must register itself with the ENRP server by using this primitive 830 before other ASAP users using the namespace can send message(s) to 831 this ASAP user by Pool Handle or by PE handle (see Sections 4.5.1 832 and 4.5.2). 834 In response to the registration primitive, the ASAP endpoint will send 835 a REGISTRATION message to the home ENRP server (See Section 2.2.1 and 836 Section 3.1), and start a T2-registration timer. 838 4.2 Deregistration.Request Primitive 840 Format: deregistration.request(poolHandle) 842 The ASAP PE invokes this primitive to remove itself from the 843 Server Pool. This should be used as a part of the graceful shutdown 844 process by the application. 846 A DEREGISTRATION message will be sent by ASAP endpoint to the home ENRP 847 server (see Section 2.2.2 and Section 3.2). 849 4.3 Cache.Populate.Request Primitive 851 Format: cache.populate.request([Pool-Handle | Pool-Element-Handle]) 853 If the address type is a Pool handle and a local name translation 854 cache exists, the ASAP endpoint should initiate a mapping 855 information query by sending a NAME.RESOLUTION message on the Pool 856 handle and update it local cache when the response comes back from 857 the ENRP server. 859 If a Pool-Element-Handle is passed then the Pool Handle is unpacked 860 from the Pool-Element-Handle and the NAME.RESOLUTION message is sent 861 to the ENRP server for resolution. When the response message returns 862 from the ENRP server the local cache is updated. 864 Note that if the ASAP service does NOT support a local cache 865 this primitive performs NO action. 867 4.4 Cache.Purge.Request Primitive 869 Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) 871 If the user passes a Pool handle and local name translation cache 872 exists, the ASAP endpoint should remove the mapping information on 873 the Pool handle from its local cache. If the user passes a 874 Pool-Element-Handle then the Pool handle within is used for the 875 cache.purge.request. 877 Note that if the ASAP service does NOT support a local cache this 878 primitive performs NO action. 880 4.5 Data.Send.Request Primitive 882 Format: data.send.request(destinationAddress, typeOfAddress, 883 message, sizeOfMessage, Options); 885 This primitive requests ASAP to send a message to some specified 886 Pool or Pool Element within the current Operational scope. 888 Depending on the address type used for the send request, the 889 senders ASAP endpoint may perform address translation and Pool 890 Element selection before sending the message out. This also MAY 891 dictate the creation of a local transport endpoint in order to meet 892 the required transport type. 894 The data.send.request primitive can take different forms of address 895 types as described in the following sections. 897 4.5.1 Sending to a Pool Handle 899 In this case the destinationAddress and typeOfAddress together 900 indicates a pool handle. 902 This is the simplest form of send.data.request primitive. By 903 default, this directs ASAP to send the message to one of the Pool 904 Elements in the specified pool. 906 Before sending the message out to the pool, the senders ASAP 907 endpoint MUST first perform a pool handle to address translation. It 908 may also need to perform Pool Element selection if multiple Pool 909 Elements exist in the pool. 911 If the senders ASAP implementation does not support a local cache 912 of the mapping information or if it does not have the mapping 913 information on the pool in its local cache, it will transmit a 914 NAME.RESOLUTION message (see Section 2.2.4 and Section 3.3) to the 915 current home ENRP server, and MUST hold the outbound message in 916 queue while awaiting the response from the ENRP server (any further 917 send request to this pool before the ENRP server responds SHOULD 918 also be queued). 920 Once the necessary mapping information arrives from the ENRP server, 921 the senders ASAP will: 923 A) map the pool handle into a list of transport addresses of the 924 destination PE(s), 926 B) if multiple PEs exist in the pool, ASAP will choose 927 one of them and transmit the message to it. In that case, the 928 choice of the PE is made by ASAP endpoint of the sender based on 929 the server pooling policy as discussed in section 4.5.2. 931 C) Optionally create any transport endpoint that may be needed to 932 communicate with the PE selected. 934 D) if no transport association or connection exists towards the 935 destination PE, ASAP will establish any needed transport state, 937 E) send out the queued message(s) to the appropriate transport 938 connection using the appropriate send mechanism (e.g. for 939 SCTP the SEND primitive in [RFC2960] would be used), and, 941 F) if the local cache is implemented, append/update the local cache 942 with the mapping information received in the ENRP server's 943 response. Also, record the local transport information (e.g. 944 the SCTP association id) if any new transport state was created. 946 For more on the ENRP server request procedures see [ENRP]. 948 Optionally, the ASAP endpoint of the sender may return a Pool Element 949 handle of the selected PE to the application after sending the 950 message. This PE handle can then be used for future transmissions to 951 that same PE (see Section 4.5.3). 953 Section 4.5.5 defines the fail-over procedures for cases where the 954 selected PE is found unreachable. 956 4.5.2 Pool Element Selection 958 Each time an ASAP user sends a message to a pool that contains more 959 than one PE, the senders ASAP endpoint must select one of the PEs 960 in the pool as the receiver of the current message. The selection is 961 done according to the current server pooling policy of the pool to 962 which the message is sent. 964 Note, no selection is needed if the ASAP_SEND_TOALL option is set 965 (see Section 4.5.5). 967 Together with the server pooling policy, each PE can also 968 specify a Policy Value for itself at the registration time. The 969 meaning of the policy value depends on the current server pooling 970 policy of the group. A PE can also change its policy value whenever 971 it desires, by re-registering itself with the namespace with a new 972 policy value. Re-registration shall be done by simply sending 973 another REGISTRATION to its home ENRP server (See section 3.1). 975 Four basic server pooling policies are defined in ASAP, namely the 976 Round Robin, Least Used, Least Used Degrading and Weighted Round 977 Robin. The following sections describes each of these policies. 979 4.5.2.1 Round Robin Policy 981 When a ASAP endpoint sends messages by Pool Handle and Round-Robin 982 is the current policy of that Pool, the ASAP endpoint of the sender 983 will select the receiver for each outbound message by round-Robining 984 through all the registered PEs in that Pool, in an attempt to 985 achieve an even distribution of outbound messages. Note that in a 986 large server pool, the ENRP server MAY NOT send back all PEs to the 987 ASAP client. In this case the client or PU will be performing a 988 round robin policy on a subset of the entire Pool. 990 4.5.2.2 Least Used Policy 992 When the destination Pool is under the Least Used server pooling 993 policy, the ASAP endpoint of the message sender will select the PE that 994 has the lowest policy value in the group as the receiver of the 995 current message. If more than one PE from the group share the same 996 lowest policy value, the selection will be done round Robin amongst 997 those PEs. 999 It is important to note that this policy means that the same PE will 1000 be always selected as the message receiver by the sender until the 1001 load control information of the pool is updated and changed in the 1002 local cache of the sender (via a cache update see section 3.3). 1004 4.5.2.3 Least Used with Degradation Policy 1006 This policy is the same as the Least Used policy with the exception 1007 that, each time the PE with the lowest policy value is selected from 1008 the Pool as the receiver of the current message, its policy value is 1009 incremented, and thus it may no longer be the lowest value in the 1010 Pool. 1012 This provides a degradation of the policy towards round Robin policy 1013 over time. As with the Least Used policy, every local cache update 1014 at the sender will bring the policy back to Least Used with 1015 Degradation. 1017 4.5.2.4 Weighted Round Robin Policy 1019 [TBD] 1021 4.5.3 Sending to a Pool Element Handle 1023 In this case the destinationAddress and typeOfAddress together 1024 indicate an ASAP Pool Element handle. 1026 This requests the ASAP endpoint to deliver the message to the PE 1027 identified by the Pool Element handle. 1029 The Pool Element handle should contain the Pool Handle and a 1030 destination transport address of the destination PE or the 1031 Pool Handle and the transport type. Other implementation 1032 dependant elements may also be cached in a Pool Element handle. 1034 The ASAP endpoint shall use the transport address and transport type 1035 to identify the endpoint to communicate with. If no communication 1036 state exists with the peer endpoint (and is required by the 1037 transport protocol) the ASAP endpoint MAY setup the needed state and 1038 then invoke the SEND primitive for the particular transport 1039 protocol to send the message to the PE. 1041 In addition, if a local translation cache is supported the 1042 endpoint will: 1044 A) send out the message to the transport address (or association 1045 id) designated by the PE handle. 1047 B) determine if the Pool Handle is in the local cache. 1049 If it is NOT, the endpoint will: 1051 i) ask the home ENRP server for name resolution on pool handle 1052 by sending a NAME.RESOLUTION message (see Section 3.3), and 1053 ii) use the response to update the local cache. 1055 If the pool handle is in the cache, the endpoint will only 1056 update the pool handle if the cache is stale. A stale cache is 1057 indicated by it being older than the protocol parameter 1058 'stale.cache.value' (see section 3.3). 1060 Section 3.5 and 4.9 defines the fail-over procedures for cases where 1061 the PE pointed to by the Pool Element handle is found unreachable. 1063 Optionally, the ASAP endpoint may return the actual Pool Element handle 1064 to which the message was sent (this may be different from the Pool 1065 Element handle specified when the primitive is invoked, due to the 1066 possibility of automatic fail-over). 1068 4.5.4 Send by Transport Address 1070 In this case the destinationAddress and typeOfAddress together 1071 indicate a transport address and transport type. 1073 This directs the senders ASAP endpoint to send the message out to the 1074 specified transport address. 1076 No endpoint fail-over is support when this form of send request is 1077 used. This form of send request effectively by-passes the ASAP 1078 endpoint. 1080 4.5.5 Message Delivery Options 1082 The Options parameter passed in the various forms of the above 1083 data.send.request primitive gives directions to the senders ASAP 1084 endpoint on special handling of the message delivery. 1086 The value of the Options parameter is generated by bit-wise "OR"ing 1087 of the following pre-defined constants: 1089 ASAP_USE_DEFAULT: 0x0000 1091 Use default setting. 1093 ASAP_SEND_FAILOVER: 0x0001 1095 Enables PE fail-over on this message. In case where the first 1096 selected PE or the PE pointed to by the PE handle is found 1097 unreachable, this option allows the senders ASAP endpoint to 1098 re-select an alternate PE from the same pool if one exists, and 1099 silently re-send the message to this newly selected endpoint. 1101 ASAP_SEND_NO_FAILOVER: 0x0002 1102 This option prohibits the senders ASAP endpoint from re-sending the 1103 message to any alternate PE in case that the first selected PE or 1104 the PE pointed to by the PE handle is found unreachable. Instead, 1105 the senders ASAP endpoint shall notify its upper layer about the 1106 unreachability with an Error.Report and return any unsent data. 1108 ASAP_SEND_TO_LAST: 0x0004 1110 This option requests the senders ASAP endpoint to send the message to 1111 the same PE in the pool that the previous message destined to this 1112 pool was sent to. 1114 ASAP_SEND_TO_ALL: 0x0008 1116 When sending by Pool Handle, this option directs the senders ASAP 1117 endpoint to send a copy of the message to all the PEs, except for 1118 the sender itself if the sender is a PE, in that pool. 1120 ASAP_SEND_TO_SELF: 0x0010. 1122 This option only applies in combination with ASAP_SEND_TO_ALL option. 1123 It permits the senders ASAP endpoint also deliver a copy of the 1124 message to itself if the sender is a PE of the pool (i.e., loop-back). 1126 ASAP_SCTP_UNORDER: 0x1000 1128 This option requests the transport layer to send the current 1129 message using un-ordered delivery (note the underlying transport 1130 must support un-ordered delivery for this option to be effective). 1132 4.6 Data.Received Notification 1134 Format: data.received(messageReceived, sizeOfMessage, senderAddress, 1135 typeOfAddress) 1136 When a new user message is received, the ASAP endpoint of the receiver 1137 uses this notification to pass the message to its upper layer. 1139 Along with the message being passed, the ASAP endpoint of the receiver 1140 should also indicate to its upper layer the message senders 1141 address. The senders address can be in the form of either an SCTP 1142 association id, TCP transport address, UDP transport address, or 1143 a ASAP Pool Element handle. 1145 A) If the name translation local cache is implemented at the 1146 receiver's ASAP endpoint, a reverse mapping from the senders IP 1147 address to the pool handle should be performed and if the mapping is 1148 successful, the senders ASAP Pool Element handle should be 1149 constructed and passed in the senderAddress field. 1151 B) If there is no local cache or the reverse mapping is not 1152 successful, the SCTP association id or other transport 1153 specific identification (if SCTP is not being used) should be 1154 passed in the senderAddress field. 1156 4.7 Error.Report Notification 1158 Format: error.report(destinationAddress, typeOfAddress, 1159 failedMessage, sizeOfMessage) 1161 An error.report should be generated to notify the ASAP user about 1162 failed message delivery as well as other abnormalities. 1164 The destinationAddress and typeOfAddress together indicates to whom 1165 the message was originally sent. The address type can be either a 1166 ASAP Pool Element handle, association id, or a transport address. 1168 The original message (or the first portion of it if the message is 1169 too big) and its size should be passed in the failedMessage and 1170 sizeOfMessage fields, respectively. 1172 4.8 Examples 1174 These examples assume an underlying SCTP transport between the PE 1175 and PU. Other transports are possible but SCTP is utilized in the 1176 examples for illustrative purposes. Note that all communication 1177 between PU and ENRP server and PE and ENRP servers would be using 1178 SCTP. 1180 4.8.1 Send to a New Pool 1182 This example shows the event sequence when a Pool User sends the 1183 message "hello" to a pool which is not in the local 1184 translation cache (assuming local caching is supported). 1186 ENRP Server PU new-name:PEx 1188 | | | 1189 | +---+ | 1190 | | 1 | | 1191 | 2. NAME_RESOLUTION +---+ | 1192 |<-------------------------------| | 1194 | +---+ | 1195 | | 3 | | 1196 | 4. NAME_RESOLUTION_REPONSE +---+ | 1197 |------------------------------->| | 1198 | +---+ | 1199 | | 5 | | 1200 | +---+ 6. "hello1" | 1201 | |---------------->| 1202 | | | 1204 1) The user at PU invokes: 1206 data.send.request("new-name", name-type, "hello1", 6, 0); 1208 The ASAP endpoint, in response, looks up the pool "new-name" in its 1209 local cache but fails to find it. 1211 2) The ASAP endpoint of PU queues the message, and sends a 1212 NAME_RESOLUTION request to the ENRP server asking for all 1213 information about pool "new-name". 1215 3) A T1-ENRPrequest timer is started while the ASAP endpoint is waiting 1216 for the response from the ENRP server. 1218 4) The ENRP Server responds to the query with a 1219 NAME_RESOLUTION_REPONSE message that contains all the information 1220 about pool "new-name". 1222 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its 1223 local cache with information on pool "new-name". 1225 6) Based on the server pooling policy of pool "new-name", ASAP at 1226 PU selects the destination PE (PEx), sets up, if necessary, an 1227 SCTP association towards PEx (explicitly or implicitly), and 1228 send out the queued "hello1" user message. 1230 4.8.2 Send to a Cached Pool Handle 1232 This shows the event sequence when the ASAP user PU sends 1233 another message to the pool "new-name" after what happened in 1234 Section 4.8.1. 1236 ENRP Server PU new-name:PEx 1238 | | | 1239 | +---+ | 1240 | | 1 | | 1241 | +---+ 2. "hello2" | 1242 | |---------------->| 1243 | | | 1245 1) The user at PU invokes: 1247 data.send.request("new-name", name-type, "hello2", 6, 0); 1249 The ASAP endpoint, in response, looks up the pool "new-name" in its 1250 local cache and find the mapping information. 1252 2) Based on the server pooling policy of "new-name", ASAP at PU 1253 selects the PE (assume EPx is selected again), and sends out 1254 "hello2" message (assume the SCTP association is already set 1255 up). 1257 4.9 PE send failure 1259 When the ASAP endpoint in a PE or PU attempts to send a message to a 1260 PE and fails the failed sender will report the event as described 1261 in section 3.5 1263 Additional primitive are also defined in this section to support 1264 those user applications that do not wish to use ASAP as the actual 1265 transport. 1267 4.9.1 Translation.Request Primitive 1269 Format: translation.request(Pool-Handle) 1271 If the address type is a Pool handle and a local name 1272 translation cache exists, the ASAP endpoint should look within 1273 its translation cache and return the current known transport 1274 types, ports and addresses to the caller. 1276 If the Pool handle does not exist in the local name cache or no name 1277 cache exists, the ASAP endpoint will send a NAME.RESOLUTION request 1278 using the Pool-Handle. Upon completion of the name resolution, the 1279 ASAP endpoint should populate the local name cache (if a local name 1280 cache is supported) and return the transport types, ports and 1281 addresses to the caller. 1283 4.9.2 Transport.Failure Primitive 1285 Format: transport.failure(Pool-Handle, Transport-address) 1287 If an external user encounters a failure in sending to a PE and is 1288 NOT using ASAP it can use this primitive to report the failure to 1289 the ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" 1290 ENRP server in response to this primitive. Note ASAP SHOULD NOT send 1291 a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous 1292 request to the translate.request() primitive. 1294 5. Variables, Timers, and Constants 1296 The following is a summary of the variables, timers, and pre-set 1297 protocol constants used in ASAP. 1299 5.1 Timers 1301 T1-ENRPrequest - A timer started when a request is sent by ASAP to 1302 the ENRP server (providing application information is 1303 queued). Normally set to 15 seconds. 1305 T2-registration - A timer started when sending a registration 1306 request to the home ENRP server, normally set to 30 seconds. 1308 T3-deregistration- A timer started when sending a deregistration 1309 request to the home ENRP server, normally set to 30 seconds. 1311 T4-reregistration - This timer is started after successful 1312 registration into the ASAP name space and is used to cause a 1313 re-registration at a periodic interval. This timer is normally set 1314 to 10 minutes or 20 seconds less than the Life Timer parameter used 1315 in the registration request (whichever is less). 1317 T5-Serverhunt - This timer is used nto during the ENRP server hunt 1318 procedure and is normally set to 120 seconds. 1320 5.2 Thresholds and Variables 1322 max-reg-attempt - The maximum number of registration attempts to be 1323 made before a server hunt is issued. 1325 max-request-retransmit - The maximum number of attempts to be made 1326 when requesting information from the local ENRP server before a 1327 server hunt is issued. 1329 stale.cache.value - A threshold variable that indicates how long 1330 a cache entry is valid for. 1332 6. Security Considerations 1334 Due to varying requirements and multiple use cases of Rserpool, we 1335 point out two basic security protocols, IPsec and TLS. We 1336 specifically do not discuss whether one security protocol would be 1337 preferred over the other. This choice will be made by designers 1338 and network architects based on system requirements. 1340 For networks that demand IPsec security, implementations MUST 1341 support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two 1342 layers below RSerPool. Therefore, if IPsec is used for securing 1343 Rserpool, no changes or special considerations need to be made to 1344 Rserpool to secure the protocol. 1346 For networks that cannot or do not wish to use IPsec and prefer 1347 instead TLS, implementations MUST support TLS with SCTP as 1348 described in [SCTPTLS] or TLS over TCP as described in [RFC2246]. 1349 When using TLS/SCTP we must ensure that RSerPool does not use any 1350 features of SCTP that are not available to an TLS/SCTP user. This 1351 is not a difficult technical problem, but simply a 1352 requirement. When describing an API of the RSerPool lower layer we 1353 have also to take into account the differences between TLS and 1354 SCTP. This is also not difficult, but it is in contrast to the 1355 IPsec solution which is transparently layered below Rserpool. 1357 Support for security is required for the ENRP server and the PEs. 1358 Security support for the Rserpool end user is optional. Note that 1359 the end user implementation contains a piece of the Rserpool 1360 protocol -- namely ASAP -- whereby the pool handle is passed for 1361 name resolution to the ENRP server and IP address(es) are 1362 returned. 1364 The argument for optional end user security is as follows: If the 1365 user doesn't require security protection for example, against 1366 eavesdropping for the request for pool handle resolution and 1367 response, then they are free to make that choice. However, if the 1368 end user does require security, they are guaranteed to get it due 1369 to the requirement for security support for the ENRP server. It is 1370 also possible for the ENRP server to reject an unsecured request 1371 from the user due to its security policy in the case that it 1372 requires enforcement of strong security. But this will be 1373 determined by the security requirements of the individual network 1374 design. 1376 7. References 1378 [RFC2026] Bradner, S., "The Internet Standards Process -- 1379 Revision 3", BCP 9, RFC 2026, October 1996. 1381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1382 Requirement Levels", BCP 14, RFC 2119, March 1997. 1384 [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1385 H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 1386 and, V. Paxson, "Stream Control Transmission Protocol," RFC 1387 2960, October 2000. 1389 [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", 1390 draft-ietf-rserpool-enrp-02.txt, work in progress. 1392 [SCTPAPI] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon, 1393 K. Fujita "Sockets API Extensions for SCTP", 1394 draft-ietf-tsvwg-sctpsocket-01.txt, work in progress. 1396 [SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", 1397 draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. 1399 [SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis, 1400 R.R. Stewart, "On the Use of SCTP with IPsec", 1401 draft-ietf-ipsec-sctp-03.txt, work in progress. 1403 [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", 1404 RFC 2246, January 1999. 1406 [ENRP-ASAP] - New draft. 1408 17.1 Bibliography 1410 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1411 Security", RFC 1750, December 1994. 1413 8. Acknowledgments 1415 The authors wish to thank John Loughney, Lyndon Ong, and many 1416 others for their invaluable comments. 1418 9. Authors' Addresses 1420 Randall R. Stewart Tel: +1-815-477-2127 1421 Cisco Systems, Inc. EMail: rrs@cisco.com 1422 8725 West Higgins Road 1423 Suite 300 1424 Chicago, Ill 60631 1426 Qiaobing Xie Phone: +1-847-632-3028 1427 Motorola, Inc. EMail: qxie1@email.mot.com 1428 1501 W. Shure Drive, 2-F9 1429 Arlington Heights, IL 60004 1430 USA 1432 Maureen Stillman Phone: +1 607 273 0724 62 1433 Nokia EMail: maureen.stillman@nokia.com 1434 127 W. State Street 1435 Ithaca, NY 14850 1436 USA