Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5352

Aggregate Server Access Protocol (ASAP)

Pages: 53
Experimental
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC5352 - Page 1
Network Working Group                                         R. Stewart
Request for Comments: 5352                                        Q. Xie
Category: Experimental                                The Resource Group
                                                             M. Stillman
                                                                   Nokia
                                                               M. Tuexen
                                      Muenster Univ. of Applied Sciences
                                                          September 2008


                Aggregate Server Access Protocol (ASAP)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol. The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service.
Top   ToC   RFC5352 - Page 2

Table of Contents

1. Introduction ....................................................4 1.1. Definitions ................................................4 1.2. Conventions ................................................5 1.3. Organization of This Document ..............................6 1.4. Scope of ASAP ..............................................6 1.4.1. Extent of the Handlespace ...........................6 2. Message Definitions .............................................6 2.1. ASAP Parameter Formats .....................................7 2.2. ASAP Messages ..............................................7 2.2.1. ASAP_REGISTRATION Message ...........................7 2.2.2. ASAP_DEREGISTRATION Message .........................8 2.2.3. ASAP_REGISTRATION_RESPONSE Message ..................9 2.2.4. ASAP_DEREGISTRATION_RESPONSE Message ...............10 2.2.5. ASAP_HANDLE_RESOLUTION Message .....................10 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message ............11 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message ...................13 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message ...............14 2.2.9. ASAP_ENDPOINT_UNREACHABLE Message ..................14 2.2.10. ASAP_SERVER_ANNOUNCE Message ......................15 2.2.11. ASAP_COOKIE Message ...............................16 2.2.12. ASAP_COOKIE_ECHO Message ..........................16 2.2.13. ASAP_BUSINESS_CARD Message ........................17 2.2.14. ASAP_ERROR Message ................................17 3. Procedures .....................................................18 3.1. Registration ..............................................18 3.2. De-Registration ...........................................21 3.3. Handle Resolution .........................................23 3.4. Endpoint Keep Alive .......................................25 3.5. Unreachable Endpoints .....................................26 3.6. ENRP Server Hunt Procedures ...............................27 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures ....................................28 3.7.1. SCTP Send Failure ..................................28 3.7.2. T1-ENRPrequest Timer Expiration ....................29 3.7.3. Registration Failure ...............................29 3.8. Cookie Handling Procedures ................................29 3.9. Business Card Handling Procedures .........................30 4. Roles of Endpoints .............................................31 5. SCTP Considerations ............................................31 6. The ASAP Interfaces ............................................31 6.1. Registration.Request Primitive ............................32 6.2. Deregistration.Request Primitive ..........................32 6.3. CachePopulateRequest Primitive ............................33 6.4. CachePurgeRequest Primitive ...............................33 6.5. DataSendRequest Primitive .................................33 6.5.1. Sending to a Pool Handle ...........................34
Top   ToC   RFC5352 - Page 3
           6.5.2. Pool Element Selection .............................35
                  6.5.2.1. Round-Robin Policy ........................35
           6.5.3. Sending to a Pool Element Handle ...................35
           6.5.4. Send by Transport Address ..........................37
           6.5.5. Message Delivery Options ...........................37
      6.6. Data.Received Notification ................................38
      6.7. Error.Report Notification .................................39
      6.8. Examples ..................................................39
           6.8.1. Send to a New Pool .................................39
           6.8.2. Send to a Cached Pool Handle .......................40
      6.9. PE Send Failure ...........................................41
           6.9.1. Translation.Request Primitive ......................41
           6.9.2. Transport.Failure Primitive ........................42
   7. Timers, Variables, and Thresholds ..............................42
      7.1. Timers ....................................................42
      7.2. Variables .................................................42
      7.3. Thresholds ................................................43
   8. IANA Considerations ............................................43
      8.1. A New Table for ASAP Message Types ........................43
      8.2. Port Numbers ..............................................44
      8.3. SCTP Payload Protocol Identifier ..........................44
      8.4. Multicast Addresses .......................................44
   9. Security Considerations ........................................44
      9.1. Summary of RSerPool Security Threats ......................45
      9.2. Implementing Security Mechanisms ..........................46
      9.3. Chain of Trust ............................................49
   10. Acknowledgments ...............................................50
   11. References ....................................................50
      11.1. Normative References .....................................50
      11.2. Informative References ...................................51
