tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5352

Experimental
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: RSERPOOL

Aggregate Server Access Protocol (ASAP)

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part