RFC 5352
Aggregate Server Access Protocol (ASAP)
Pages: 53
Experimental
Experimental
Part 1 of 3 – Pages 1 to 18
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.
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
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
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.
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].
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.
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 12.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
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].
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
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.
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.
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].
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].
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].
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.
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].
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].
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)