Top   ToC   RFC5352 - Page 4

1. Introduction

The Aggregate Server Access Protocol (ASAP), when used in conjunction with Endpoint Name Resolution Protocol [RFC5353], provides a high- availability data-transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure. When multiple receiver instances exist under the same handle (aka a server pool), an ASAP Endpoint will select one Pool Element (PE), based on the current load sharing policy indicated by the server pool, and deliver its message to the selected PE. While delivering the message, ASAP can be used to monitor the reachability of the selected PE. If it is found unreachable, before notifying the message sender (an ASAP User) of the failure, ASAP can automatically select another PE (if one exists) under that pool and attempt to deliver the message to that PE. In other words, ASAP is capable of transparent failover amongst PE instances within a server pool. ASAP depends on ENRP, which provides a high-availability Pool Handlespace. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as presentation to the upper layer (aka an ASAP User) via a unified primitive interface. When SCTP [RFC4960] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by SCTP. This document defines the ASAP portion of the high-availability server pool.

1.1. Definitions

This document uses the following terms: ASAP User: Either a PE or Pool User (PU) that uses ASAP. Business Card: When presented by a PU or PE, it specifies the pool the sender belongs to and provides a list of alternate PEs in case of failovers.
Top   ToC   RFC5352 - Page 5
   Operational Scope:  The part of the network visible to pool users by
      a specific instance of the reliable server pooling protocols.

   Pool (or Server Pool):  A collection of servers providing the same
      application functionality.

   Pool Handle:  A logical pointer to a pool.  Each server pool will be
      identifiable in the operational scope of the system by a unique
      Pool Handle.

   Pool Element:  A server entity having registered to a pool.

   Pool User:  A server pool user.

   Pool Element Handle (or Endpoint Handle):  A logical pointer to a
      particular Pool Element in a pool, consisting of the Pool Handle
      and a destination transport address of the Pool Element.

   Handlespace:  A cohesive structure of Pool Handles and relations that
      may be queried by an internal or external agent.

   Home ENRP Server:  The ENRP server to which a PE or PU currently
      sends all namespace service requests.  A PE must only have one
      Home ENRP server at any given time, and both the PE and its Home
      ENRP server MUST know and keep track of this relationship.  A PU
      should select one of the available ENRP servers as its Home ENRP
      server, but the collective ENRP servers may change this by the
      sending of an ASAP_ENDPOINT_KEEP_ALIVE message.

   ENRP Client Channel:  The communication channel through which an ASAP
      User sends all namespace service requests.  The client channel is
      usually defined by the transport address of the Home ENRP server
      and a well-known port number.  The channel MAY make use of
      multicast or a named list of ENRP servers.

   Network Byte Order:  Most significant byte first, aka Big Endian.

   Transport Address:  A transport address is traditionally defined by
      Network Layer address, Transport Layer protocol and Transport
      Layer port number.  In the case of SCTP running over IP, a
      transport address is defined by the combination of an IP address
      and an SCTP port number (where SCTP is the Transport protocol).

1.2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Top   ToC   RFC5352 - Page 6

1.3. Organization of This Document

Section 2 details the ASAP message formats. In Section 3, we provide detailed ASAP procedures for the ASAP implementer. Section 4 summarizes which messages need to be supported by which nodes, and Section 5 describes the usage of SCTP. In Section 6, details of the ASAP interface are given, focusing on the communication primitives between ASAP, the applications above ASAP, and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layers). Also included in this discussion are relevant timers and configurable parameters, as appropriate. Section 7 provides threshold and protocol variables. It should be noted that variables, timers, and constants are used in the text when necessary. The complete list can be found in Section 7.

1.4. Scope of ASAP

The requirements for high availability and scalability do not imply requirements on shared state and data. ASAP does not provide transaction failover. If a host or application fails during the processing of a transaction, this transaction may be lost. Some services MAY provide a way to handle the failure, but this is not guaranteed. ASAP MAY provide hooks to assist an application in building a mechanism to share state but ASAP in itself does NOT share any state.

1.4.1. Extent of the Handlespace

The scope of ASAP/ENRP is NOT Internet-wide. The handlespace is neither hierarchical nor arbitrarily large like DNS. A flat peer-to- peer model is detailed. Pools of servers will exist in different administrative domains. For example, suppose the use of ASAP and ENRP is wanted. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact a server pool in Japan instead of North America. The PU would use DNS to get the list of IP addresses of the Japanese server pool; that is, the ENRP client channel in Japan. From there, the PU would query the Home ENRP server it established and then directly contact the PE(s) of interest.

2. Message Definitions

All messages, as well as their fields described below, shall be in network byte order during transmission. For fields with a length bigger than 4 bytes, a number in a pair of parentheses may follow the field name to indicate the length of the field in number of bytes.
Top   ToC   RFC5352 - Page 7

2.1. ASAP Parameter Formats

The basic message format and all parameter formats can be found in [RFC5354]. Note also that *all* ASAP messages exchanged between an ENRP server and a PE MUST use SCTP as transport, while ASAP messages exchanged between an ENRP server and a PU MUST use either SCTP or TCP as transport. PE to PU data traffic MAY use any transport protocol specified by the PE during registration.

2.2. ASAP Messages

This section details the individual messages used by ASAP. These messages are composed of a standard message format found in Section 4 of [RFC5354]. The parameter descriptions can be found in [RFC5354]. The following ASAP message types are defined in this section: Type Message Name ----- ------------------------- 0x00 - (Reserved by IETF) 0x01 - ASAP_REGISTRATION 0x02 - ASAP_DEREGISTRATION 0x03 - ASAP_REGISTRATION_RESPONSE 0x04 - ASAP_DEREGISTRATION_RESPONSE 0x05 - ASAP_HANDLE_RESOLUTION 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 0x09 - ASAP_ENDPOINT_UNREACHABLE 0x0a - ASAP_SERVER_ANNOUNCE 0x0b - ASAP_COOKIE 0x0c - ASAP_COOKIE_ECHO 0x0d - ASAP_BUSINESS_CARD 0x0e - ASAP_ERROR others - (Reserved by IETF) Figure 1

2.2.1. ASAP_REGISTRATION Message

The ASAP_REGISTRATION message is sent by a PE to its Home ENRP server to either create a new pool or to add itself to an existing pool. The PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle parameter and the Pool Element parameter. The Pool Handle parameter specifies the name to be registered. The Pool Element parameter MUST be filled in by the registrant, as outlined in Section 3.1. Note that the PE sending the registration message MUST
Top   ToC   RFC5352 - Page 8
   send the message using an SCTP association.  Furthermore, the IP
   address(es) of the PE that is registered within the Pool Element
   parameter MUST be a subset of the IP address(es) used in the SCTP
   association, regardless of the registered transport protocol.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x01 |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Pool Handle Parameter:

   See [RFC5354].

   Pool Element Parameter:

   See [RFC5354].

2.2.2. ASAP_DEREGISTRATION Message

The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP server to remove itself from a pool to which it registered. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ Pool Handle Parameter: See [RFC5354]. PE Identifier Parameter: See [RFC5354].
Top   ToC   RFC5352 - Page 9
   The PE sending the ASAP_DEREGISTRATION MUST fill in the Pool Handle
   and the PE identifier parameter in order to allow the ENRP server to
   verify the identity of the endpoint.  Note that de-registration is
   NOT allowed by proxy; in other words, a PE may only de-register
   itself.

2.2.3. ASAP_REGISTRATION_RESPONSE Message

The ASAP_REGISTRATION_RESPONSE message is sent in response by the Home ENRP server to the PE that sent an ASAP_REGISTRATION message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x03 |0|0|0|0|0|0|0|R| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reject) Flag: When set to '1', this flag indicates that the ENRP server sending this message has rejected the registration. Otherwise, when this flag is set to '0', this indicates the registration has been granted. Pool Handle Parameter: See [RFC5354]. PE Identifier Parameter: See [RFC5354]. Operational Error Parameter (optional): See [RFC5354]. This parameter is included if an error or some atypical events occurred during the registration process. When the R flag is set to '1', this parameter, if present, indicates the cause of the rejection. When the R flag is set to '0', this parameter, if present, serves as a warning to the registering PE, informing it that
Top   ToC   RFC5352 - Page 10
   some of its registration values may have been modified by the ENRP
   server.  If the registration was successful and there is no warning,
   this parameter is not included.

2.2.4. ASAP_DEREGISTRATION_RESPONSE Message

The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP server to a PE in response to an ASAP_DEREGISTRATION message or due to the expiration of the registration life of the PE in the pool. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [RFC5354]. PE Identifier Parameter: See [RFC5354]. Operational Error: See [RFC5354]. This parameter is included if an error or some atypical events occurred during the de-registration process. If the de-registration was successful this parameter is not included.

2.2.5. ASAP_HANDLE_RESOLUTION Message

The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to its Home ENRP server to resolve a Pool Handle into a list of Pool Elements that are members of the pool indicated by the Pool Handle.
Top   ToC   RFC5352 - Page 11
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x05 |0|0|0|0|0|0|0|S|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'S' bit:

   The 'S' bit, if set to '1', requests the Home ENRP server to send
   updates to this Pool dynamically when the Pool changes for the
   lifetime of the SCTP association.  Dynamic updates to the pool will
   consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages,
   without the user needing to send in an ASAP_HANDLE_RESOLUTION.

   If the 'S' bit is set to '0', no Dynamic updates are requested.

   Note that if a new Home ENRP server is adopted, any 'dynamic update
   request' will need to be re-sent to the new Home ENPR server if the
   endpoint would like to continue to receive updates.  In other words,
   the ENRP servers do NOT share state regarding which of its PU's are
   requesting automatic update of state.  Thus, upon change of Home ENRP
   server, the PU will need to re-send an ASAP_HANDLE_RESOLUTION message
   with the 'S' bit set to '1'.  Note also, that the 'S' bit will only
   cause Dynamic update of a Pool when the Pool exists.  If a negative
   response is returned, no further updates to the Pool (when it is
   created) will occur.

   Pool Handle Parameter:

   See [RFC5354].

2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message

The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by the Home ENRP server of the PU or PE that sent an ASAP_HANDLE_RESOLUTION message or is sent periodically upon Pool changes if the PU has requested Dynamic updates.
Top   ToC   RFC5352 - Page 12
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x06 |0|0|0|0|0|0|0|A|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :             Overall PE Selection Policy (optional)            :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :               Pool Element Parameter 1 (optional)             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :               Pool Element Parameter N (optional)             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Operational Error (optional)                :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   'A' bit:

   This bit is set to '1' if the ENRP server accepts the request to send
   automatic updates (i.e., the 'S' bit was set on the request).  If
   this bit is set to '0', either the ENRP server does NOT support
   automatic updates, it has resource issues and cannot supply this
   feature, or the user did not request it.

   Pool Handle Parameter:

   See [RFC5354].

   Overall PE Selection Policy (optional):

   See [RFC5354].

   This parameter can be present when the response is positive.  If
   present, it indicates the overall pool member selection policy of the
   pool.  If not present, a Round-Robin overall pool member selection
   policy is assumed.  This parameter is not present when the response
   is negative.

   Note, any load policy parameter within a Pool Element parameter (if
   present) MUST be ignored, and MUST NOT be used to determine the
   overall pool member selection policy.

   Pool Element Parameters (optional):

   See [RFC5354].
Top   ToC   RFC5352 - Page 13
   When the response is positive, an array of PE parameters are
   included, indicating the current information about the PEs in the
   named pool.  At least one PE parameter MUST be present.  When the
   response is negative, no PE parameters are included.

   Operational Error (optional):

   See [RFC5354].

   The presence of this parameter indicates that the response is
   negative (the handle resolution request was rejected by the ENRP
   server).  The cause code in this parameter (if present) will indicate
   the reason the handle resolution request was rejected (e.g., the
   requested Pool Handle was not found).  The absence of this parameter
   indicates that the response is positive.

2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message

The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the PE is reachable and requires the PE to adopt the sending server as its new Home ENRP server if the 'H' bit is set to '1'. Regardless of the setting of the 'H' bit, an ASAP Endpoint MUST respond with an ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages that arrive. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H (Home ENRP server) Flag: When set to '1', indicates that the ENRP server that sends this message wants to be the Home ENRP server of the receiver of this message. Server Identifier: 32 bits (unsigned integer) This is the ID of the ENRP server, as discussed in [RFC5353].
Top   ToC   RFC5352 - Page 14
   Pool Handle Parameter:

   See [RFC5354].

2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message

The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP server. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [RFC5354]. PE Identifier Parameter: See [RFC5354].

2.2.9. ASAP_ENDPOINT_UNREACHABLE Message

The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to its Home ENRP server to report an unreachable PE. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [RFC5354].
Top   ToC   RFC5352 - Page 15
   PE Identifier Parameter:

   See [RFC5354].

2.2.10. ASAP_SERVER_ANNOUNCE Message

The ASAP_SERVER_ANNOUNCE message is sent by an ENRP server such that PUs and PEs know the transport information necessary to connect to the ENRP server. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport Param #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport Param #2 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ..... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport Param #n : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Server Identifier: 32 bits (unsigned integer) This is the ID of the ENRP server, as discussed in [RFC5353]. Transport Parameters (optional): See [RFC5354] for the SCTP and TCP Transport parameters. Only SCTP and TCP Transport parameters are allowed for use within the SERVER_ANNOUNCE message.
Top   ToC   RFC5352 - Page 16

2.2.11. ASAP_COOKIE Message

The ASAP_COOKIE message is sent by a PE to a PU, allowing the PE to convey information it wishes to share using a control channel. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Cookie Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cookie Parameter : See [RFC5354].

2.2.12. ASAP_COOKIE_ECHO Message

The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it detects a failure with the current PE to aid in failover. The Cookie Parameter sent by the PE is the latest one received from the failed PE. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Cookie Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cookie Parameter: See [RFC5354].
Top   ToC   RFC5352 - Page 17

2.2.13. ASAP_BUSINESS_CARD Message

The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE to a PU using a control channel to convey the pool handle and a preferred failover ordering. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter-1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : .. : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter-N : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [RFC5354]. Pool Element Parameters: See [RFC5354].

2.2.14. ASAP_ERROR Message

The ASAP_ERROR message is sent in response by an ASAP Endpoint receiving an unknown message or an unknown parameter to the sending ASAP Endpoint to report the problem or issue. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operational Error Parameter: See [RFC5354].
Top   ToC   RFC5352 - Page 18
   When an ASAP Endpoint receives an ASAP message with an unknown
   message type or a message of known type that contains an unknown
   parameter, it SHOULD handle the unknown message or the unknown
   parameter according to the unrecognized message and parameter
   handling rules, defined in Section 3.

   According to the rules, if an error report to the message sender is
   needed, the ASAP endpoint that discovered the error SHOULD send back
   an ASAP_ERROR message that includes an Operational Error parameter
   with the proper cause code, cause length, and case-specific
   information.



(page 18 continued on part 2)

Next Section