draft-ietf-rserpool-asap-21.txt   rfc5352.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Q. Xie Request for Comments: 5352 Q. Xie
Intended status: Experimental Category: Experimental The Resource Group
Expires: January 12, 2009 M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
July 11, 2008 September 2008
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-21.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009. 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 Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction
Endpoint Handlespace Redundancy Protocol (ENRP) with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353),
[I-D.ietf-rserpool-enrp] provides a high availability data transfer provides a high-availability data transfer mechanism over IP
mechanism over IP networks. ASAP uses a handle-based addressing networks. ASAP uses a handle-based addressing model that isolates a
model which isolates a logical communication endpoint from its IP logical communication endpoint from its IP address(es), thus
address(es), thus effectively eliminating the binding between the effectively eliminating the binding between the communication
communication endpoint and its physical IP address(es) which normally endpoint and its physical IP address(es), which normally constitutes
constitutes a single point of failure. a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
pool, providing full transparent support for server-pooling and load pool, providing full transparent support for server pooling and load
sharing. It also allows dynamic system scalability - members of a sharing. It also allows dynamic system scalability -- members of a
server pool can be added or removed at any time without interrupting server pool can be added or removed at any time without interrupting
the service. the service.
ASAP is designed to take full advantage of the network level ASAP is designed to take full advantage of the network level
redundancy provided by the Stream Transmission Control Protocol redundancy provided by the Stream Transmission Control Protocol
(SCTP) [RFC4960]. Each transport protocol, other than SCTP, MUST (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST
have an accompanying transport mapping document. It should be noted have an accompanying transport mapping document. It should be noted
that ASAP messages passed between PE's and ENRP servers MUST use the that ASAP messages passed between Pool Elements (PEs) and ENRP
SCTP transport protocol. servers MUST use the SCTP transport protocol.
The high availability server pooling is gained by combining two The high-availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for pool handle to address translation, load sharing interface for Pool Handle to address translation, load sharing
management, and fault management while ENRP defines the high management, and fault management, while ENRP defines the high-
availability pool handle translation service. availability Pool Handle translation service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Definitions ................................................4
1.2. Organization of this document . . . . . . . . . . . . . . 6 1.2. Conventions ................................................5
1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Organization of This Document ..............................6
1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 1.4. Scope of ASAP ..............................................6
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Extent of the Handlespace ...........................6
2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 2. Message Definitions .............................................6
2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.1. ASAP Parameter Formats .....................................7
2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2. ASAP Messages ..............................................7
2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 2.2.1. ASAP_REGISTRATION Message ...........................7
2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 2.2.2. ASAP_DEREGISTRATION Message .........................8
2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 2.2.3. ASAP_REGISTRATION_RESPONSE Message ..................9
2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 11 2.2.4. ASAP_DEREGISTRATION_RESPONSE Message ...............10
2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 2.2.5. ASAP_HANDLE_RESOLUTION Message .....................10
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 12 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message ............11
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 14 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message ...................13
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 15 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message ...............14
2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 15 2.2.9. ASAP_ENDPOINT_UNREACHABLE Message ..................14
2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 16 2.2.10. ASAP_SERVER_ANNOUNCE Message ......................15
2.2.11. ASAP_COOKIE message . . . . . . . . . . . . . . . . . 16 2.2.11. ASAP_COOKIE Message ...............................16
2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 17 2.2.12. ASAP_COOKIE_ECHO Message ..........................16
2.2.13. ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . 17 2.2.13. ASAP_BUSINESS_CARD Message ........................17
2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 18 2.2.14. ASAP_ERROR Message ................................17
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Procedures .....................................................18
3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Registration ..............................................18
3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 22 3.2. De-Registration ...........................................21
3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 23 3.3. Handle Resolution .........................................23
3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 25 3.4. Endpoint Keep Alive .......................................25
3.5. Unreachable endpoints . . . . . . . . . . . . . . . . . . 26 3.5. Unreachable Endpoints .....................................26
3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 27 3.6. ENRP Server Hunt Procedures ...............................27
3.7. Handling ASAP Endpoint to ENRP Server Communication 3.7. Handling ASAP Endpoint to ENRP Server
Failures . . . . . . . . . . . . . . . . . . . . . . . . . 29 Communication Failures ....................................28
3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 29 3.7.1. SCTP Send Failure ..................................28
3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 29 3.7.2. T1-ENRPrequest Timer Expiration ....................29
3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 30 3.7.3. Registration Failure ...............................29
3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 30 3.8. Cookie Handling Procedures ................................29
3.9. Business Card handling procedures . . . . . . . . . . . . 30 3.9. Business Card Handling Procedures .........................30
4. Roles of Endpoints . . . . . . . . . . . . . . . . . . . . . . 32 4. Roles of Endpoints .............................................31
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 33 5. SCTP Considerations ............................................31
6. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 34 6. The ASAP Interfaces ............................................31
6.1. Registration.Request Primitive . . . . . . . . . . . . . . 34 6.1. Registration.Request Primitive ............................32
6.2. Deregistration.Request Primitive . . . . . . . . . . . . . 34 6.2. Deregistration.Request Primitive ..........................32
6.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 35 6.3. CachePopulateRequest Primitive ............................33
6.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 35 6.4. CachePurgeRequest Primitive ...............................33
6.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 35 6.5. DataSendRequest Primitive .................................33
6.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 36 6.5.1. Sending to a Pool Handle ...........................34
6.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 37 6.5.2. Pool Element Selection .............................35
6.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 38 6.5.2.1. Round-Robin Policy ........................35
6.5.4. Send by Transport Address . . . . . . . . . . . . . . 39 6.5.3. Sending to a Pool Element Handle ...................35
6.5.5. Message Delivery Options . . . . . . . . . . . . . . . 39 6.5.4. Send by Transport Address ..........................37
6.6. Data.Received Notification . . . . . . . . . . . . . . . . 40 6.5.5. Message Delivery Options ...........................37
6.7. Error.Report Notification . . . . . . . . . . . . . . . . 41 6.6. Data.Received Notification ................................38
6.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.7. Error.Report Notification .................................39
6.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 41 6.8. Examples ..................................................39
6.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 43 6.8.1. Send to a New Pool .................................39
6.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 43 6.8.2. Send to a Cached Pool Handle .......................40
6.9.1. Translation.Request Primitive . . . . . . . . . . . . 43 6.9. PE Send Failure ...........................................41
6.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 44 6.9.1. Translation.Request Primitive ......................41
7. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 45 6.9.2. Transport.Failure Primitive ........................42
7.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7. Timers, Variables, and Thresholds ..............................42
7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45 7.1. Timers ....................................................42
7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Variables .................................................42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 7.3. Thresholds ................................................43
8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47 8. IANA Considerations ............................................43
8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. A New Table for ASAP Message Types ........................43
8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48 8.2. Port Numbers ..............................................44
8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48 8.3. SCTP Payload Protocol Identifier ..........................44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 8.4. Multicast Addresses .......................................44
9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49 9. Security Considerations ........................................44
9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50 9.1. Summary of RSerPool Security Threats ......................45
9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 53 9.2. Implementing Security Mechanisms ..........................46
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 9.3. Chain of Trust ............................................49
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 10. Acknowledgments ...............................................50
11.1. Normative References . . . . . . . . . . . . . . . . . . . 56 11. References ....................................................50
11.2. Informative References . . . . . . . . . . . . . . . . . . 57 11.1. Normative References .....................................50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 11.2. Informative References ...................................51
Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
The Aggregate Server Access Protocol (ASAP) when used in conjunction The Aggregate Server Access Protocol (ASAP), when used in conjunction
with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp] with Endpoint Name Resolution Protocol [RFC5353], provides a high-
provides a high availability data transfer mechanism over IP availability data-transfer mechanism over IP networks. ASAP uses a
networks. ASAP uses a handle-based addressing model which isolates a handle-based addressing model that isolates a logical communication
logical communication endpoint from its IP address(es), thus endpoint from its IP address(es), thus effectively eliminating the
effectively eliminating the binding between the communication binding between the communication endpoint and its physical IP
endpoint and its physical IP address(es) which normally constitutes a address(es), which normally constitutes a single point of failure.
single point of failure.
When multiple receiver instances exist under the same handle (a.k.a, When multiple receiver instances exist under the same handle (aka a
a server pool),an ASAP endpoint will select one Pool Element (PE), server pool), an ASAP Endpoint will select one Pool Element (PE),
based on the current load sharing policy indicated by the server based on the current load sharing policy indicated by the server
pool, and deliver its message to the selected PE. pool, and deliver its message to the selected PE.
While delivering the message, ASAP can be used to monitor the While delivering the message, ASAP can be used to monitor the
reachability of the selected PE. If it is found unreachable, before reachability of the selected PE. If it is found unreachable, before
notifying the message sender (an ASAP user) of the failure, ASAP can notifying the message sender (an ASAP User) of the failure, ASAP can
automatically select another PE (if one exists) under that pool and automatically select another PE (if one exists) under that pool and
attempt to deliver the message to that PE. In other words, ASAP is attempt to deliver the message to that PE. In other words, ASAP is
capable of transparent fail-over amongst PE instances within a server capable of transparent failover amongst PE instances within a server
pool. pool.
ASAP depends on ENRP which provides a high availability pool handle ASAP depends on ENRP, which provides a high-availability Pool
space. ASAP is responsible for the abstraction of the underlying Handlespace. ASAP is responsible for the abstraction of the
transport technologies, load distribution management, fault underlying transport technologies, load distribution management,
management, as well as presentation to the upper layer (aka an ASAP fault management, as well as presentation to the upper layer (aka an
user) via a unified primitive interface. ASAP User) via a unified primitive interface.
When SCTP [RFC4960] is used as the transport layer protocol, ASAP can When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
seamlessly incorporate the link-layer redundancy provided by SCTP. seamlessly incorporate the link-layer redundancy provided by SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high-availability
server pool. server pool.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
ASAP user: Either a PE or PU that uses ASAP. 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 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 the sender belongs to and provides a list of alternate PEs in case
of fail-overs. of failovers.
Operational scope: The part of the network visible to pool users by Operational Scope: The part of the network visible to pool users by
a specific instance of the reliable server pooling protocols. a specific instance of the reliable server pooling protocols.
Pool (or server pool): A collection of servers providing the same Pool (or Server Pool): A collection of servers providing the same
application functionality. application functionality.
Pool handle: A logical pointer to a pool. Each server pool will be Pool Handle: A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a unique identifiable in the operational scope of the system by a unique
pool handle. Pool Handle.
Pool element: A server entity having registered to a pool. Pool Element: A server entity having registered to a pool.
Pool user: A server pool user. Pool User: A server pool user.
Pool element handle (or endpoint handle): A logical pointer to a Pool Element Handle (or Endpoint Handle): A logical pointer to a
particular pool element in a pool, consisting of the pool handle particular Pool Element in a pool, consisting of the Pool Handle
and a destination transport address of the pool element. and a destination transport address of the Pool Element.
Handle space: A cohesive structure of pool handles and relations Handlespace: A cohesive structure of Pool Handles and relations that
that may be queried by an internal or external agent. may be queried by an internal or external agent.
Home ENRP server: The ENRP server to which a PE or PU currently Home ENRP Server: The ENRP server to which a PE or PU currently
sends all namespace service requests. A PE must only have one 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 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 ENRP server MUST know and keep track of this relationship. A PU
should select one of the available ENRP servers as its Home ENRP should select one of the available ENRP servers as its Home ENRP
server but the collective ENRP servers may change this by the server, but the collective ENRP servers may change this by the
sending or a ASAP_ENDPOINT_KEEP_ALIVE message. sending of an ASAP_ENDPOINT_KEEP_ALIVE message.
ENRP client channel: The communication channel through which an ASAP ENRP Client Channel: The communication channel through which an ASAP
User sends all namespace service requests. The client channel is User sends all namespace service requests. The client channel is
usually defined by the transport address of the Home ENRP server usually defined by the transport address of the Home ENRP server
and a well known port number. The channel MAY make use of and a well-known port number. The channel MAY make use of
multicast or a named list of ENRP servers. multicast or a named list of ENRP servers.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, aka Big Endian.
Transport address: A Transport Address is traditionally defined by Transport Address: A transport address is traditionally defined by
Network Layer address, Transport Layer protocol and Transport Network Layer address, Transport Layer protocol and Transport
Layer port number. In the case of SCTP running over IP, a Layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the Transport protocol). and an SCTP port number (where SCTP is the Transport protocol).
1.2. Organization of this document 1.2. Conventions
Section 2 details the ASAP message formats. In Section 3 we provide 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 detailed ASAP procedures for the ASAP implementer. Section 4
summarizes which messages needs to be supported by which nodes and summarizes which messages need to be supported by which nodes, and
Section 5 describes the usage of SCTP. In Section 6 details of the Section 5 describes the usage of SCTP. In Section 6, details of the
ASAP interface are given, focusing on the communication primitives ASAP interface are given, focusing on the communication primitives
between ASAP the applications above ASAP and ASAP itself, and the between ASAP, the applications above ASAP, and ASAP itself, and the
communications primitives between ASAP and SCTP (or other transport communications primitives between ASAP and SCTP (or other transport
layers). Also included in this discussion are relevant timers and layers). Also included in this discussion are relevant timers and
configurable parameters as appropriate. Section 7 provides threshold configurable parameters, as appropriate. Section 7 provides
and protocol variables. threshold and protocol variables.
It should be noted that variables, timers and constants are used in It should be noted that variables, timers, and constants are used in
the text when necessary. The complete list can be found in the text when necessary. The complete list can be found in
Section 7. Section 7.
1.3. Scope of ASAP 1.4. Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during the transaction failover. If a host or application fails during the
processing of a transaction, this transaction may be lost. Some processing of a transaction, this transaction may be lost. Some
services MAY provide a way to handle the failure, but this is not services MAY provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself does NOT share building a mechanism to share state but ASAP in itself does NOT share
any state. any state.
1.3.1. Extent of the Handlespace 1.4.1. Extent of the Handlespace
The scope of ASAP/ENRP is NOT Internet wide. The handlespace is The scope of ASAP/ENRP is NOT Internet-wide. The handlespace is
neither hierarchical nor arbitrarily large like DNS. A flat peer-to- neither hierarchical nor arbitrarily large like DNS. A flat peer-to-
peer model is detailed. Pools of servers will exist in different peer model is detailed. Pools of servers will exist in different
administrative domains. For example, suppose the use of ASAP and administrative domains. For example, suppose the use of ASAP and
ENRP is wanted. First, the PU may use DNS to contact an ENRP server. 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 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 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 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 channel in Japan. From there, the PU would query the Home ENRP
it established and then directly contact the PE(s) of interest. server it established and then directly contact the PE(s) of
interest.
1.4. 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].
2. Message Definitions 2. Message Definitions
All messages as well as their fields described below shall be in All messages, as well as their fields described below, shall be in
Network Byte Order during transmission. For fields with a length network byte order during transmission. For fields with a length
bigger than 4 bytes, a number in a pair of parentheses may follow the 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. field name to indicate the length of the field in number of bytes.
2.1. ASAP Parameter Formats 2.1. ASAP Parameter Formats
The basic message format and all parameter formats can be found in The basic message format and all parameter formats can be found in
[I-D.ietf-rserpool-common-param]. Note also that ALL ASAP messages [RFC5354]. Note also that *all* ASAP messages exchanged between an
exchanged between an ENRP server and a PE MUST use SCTP as transport, ENRP server and a PE MUST use SCTP as transport, while ASAP messages
while ASAP messages exchanged between an ENRP server and a PU MUST exchanged between an ENRP server and a PU MUST use either SCTP or TCP
use either SCTP or TCP as transport. PE to PU data traffic MAY use as transport. PE to PU data traffic MAY use any transport protocol
any transport protocol specified by the PE during registration. specified by the PE during registration.
2.2. ASAP Messages 2.2. ASAP Messages
This section details the individual messages used by ASAP. These This section details the individual messages used by ASAP. These
messages are composed of a standard message format found in Section 4 messages are composed of a standard message format found in Section 4
of [I-D.ietf-rserpool-common-param]. The parameter descriptions can of [RFC5354]. The parameter descriptions can be found in [RFC5354].
be found in [I-D.ietf-rserpool-common-param].
The following ASAP message types are defined in this section: The following ASAP message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (Reserved by IETF)
0x01 - ASAP_REGISTRATION 0x01 - ASAP_REGISTRATION
0x02 - ASAP_DEREGISTRATION 0x02 - ASAP_DEREGISTRATION
0x03 - ASAP_REGISTRATION_RESPONSE 0x03 - ASAP_REGISTRATION_RESPONSE
0x04 - ASAP_DEREGISTRATION_RESPONSE 0x04 - ASAP_DEREGISTRATION_RESPONSE
0x05 - ASAP_HANDLE_RESOLUTION 0x05 - ASAP_HANDLE_RESOLUTION
0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE
0x07 - ASAP_ENDPOINT_KEEP_ALIVE 0x07 - ASAP_ENDPOINT_KEEP_ALIVE
0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK
0x09 - ASAP_ENDPOINT_UNREACHABLE 0x09 - ASAP_ENDPOINT_UNREACHABLE
0x0a - ASAP_SERVER_ANNOUNCE 0x0a - ASAP_SERVER_ANNOUNCE
0x0b - ASAP_COOKIE 0x0b - ASAP_COOKIE
0x0c - ASAP_COOKIE_ECHO 0x0c - ASAP_COOKIE_ECHO
0x0d - ASAP_BUSINESS_CARD 0x0d - ASAP_BUSINESS_CARD
0x0e - ASAP_ERROR 0x0e - ASAP_ERROR
others - (Reserved by IETF)
Figure 1 Figure 1
2.2.1. ASAP_REGISTRATION message 2.2.1. ASAP_REGISTRATION Message
The REGISTRATION message is sent by a PE to its Home ENRP Server to The ASAP_REGISTRATION message is sent by a PE to its Home ENRP server
either create a new pool or to add itself to an existing pool. The to either create a new pool or to add itself to an existing pool.
PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle The PE sending the ASAP_REGISTRATION message MUST fill in the Pool
parameter and the Pool Element parameter. The Pool Handle parameter Handle parameter and the Pool Element parameter. The Pool Handle
specifies the name to be registered. The Pool Element parameter MUST parameter specifies the name to be registered. The Pool Element
be filled in by the registrant as outlined in Section 3.1. Note that parameter MUST be filled in by the registrant, as outlined in
the PE sending the registration message MUST send the message using Section 3.1. Note that the PE sending the registration message MUST
an SCTP association. Furthermore the IP address(es) of the PE that send the message using an SCTP association. Furthermore, the IP
is registered within the Pool Element parameter MUST be a subset of address(es) of the PE that is registered within the Pool Element
the IP address(es) used in the SCTP association regardless of the parameter MUST be a subset of the IP address(es) used in the SCTP
registered transport protocol association, regardless of the registered transport protocol.
0 1 2 3 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 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 | | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
Pool Element Parameter: Pool Element Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
2.2.2. ASAP_DEREGISTRATION message 2.2.2. ASAP_DEREGISTRATION Message
The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP
Server to remove itself from a pool to which it registered. server to remove itself from a pool to which it registered.
0 1 2 3 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 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 | | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
Pool Handle Parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
PE Identifier Parameter: PE Identifier Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle 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 and the PE identifier parameter in order to allow the ENRP server to
verify the identity of the endpoint. Note that deregistration is NOT verify the identity of the endpoint. Note that de-registration is
allowed by proxy, in other words a PE may only deregister itself. NOT allowed by proxy; in other words, a PE may only de-register
itself.
2.2.3. ASAP_REGISTRATION_RESPONSE message 2.2.3. ASAP_REGISTRATION_RESPONSE Message
The ASAP_REGISTRATION_RESPONSE message is sent in response by the The ASAP_REGISTRATION_RESPONSE message is sent in response by the
Home ENRP Server to the PE that sent a ASAP_REGISTRATION message. Home ENRP server to the PE that sent an ASAP_REGISTRATION message.
0 1 2 3 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 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 | | Type = 0x03 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) Flag: R (Reject) Flag:
When set to '1', this flag indicates that the ENRP server sending When set to '1', this flag indicates that the ENRP server sending
this message has rejected the registration. Otherwise when this flag this message has rejected the registration. Otherwise, when this
is set to '0', this indicates the registration has been granted. flag is set to '0', this indicates the registration has been granted.
Pool Handle Parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
PE Identifier Parameter: PE Identifier Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
Operational Error Parameter (optional): Operational Error Parameter (optional):
See [I-D.ietf-rserpool-common-param] See [RFC5354].
This parameter is included if an error or some atypical events This parameter is included if an error or some atypical events
occurred during the registration process. When the R flag is set to occurred during the registration process. When the R flag is set to
'1', this parameter, if present, indicates the cause of the '1', this parameter, if present, indicates the cause of the
rejection. When the R flag is set to '0', this parameter, if rejection. When the R flag is set to '0', this parameter, if
present, serves as a warning to the registering PE, informing it that present, serves as a warning to the registering PE, informing it that
some of its registration values may have been modified by the ENRP some of its registration values may have been modified by the ENRP
server. If the registration was successful and there is no warning, server. If the registration was successful and there is no warning,
this parameter is not included. this parameter is not included.
2.2.4. ASAP_DEREGISTRATION_RESPONSE message 2.2.4. ASAP_DEREGISTRATION_RESPONSE Message
The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP
Server to a PE in response to a ASAP_DEREGISTRATION message or due to server to a PE in response to an ASAP_DEREGISTRATION message or due
the expiration of the registration life of the PE in the pool to the expiration of the registration life of the PE in the pool.
0 1 2 3 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 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 | | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
PE Identifier Parameter: PE Identifier Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
Operational Error: Operational Error:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
This parameter is included if an error or some atypical events This parameter is included if an error or some atypical events
occurred during the deregistration process. If the deregistration occurred during the de-registration process. If the de-registration
was successful this parameter is not included. was successful this parameter is not included.
2.2.5. ASAP_HANDLE_RESOLUTION message 2.2.5. ASAP_HANDLE_RESOLUTION Message
The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to 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 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. Elements that are members of the pool indicated by the Pool Handle.
0 1 2 3 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 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 | | Type = 0x05 |0|0|0|0|0|0|0|S| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'S' bit: The 'S' bit:
The 'S' bit, if set to '1', requests the Home ENRP server to send 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 updates to this Pool dynamically when the Pool changes for the
lifetime of the SCTP association. Dynamic updates to the pool will lifetime of the SCTP association. Dynamic updates to the pool will
consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages, consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages,
without the user needing to send in a ASAP_HANDLE_RESOLUTION. without the user needing to send in an ASAP_HANDLE_RESOLUTION.
If the 'S' bit is set to '0' no dynamic updates are requested. 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 Note that if a new Home ENRP server is adopted, any 'dynamic update
request' will need to be resent to the new Home ENPR server if the 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, 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 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 requesting automatic update of state. Thus, upon change of Home ENRP
Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message 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 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 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 response is returned, no further updates to the Pool (when it is
created) will occur. created) will occur.
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message
The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by
the Home ENRP server of the PU or PE that sent a the Home ENRP server of the PU or PE that sent an
ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if ASAP_HANDLE_RESOLUTION message or is sent periodically upon Pool
the PU as requested Dynamic updates. changes if the PU has requested Dynamic updates.
0 1 2 3 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 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 | | Type = 0x06 |0|0|0|0|0|0|0|A| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) : : Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 (optional) : : Pool Element Parameter 1 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N (optional) : : Pool Element Parameter N (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A bit: 'A' bit:
This bit is set to '1' if the ENRP server accepts the request to send 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 automatic updates (i.e., the 'S' bit was set on the request). If
bit is set to '0' either the ENRP server does NOT support automatic this bit is set to '0', either the ENRP server does NOT support
update, it has resource issues and cannot supply this feature or the automatic updates, it has resource issues and cannot supply this
user did not request it. feature, or the user did not request it.
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] See [RFC5354].
Overall PE Selection Policy (optional): Overall PE Selection Policy (optional):
See [I-D.ietf-rserpool-common-param] See [RFC5354].
This parameter can be present when the response is positive. If This parameter can be present when the response is positive. If
present, it indicates the overall pool member selection policy of the present, it indicates the overall pool member selection policy of the
pool. If not present, a round robin overall pool member selection pool. If not present, a Round-Robin overall pool member selection
policy is assumed. This parameter is not present when the response policy is assumed. This parameter is not present when the response
is negative. is negative.
Note, any load policy parameter within a Pool Element Parameter (if Note, any load policy parameter within a Pool Element parameter (if
present) MUST be ignored, and MUST NOT be used to determine the present) MUST be ignored, and MUST NOT be used to determine the
overall pool member selection policy. overall pool member selection policy.
Pool Element Parameters (optional): Pool Element Parameters (optional):
See [I-D.ietf-rserpool-common-param] See [RFC5354].
When the response is positive, an array of PE parameters are When the response is positive, an array of PE parameters are
included, indicating the current information about the PEs in the included, indicating the current information about the PEs in the
named pool. At least one PE parameter MUST be present. When the named pool. At least one PE parameter MUST be present. When the
response is negative, no PE parameters are included. response is negative, no PE parameters are included.
Operational Error (optional): Operational Error (optional):
See [I-D.ietf-rserpool-common-param] See [RFC5354].
The presence of this parameter indicates that the response is The presence of this parameter indicates that the response is
negative (the handle resolution request was rejected by the ENRP negative (the handle resolution request was rejected by the ENRP
server). The cause code in this parameter (if present) will indicate server). The cause code in this parameter (if present) will indicate
the reason the handle resolution request was rejected (e.g., the the reason the handle resolution request was rejected (e.g., the
requested pool handle was not found). The absence of this parmaeter requested Pool Handle was not found). The absence of this parameter
indicates that the response is positive. indicates that the response is positive.
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message
The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP Server to a 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. 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 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 its new Home ENRP server if the 'H' bit is set to '1'. Regardless of
setting of the H bit, an ASAP endpoint MUST respond with an 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 ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages
that arrive. that arrive.
0 1 2 3 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 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 | | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier | | Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H (Home ENRP server) flag H (Home ENRP server) Flag:
When set to '1', indicate that the ENRP server that sends this When set to '1', indicates that the ENRP server that sends this
message want to be the home ENRP server of the receiver of this message wants to be the Home ENRP server of the receiver of this
message. message.
Server Identifier: 32 bit (unsigned integer) Server Identifier: 32 bits (unsigned integer)
This is the ID of the ENRP server, as discussed in This is the ID of the ENRP server, as discussed in [RFC5353].
[I-D.ietf-rserpool-enrp].
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param] . See [RFC5354].
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message
The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response 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. to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP server.
0 1 2 3 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 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 | | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
PE Identifier parameter: PE Identifier Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
2.2.9. ASAP_ENDPOINT_UNREACHABLE message 2.2.9. ASAP_ENDPOINT_UNREACHABLE Message
The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to
its Home ENRP Server to report an unreachable PE. its Home ENRP server to report an unreachable PE.
0 1 2 3 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 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 | | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
PE Identifier parameter: PE Identifier Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
2.2.10. ASAP_SERVER_ANNOUNCE message 2.2.10. ASAP_SERVER_ANNOUNCE Message
The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that The ASAP_SERVER_ANNOUNCE message is sent by an ENRP server such that
PUs and PEs know the transport information necessary to connect to PUs and PEs know the transport information necessary to connect to
the ENRP server. the ENRP server.
0 1 2 3 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 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 | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier | | Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #1 : : Transport Param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #2 : : Transport Param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ..... : : ..... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n : : Transport Param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Identifier: 32 bit (unsigned integer) Server Identifier: 32 bits (unsigned integer)
This is the ID of the ENRP server, as discussed in This is the ID of the ENRP server, as discussed in [RFC5353].
[I-D.ietf-rserpool-enrp].
Transport parameters (optional): Transport Parameters (optional):
See [I-D.ietf-rserpool-common-param] for the SCTP and TCP Transport See [RFC5354] for the SCTP and TCP Transport parameters.
parameters.
Only SCTP and TCP Transport parameters are allowed for use within the Only SCTP and TCP Transport parameters are allowed for use within the
SERVER_ANNOUNCE message. SERVER_ANNOUNCE message.
2.2.11. ASAP_COOKIE message 2.2.11. ASAP_COOKIE Message
The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to 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. convey information it wishes to share using a control channel.
0 1 2 3 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 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 | | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter : Cookie Parameter :
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
2.2.12. ASAP_COOKIE_ECHO message 2.2.12. ASAP_COOKIE_ECHO Message
The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it 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 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 Parameter sent by the PE is the latest one received from the failed
PE. PE.
0 1 2 3 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 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 | | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter: Cookie Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
2.2.13. ASAP_BUSINESS_CARD message 2.2.13. ASAP_BUSINESS_CARD Message
The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE 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 to a PU using a control channel to convey the pool handle and a
preferred failover ordering. preferred failover ordering.
0 1 2 3 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 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 | | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 : : Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. : : .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N : : Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
Pool Element parameters: Pool Element Parameters:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
2.2.14. ASAP_ERROR message 2.2.14. ASAP_ERROR Message
The ASAP_ERROR message is sent in response by an ASAP endpoint The ASAP_ERROR message is sent in response by an ASAP Endpoint
receiving an unknown message or an unknown parameter to the sending receiving an unknown message or an unknown parameter to the sending
ASAP endpoint to report the problem or issue. ASAP Endpoint to report the problem or issue.
0 1 2 3 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 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 | | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter : : Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operation Error parameter: Operational Error Parameter:
See [I-D.ietf-rserpool-common-param]. See [RFC5354].
When an ASAP endpoint receives an ASAP message with an unknown When an ASAP Endpoint receives an ASAP message with an unknown
message type or a message of known type that contains 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, it SHOULD handle the unknown message or the unknown
parameter according to the unrecognized message and parameter parameter according to the unrecognized message and parameter
handling rules defined in Section 3. handling rules, defined in Section 3.
According to the rules, if an error report to the message sender is According to the rules, if an error report to the message sender is
needed, the ASAP endpoint that discovered the error SHOULD send back needed, the ASAP endpoint that discovered the error SHOULD send back
an ASAP_ERROR message which includes an Operation Error parameter an ASAP_ERROR message that includes an Operational Error parameter
with the proper cause code, cause length, and case specific with the proper cause code, cause length, and case-specific
information. information.
3. Procedures 3. Procedures
This section will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP Endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. Also please failure detection and management are also discussed. Also, please
note that ASAP messages, sent between a PE and PU are identified by note that ASAP messages sent between a PE and PU are identified by an
an SCTP Payload Protocol Identifier (PPID). SCTP Payload Protocol Identifier (PPID).
3.1. Registration 3.1. Registration
When a PE wishes to initiate or join a server pool it MUST use the When a PE wishes to initiate or join a server pool, it MUST use the
procedures outlined in this section for registration. Often, the procedures outlined in this section for registration. Often, the
registration will be triggered by a user request primitive (discussed registration will be triggered by a user request primitive (discussed
in Section 6.1). The PE MUST register using an SCTP association in Section 6.1). The PE MUST register using an SCTP association
established between itself and the Home ENRP server. If the PE has established between itself and the Home ENRP server. If the PE has
not established its Home ENRP server, it MUST follow the procedures not established its Home ENRP server, it MUST follow the procedures
specified in Section 3.6. specified in Section 3.6.
Once the PE's ASAP endpoint has established its Home ENRP server the Once the PE's ASAP Endpoint has established its Home ENRP server, the
following procedures MUST be followed to register: following procedures MUST be followed to register:
R1) The PE's SCTP endpoint used to communicate with the Home ENRP R1) The PE's SCTP endpoint used to communicate with the Home ENRP
server MUST be bound to all IP addresses that will be used by the server MUST be bound to all IP addresses that will be used by the
PE (irregardless of what transport protocol will be used to PE (regardless of which transport protocol will be used to service
service user requests to the PE). user requests to the PE).
R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION R2) The PE's ASAP Endpoint MUST formulate an ASAP_REGISTRATION
message as defined in Section 2.2.1. In formulating the message, message, as defined in Section 2.2.1. In formulating the message,
the PE MUST: the PE MUST:
R2.1) Fill in the Pool Handle Parameter to specify which server R2.1) Fill in the Pool Handle parameter to specify which server
pool the ASAP endpoint wishes to join. pool the ASAP Endpoint wishes to join.
R2.2) Fill in the PE identifier using a good quality randomly R2.2) Fill in the PE identifier using a good-quality randomly
generated number ([RFC4086] provides some information on generated number ([RFC4086] provides some information on
randomness guidelines). randomness guidelines).
R2.3) Fill in the Registration Life time parameter with the R2.3) Fill in the Registration Lifetime parameter with the number
number of seconds that this registration is valid for. Note a of seconds that this registration is valid for. Note that a PE
PE that wishes to continue service MUST re-register before the that wishes to continue service MUST re-register before the
registration expires. registration expires.
R2.4) Fill in a User Transport Parameter to specify the type of R2.4) Fill in a User Transport parameter to specify the type of
transport and the data/control channel usage the PE is willing transport and the data/control channel usage the PE is willing
to support. Note, in joining an existing server pool, the PE to support. Note, in joining an existing server pool, the PE
MUST follow the overall transport type and overall data/control MUST follow the overall transport type and overall data/control
channel usage of the pool. Otherwise, the registration may be channel usage of the pool. Otherwise, the registration may be
rejected by the ENRP server. rejected by the ENRP server.
R2.5) Fill in the preferred Pool Member Selection Policy R2.5) Fill in the preferred Pool Member Selection Policy
parameter. parameter.
R3) Send the Registration message to the Home ENRP server using R3) Send the ASAP_REGISTRATION message to the Home ENRP server using
SCTP. SCTP.
R4) Start a T2-registration timer. R4) Start a T2-registration timer.
Note: the PE does not need to fill in the optional ASAP transport Note: the PE does not need to fill in the optional ASAP transport
parameter. The ASAP transport parameter will be filled in and used parameter. The ASAP transport parameter will be filled in and used
by the home ENRP server. by the Home ENRP server.
If the T2-registration timer expires before receiving an If the T2-registration timer expires before receiving an
ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the PE shall start the Server Hunt received from the SCTP layer, the PE shall start the Server Hunt
procedure (see Section 3.6) in an attempt to get service from a procedure (see Section 3.6) in an attempt to get service from a
different ENRP server. After establishing a new Home ENRP server the different ENRP server. After establishing a new Home ENRP server,
PE SHOULD restart the registration procedure. the PE SHOULD restart the registration procedure.
At the reception of the registration response, the PE MUST stop the At the reception of the registration response, the PE MUST stop the
T2-Registration timer. If the response indicates success, the PE is T2-registration timer. If the response indicates success, the PE is
registered and will be considered an available member of the server registered and will be considered an available member of the server
pool. If the registration response indicates a failure, the PE must pool. If the registration response indicates a failure, the PE must
either re-attempt registration after correcting the error or return a either re-attempt registration after correcting the error or return a
failure indication to the PE's upper layer. The PE MUST NOT re- failure indication to the PE's upper layer. The PE MUST NOT re-
attempt registration without correcting the error condition. attempt registration without correcting the error condition.
At any time a registered PE MAY wish to re-register to either update At any time, a registered PE MAY wish to re-register to either update
its member selection policy value or registration expiration time. its member selection Policy Value or registration expiration time.
When re-registering the PE MUST use the same PE identifier. When re-registering, the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration After successful registration, the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting timer. At its expiration, a re-registration SHOULD be made starting
at step R1 including (at completion) restarting the T4-reregistration at step R1, including (at completion) restarting the T4-
timer. reregistration timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
registration (and reregistration) attempts it makes in a local registration (and re-registration) attempts it makes in a local
variable that gets set to zero before the initial registration variable that gets set to zero before the initial registration
attempt to the Home ENRP server or after a successful re- attempt to the Home ENRP server or after a successful re-
registration.If repeated registration time-outs or failures occurs registration. If repeated registration timeouts or failures occurs
and the local count exceeds the Threshold 'MAX-REG-ATTEMPT' the and the local count exceeds the Threshold 'MAX-REG-ATTEMPT', the
implementation SHOULD report the error to its upper layer and stop implementation SHOULD report the error to its upper layer and stop
attempting registration. attempting registration.
The ENRP server handles the ASAP_REGISTRATION message according to The ENRP server handles the ASAP_REGISTRATION message according to
the following rules: the following rules:
1. If the named pool does not exist in the handlespace, the ENRP 1. If the named pool does not exist in the handlespace, the ENRP
server MUST creates a new pool with that handle in the server MUST create a new pool with that handle in the handlespace
handlespace and add the PE to the pool as its first PE; and add the PE to the pool as its first PE.
When a new pool is created, the overall member selection policy When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first of the pool MUST be set to the policy type indicated by the first
PE, the overall pool transport type MUST be set to the transport PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the Transport Use field of the User Transport parameter by the
registering PE. registering PE.
2. If the named pool already exists in the handlespace, but the 2. If the named pool already exists in the handlespace, but the
requesting PE is not currently a member of the pool, the ENRP requesting PE is not currently a member of the pool, the ENRP
server will add the PE as a new member to the pool; server will add the PE as a new member to the pool.
However, before adding the PE to the pool, the server MUST check However, before adding the PE to the pool, the server MUST check
if the policy type, transport type, and transport usage indicated if the policy type, transport type, and transport usage indicated
by the registering PE is consistent with those of the pool. If by the registering PE is consistent with those of the pool. If
different, the ENRP server MUST reject the registration. different, the ENRP server MUST reject the registration.
3. If the named pool already exists in the handlespace AND the 3. If the named pool already exists in the handlespace *and* the
requesting PE is already a member of the pool, the ENRP server requesting PE is already a member of the pool, the ENRP server
SHOULD consider this as a re-registration case. The ENRP server SHOULD consider this as a re-registration case. The ENRP server
MUST perform the same tests on policy, transport type, transport MUST perform the same tests on policy, transport type, and
use, as described above. If the re-registration is accepted transport use, as described above. If the re-registration is
after the test, the ENRP Server SHOULD replace the attributes of accepted after the test, the ENRP server SHOULD replace the
the existing PE with the information carried in the received attributes of the existing PE with the information carried in the
ASAP_REGISTRATION message. received ASAP_REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assign 4. After accepting the registration, the ENRP server MUST assign
itself the owner of this PE. If this is a re-registration, the itself the owner of this PE. If this is a re-registration, the
ENRP server MUST take over ownership of this PE regardless of ENRP server MUST take over ownership of this PE, regardless of
whether the PE was previously owned by this server or by another whether the PE was previously owned by this server or by another
server. The ENRP server MUST also record the SCTP transport server. The ENRP server MUST also record the SCTP transport
address from which it received the ASAP_REGISTRATION in the ASAP address from which it received the ASAP_REGISTRATION in the ASAP
Transport parameter TLV inside the PE parameter of this PE. Transport parameter TLV inside the PE parameter of this PE.
5. The ENRP server may reject the registration due to other reasons 5. The ENRP server may reject the registration due to other reasons
such as invalid values, lack of resource, authentication failure, such as invalid values, lack of resource, authentication failure,
etc. etc.
In all above cases, the ENRP server MUST reply to the requesting PE In all above cases, the ENRP server MUST reply to the requesting PE
with an ASAP_REGISTRATION_RESPONSE message. If the registration is with an ASAP_REGISTRATION_RESPONSE message. If the registration is
accepted, the ENRP server MUST set the 'R' flag in the accepted, the ENRP server MUST set the R flag in the
ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected,
the ENRP server MUST indicate the rejection by setting the 'R' flag the ENRP server MUST indicate the rejection by setting the R flag in
in the ASAP_REGISTRATION_RESPONSE to '1'. the ASAP_REGISTRATION_RESPONSE to '1'.
If the registration is rejected, the ENRP server SHOULD include the If the registration is rejected, the ENRP server SHOULD include the
proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message.
If the registration is granted (either a new registration or a re- If the registration is granted (either a new registration or a re-
registration case), the ENRP server MUST assign itself to be the home registration case), the ENRP server MUST assign itself to be the Home
ENRP server of the PE, i.e., to "own" the PE. ENRP server of the PE, i.e., to "own" the PE.
Implementation note: for better performance, the ENRP server may Implementation note: For better performance, the ENRP server may
find it both efficient and convenient to internally maintain two find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned" separate PE lists or tables -- one is for the PEs that are owned
by the ENRP server and the other for all the PEs owned by its by the ENRP server and the other is for all the PEs owned by their
peer(s). peer(s).
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the handlespace update action to inform its peers about the change the handlespace update action to inform its peers about the change
just made. If the registration is denied, no message will be sent to just made. If the registration is denied, no message will be sent to
its peers. its peers.
3.2. Deregistration 3.2. De-Registration
In the event a PE wishes to deregister from its server pool (normally In the event a PE wishes to de-register from its server pool
via an upper layer requests see Section 6.2), it SHOULD use the (normally, via an upper-layer request, see Section 6.2), it SHOULD
following procedure. It should be noted that an alternate method of use the following procedure. It should be noted that an alternate
deregistration is to NOT re-register and to allow the registration method of de-registration is to NOT re-register and to allow the
life of the PE to expire. In this case a registration life of the PE to expire. In this case, an
ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP
endpoint to indicate the removal of the PE from the pool it Endpoint to indicate the removal of the PE from the pool it
registered. registered.
When deregistering the PE SHOULD use the SCTP association that was When de-registering, the PE SHOULD use the SCTP association that was
used for registration with its Home ENRP server. To deregister, the used for registration with its Home ENRP server. To de-register, the
PE's ASAP endpoint MUST take the following actions: PE's ASAP Endpoint MUST take the following actions:
D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION
message ( Section 2.2.2) using the same Pool Handle parameter sent message (Section 2.2.2) using the same Pool Handle parameter sent
during registration. during registration.
D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION
message. The identifier MUST be the same as used during message. The identifier MUST be the same as used during
registration. The use of the same Pool Handle and Pool Identifier registration. The use of the same Pool Handle and Pool Identifier
parameters used in registration allows the identity of the PE ASAP parameters used in registration allows the identity of the PE ASAP
endpoint be verified before deregistration can occur. Endpoint to be verified before de-registration can occur.
D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server
using the PE's SCTP association. using the PE's SCTP association.
D4) Start a T3-Deregistration timer. D4) Start a T3-Deregistration timer.
If the T3-Deregistration timer expires before receiving either a If the T3-Deregistration timer expires before receiving either an
ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification
from the PE's SCTP endpint, the PE's ASAP endpoint shall start the from the PE's SCTP endpoint, the PE's ASAP Endpoint shall start the
ENRP Server Hunt procedure (see Section 3.6) in an attempt to get ENRP Server Hunt procedure (see Section 3.6) in an attempt to get
service from another ENRP server. After establishing a new Home ENRP service from another ENRP server. After establishing a new Home ENRP
server, the ASAP endpoint SHOULD restart the deregistration server, the ASAP Endpoint SHOULD restart the de-registration
procedure. procedure.
At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP
endpoint MUST stop the T3-deregistration timer. endpoint MUST stop the T3-Deregistration timer.
It should be noted that after a successful deregistration the PE MAY It should be noted that after a successful de-registration, the PE
still receive requests for some period of time. The PE MAY wish to MAY still receive requests for some period of time. The PE MAY wish
remain active and service these requests or to exit and ignore these to remain active and service these requests or to exit and ignore
requests. these requests.
Upon receiving the message, the ENRP server SHALL remove the PE from Upon receiving the message, the ENRP server SHALL remove the PE from
its handlespace. Moreover, if the PE is the last one of the named its handlespace. Moreover, if the PE is the last one of the named
pool, the ENRP server will remove the pool from the handlespace as pool, the ENRP server will remove the pool from the handlespace as
well. well.
If the ENRP server fails to find any record of the PE in its If the ENRP server fails to find any record of the PE in its
handlespace, it SHOULD consider the de-registration granted and handlespace, it SHOULD consider the de-registration granted and
completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the
PE. PE.
skipping to change at page 23, line 44 skipping to change at page 23, line 8
reasons, such as invalid parameters, authentication failure, etc. reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send an In response, the ENRP server MUST send an
ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-
registration is rejected, the ENRP server MUST indicate the rejection registration is rejected, the ENRP server MUST indicate the rejection
by including the proper Operational Error parameter. by including the proper Operational Error parameter.
It should be noted that de-registration does not stop the PE from It should be noted that de-registration does not stop the PE from
sending or receiving application messages. sending or receiving application messages.
Once the de-registration request is granted AND the PE removed from Once the de-registration request is granted *and* the PE removed from
its local copy of the handlespace, the ENRP server MUST take the its local copy of the handlespace, the ENRP server MUST take the
handlespace update action to inform its peers about the change just handlespace update action to inform its peers about the change just
made. Otherwise, the ENRP server MUST NOT inform its peers. made. Otherwise, the ENRP server MUST NOT inform its peers.
3.3. Handle resolution 3.3. Handle Resolution
At any time a PE or PU may wish to resolve a handle. This usually At any time, a PE or PU may wish to resolve a handle. This usually
will occur when a ASAP Endpoint sends to a Pool handle ( will occur when an ASAP Endpoint sends a Pool Handle (Section 6.5.1)
Section 6.5.1) to its home ENRP server or requests a cache population to its Home ENRP server or requests a cache population (Section 6.3).
(Section 6.3). It may also occur for other reasons (e.g. the It may also occur for other reasons (e.g., the internal ASAP PE
internal ASAP PE wishes to know its peers for sending a message to wishes to know its peers to send a message to all of them). When an
all of them). When an ASAP Endpoint (PE or PU) wishes to resolve a ASAP Endpoint (PE or PU) wishes to resolve a pool handle to a list of
pool handle to a list of accesible transport addresses of the member accessible transport addresses of the member PEs of the pool, it MUST
PEs of the pool, it MUST take the following actions: take the following actions:
NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with NR1) Fill in an ASAP_HANDLE_RESOLUTION message (Section 2.2.5) with
the Pool Handle to be resolved. the Pool Handle to be resolved.
NR2) If the endpoint does not have a Home ENRP server start the ENRP NR2) If the endpoint does not have a Home ENRP server, start the
Server Hunt procedures specified in Section 3.6 to obtain one. ENRP Server Hunt procedures specified in Section 3.6 to obtain
Otherwise, proceed to step NR3. one. Otherwise, proceed to step NR3.
NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the home NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the Home
ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION ENRP server using SCTP; if a PU, send the ASAP_HANDLE_RESOLUTION
message to the Home ENRP server using either TCP or SCTP. If sent message to the Home ENRP server using either TCP or SCTP. If sent
from a PE, the SCTP association used for registration SHOULD be from a PE, the SCTP association used for registration SHOULD be
used. used.
NR4) Start a T1-ENRPrequest timer. NR4) Start a T1-ENRPrequest timer.
If the T1-ENRPrequest timer expires before receiving a response If the T1-ENRPrequest timer expires before receiving a response
message, the ASAP endpoint SHOULD take the steps described in message, the ASAP Endpoint SHOULD take the steps described in
Section 3.7.2. If a SEND.FAILURE notification is received from the Section 3.7.2. If a SEND.FAILURE notification is received from the
SCTP or TCP layer, the ASAP endpoint SHOULD start the Server Hunt SCTP or TCP layer, the ASAP Endpoint SHOULD start the Server Hunt
procedure (see Section 3.6) in an attempt to get service from a procedure (see Section 3.6) in an attempt to get service from a
different ENRP server. After establishing a new Home ENRP server, different ENRP server. After establishing a new Home ENRP server,
the ASAP endpoint SHOULD restart the handle resolution procedure. the ASAP Endpoint SHOULD restart the handle resolution procedure.
At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message the At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message, the
ASAP endpoint MUST stop its T1-ENRPrequest timer. After stopping the ASAP Endpoint MUST stop its T1-ENRPrequest timer. After stopping the
T1-ENRPrequest timer the ASAP endpoint SHOULD process the message as T1-ENRPrequest timer, the ASAP Endpoint SHOULD process the message as
appropriate (e.g. populate a local cache, give the response to the appropriate (e.g., populate a local cache, give the response to the
ASAP user, and/or use the response to send the ASAP users message). ASAP User, and/or use the response to send the ASAP User's message).
Note that some ASAP endpoints MAY use a cache to minimize the number Note that some ASAP Endpoints MAY use a cache to minimize the number
of handle resolutions sent. If a cache is used, it SHOULD: of handle resolutions sent. If a cache is used, it SHOULD:
C1) Be consulted before sending a handle resolution. C1) Be consulted before sending a handle resolution.
C2) Have a stale timeout timer associated with each cache entry. If C2) Have a stale timeout timer associated with each cache entry. If
the cache entry is determined to be stale upon a cache hit, a the cache entry is determined to be stale upon a cache hit, a
handle resolution message SHOULD be sent so the cache can be handle resolution message SHOULD be sent so the cache can be
updated. updated.
C3) In the case of a stale cache entry the implementation may in C3) In the case of a stale cache entry, the implementation may, in
parallel update the cache and answer the request or it may block parallel, update the cache and answer the request, or it may block
the user and wait for an updated cache before proceeding with the the user and wait for an updated cache before proceeding with the
users request. users request.
C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a
handle resolution request but instead SHOULD use the entry from handle resolution request but instead SHOULD use the entry from
the cache. the cache.
It should be noted that the impact of using a cache depends on the It should be noted that the impact of using a cache depends on the
policy and the requirements of the application. For some policy and the requirements of the application. For some
applications cache-usage can increase the performance of the system, applications, cache-usage can increase the performance of the system;
for some it can decrease it. for some, it can decrease it.
An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION
requests from PUs either over an SCTP association on the well-know requests from PUs, either over an SCTP association on the well-known
SCTP port, or over a TCP connection on the well-know TCP port. SCTP port, or over a TCP connection on the well-known TCP port.
Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server
MUST first look up the pool handle in its handlespace. If the pool MUST first look up the pool handle in its handlespace. If the pool
exits, the home ENRP server MUST compose and send back an exists, the Home ENRP server MUST compose and send back an
ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server SHOULD list all the PEs In the response message, the ENRP server SHOULD list all the PEs
currently registered in this pool, in a list of PE parameters. The currently registered in this pool, in a list of PE parameters. The
ENRP server MUST also include a pool member selection policy ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not round-robin. pool, if the current pool member selection policy is not Round-Robin.
If the named pool does not exist in the handlespace, the ENRP server If the named pool does not exist in the handlespace, the ENRP server
MUST reject the handle resolution request by responding with an MUST reject the handle resolution request by responding with an
ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Pool ASAP_HANDLE_RESOLUTION_RESPONSE message carrying an Unknown Pool
Handle error. Handle error.
3.4. Endpoint keep alive 3.4. Endpoint Keep Alive
The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a
PE in order to verify it is reachable. If the transport level heart PE in order to verify it is reachable. If the transport level
beat mechanism is insufficient, this message can be used in a heart heartbeat mechanism is insufficient, this message can be used in a
beat mechanism for the ASAP level whose goal is determining the heartbeat mechanism for the ASAP level whose goal is determining the
health status of the ASAP level in a timely fashion. (The transport health status of the ASAP level in a timely fashion. (The transport
level heart beat mechanism may be insufficient due to either the time level heartbeat mechanism may be insufficient due to either the
outs or the heart beat interval being set too long, or, that the timeouts or the heartbeat interval being set too long, or, that the
transport level heart beat mechanism's coverage is limited only to transport level heartbeat mechanism's coverage is limited only to the
the transport level at the two ends.) Additionally, the transport level at the two ends.) Additionally, the
ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of
fault detection if the SCTP stack is in the kernel. In such a case, fault detection if the SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity while the SCTP-level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, the ASAP level heartbeat monitors the between the two SCTP stacks, the ASAP-level heartbeat monitors the
end-to-end liveliness of the ASAP layer above it. end-to-end liveliness of the ASAP layer above it.
The use of the ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7) and The use of the ASAP_ENDPOINT_KEEP_ALIVE message (Section 2.2.7) and
the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below.
Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following
actions MUST be taken: actions MUST be taken:
KA1) The PE must verify that the Pool Handle is correct and matches KA1) The PE must verify that the Pool Handle is correct and matches
the Pool Handle sent in its earlier ASAP_REGISTRATION message. If the Pool Handle sent in its earlier ASAP_REGISTRATION message. If
the Pool Handle does not match, the PE MUST silently discard the the Pool Handle does not match, the PE MUST silently discard the
message. message.
KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as
follows: follows:
KA2.1) Fill in the Pool Handle Parameter with the PE's Pool KA2.1) Fill in the Pool Handle parameter with the PE's Pool
Handle. Handle.
KA2.2) Fill in the PE Identifier parameter using the PE KA2.2) Fill in the PE Identifier parameter using the PE
identifier used by this PE for registration. identifier used by this PE for registration.
KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the
appropriate SCTP association for the ENRP server which sent the appropriate SCTP association for the ENRP server that sent the
ASAP_ENDPOINT_KEEP_ALIVE message. ASAP_ENDPOINT_KEEP_ALIVE message.
KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE KA2.4) If the H flag in the received ASAP_ENDPOINT_KEEP_ALIVE
message is set, and the Server Identifier in the message is NOT message is set, and the Server Identifier in the message is NOT
the identity of your Home ENRP server (or it is not set e.g you the identity of your Home ENRP server (or it is not set, e.g.,
have a no Home ENRP server) adopt the sender of the you have a no Home ENRP server) adopt the sender of the
ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server. ASAP_ENDPOINT_KEEP_ALIVE message as the new Home ENRP server.
3.5. Unreachable endpoints 3.5. Unreachable Endpoints
Occasionally, an ASAP endpoint may realize a PE is unreachable. This Occasionally, an ASAP Endpoint may realize a PE is unreachable. This
may occur by a specific SCTP error realized by the ASAP endpoint or may occur by a specific SCTP error realized by the ASAP endpoint or
via an ASAP user report via the Transport.Failure Primitive via an ASAP User report via the Transport.Failure Primitive
(Section 6.9.2). In either case, the ASAP endpoint SHOULD report the (Section 6.9.2). In either case, the ASAP Endpoint SHOULD report the
unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE
message to any ENRP server. Before sending the message to any ENRP server. Before sending the
ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in
the Pool Handle parameter and PE identifier parameter of the the Pool Handle parameter and PE Identifier parameter of the
unreachable endpoint. If the sender is a PE, the message MUST be unreachable endpoint. If the sender is a PE, the message MUST be
sent via SCTP. It should be noted that an ASAP endpoint MUST report sent via SCTP. It should be noted that an ASAP Endpoint MUST report
no more than once each time it encounters such an event. no more than once each time it encounters such an event.
Additionally, when processing a Transport.Failure Primitive Additionally, when processing a Transport.Failure Primitive
(Section 6.9.2) the ASAP endpoint MUST NOT send an (Section 6.9.2), the ASAP Endpoint MUST NOT send an
ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous
request to send data to the PE specified by the primitive. request to send data to the PE specified by the primitive.
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, an ENRP
MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE server MUST immediately send a point-to-point
message to the PE in question (the 'H' flag in the message SHOULD be ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the H flag in
set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails the message SHOULD be set to '0', in this case). If this
(e.g., it results in an SCTP SEND.FAILURE notification), the ENRP ASAP_ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP
server MUST consider the PE as truly unreachable and MUST remove the SEND.FAILURE notification), the ENRP server MUST consider the PE as
PE from its handlespace. truly unreachable and MUST remove the PE from its handlespace.
If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully
to the PE, the ENRP server MUST retain the PE in its handlespace. to the PE, the ENRP server MUST retain the PE in its handlespace.
Moreover, the server SHOULD keep a counter to record how many Moreover, the server SHOULD keep a counter to record how many
ASAP_ENDPOINT_UNREACHABLE messages it has received reporting ASAP_ENDPOINT_UNREACHABLE messages it has received reporting
reachability problem relating to this PE. If the counter exceeds the reachability problem relating to this PE. If the counter exceeds the
protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove
the PE from its handlespace. the PE from its handlespace.
Optionally, an ENRP server may also periodically send point-to-point Optionally, an ENRP server may also periodically send point-to-point
ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each ASAP_ENDPOINT_KEEP_ALIVE (with the H flag set to '0') messages to
of the PEs owned by the ENRP server in order to check their each of the PEs owned by the ENRP server in order to check their
reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE reachability status. If the sending of ASAP_ENDPOINT_KEEP_ALIVE to a
fails, the ENRP server MUST consider the PE as unreachable and MUST PE fails, the ENRP server MUST consider the PE as unreachable and
remove the PE from its handlespace . Note, if an ENRP server owns a MUST remove the PE from its handlespace. Note, if an ENRP server
large number of PEs, the implementation should pay attention not to owns a large number of PEs, the implementation should pay attention
flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. not to flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE
Instead, the implementation MUST distribute the messages. Instead, the implementation MUST distribute the
ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This
can be achieved by varying the time between two can be achieved by varying the time between two
ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/ ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/
minus 50 percent. minus 50 percent.
3.6. ENRP server hunt procedures 3.6. ENRP Server Hunt Procedures
Each PU and PE manages a list of transport addresses of ENRP servers Each PU and PE manages a list of transport addresses of ENRP servers
it knows about. it knows about.
If multicast capabilities are used within the operational scope an If multicast capabilities are used within the operational scope, an
ENRP server MUST send periodically every (N+1)*T6-Serverannounce an ENRP server MUST send periodically every (N+1)*T6-Serverannounce an
ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the ASAP_SERVER_ANNOUNCE message (Section 2.2.10), which includes all the
transport addresses available for ASAP communication on the multicast transport addresses available for ASAP communication on the multicast
ENRP client channel where N is the number of ENRP servers the server ENRP client channel, where N is the number of ENRP servers the server
has found via receiving ASAP_SERVER_ANNOUNCE messages. This should has found via receiving ASAP_SERVER_ANNOUNCE messages. This should
result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per
T6-Serverannounce. T6-Serverannounce.
If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it
SHOULD insert all new included transport addresses into its list of SHOULD insert all new included transport addresses into its list of
ENRP server addresses and start a T7-ENRPoutdate timer for each ENRP server addresses and start a T7-ENRPoutdate timer for each
address. For all already known included transport addresses, the T7- address. For all already-known, included transport addresses, the
ENRPoutdate timer MUST be restarted for each address. If no T7-ENRPoutdate timer MUST be restarted for each address. If no
transport parameters are included in the ASAP_SERVER_ANNOUNCE transport parameters are included in the ASAP_SERVER_ANNOUNCE
message, the SCTP transport protocol is assumed to be used and the message, the SCTP transport protocol is assumed to be used and the
source IP address and the IANA registered ASAP port number is used source IP address and the IANA-registered ASAP port number is used
for communication with the ENRP server. If a T7-ENRPoutdate timer for communication with the ENRP server. If a T7-ENRPoutdate timer
for a transport address expires, the corresponding address is deleted for a transport address expires, the corresponding address is deleted
from the managed list of transport addresses of the PU or PE. from the managed list of transport addresses of the PU or PE.
If multicast capabilities are not used within the operational scope, If multicast capabilities are not used within the operational scope,
each PU and PE MUST have a configured list of transport addresses of each PU and PE MUST have a configured list of transport addresses of
ENRP servers. ENRP servers.
At its startup or when it fails to communicate with its home ENRP At its startup, or when it fails to communicate with its Home ENRP
server (i.e., timed-out on a ENRP request), a PE or PU MUST establish server (i.e., timed out on an ENRP request), a PE or PU MUST
a new Home ENRP server (i.e. setup a TCP connection or SCTP establish a new Home ENRP server (i.e., set up a TCP connection or
association with a different ENRP server). SCTP association with a different ENRP server).
To establish a home ENRP server the following rules MUST be followed: To establish a Home ENRP server, the following rules MUST be
followed:
SH1) The PE or PU SHOULD try to establish an association or SH1) The PE or PU SHOULD try to establish an association or
connection with no more than three ENRP server's. An ASAP connection, with no more than three ENRP servers. An ASAP
endpoint MUST NOT establish more than three associations or Endpoint MUST NOT establish more than three associations or
connections. connections.
SH2) The ASAP endpoint shall start a T5-Serverhunt timer. SH2) The ASAP Endpoint shall start a T5-Serverhunt timer.
SH3) If the ASAP endpoint establishes an association or connection SH3) If the ASAP Endpoint establishes an association or connection
it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD
also reset the T5-Serverhunt timer to its initial value and then also reset the T5-Serverhunt timer to its initial value and then
proceed to step SH6. proceed to step SH6.
SH4) If an association or connection establishment fails, the ASAP SH4) If an association or connection establishment fails, the ASAP
endpoint SHOULD try to establish an association or connection Endpoint SHOULD try to establish an association or connection
using a different transport address. using a different transport address.
SH5) If the T5-Serverhunt timer expires the following should be SH5) If the T5-Serverhunt timer expires, the following should be
performed: performed:
SH5.1) The ASAP endpoint MUST double the value of the T5- SH5.1) The ASAP Endpoint MUST double the value of the T5-
Serverhunt timer. Note that this doubling is capped at the Serverhunt timer. Note that this doubling is capped at the
value RETRAN.max value RETRAN.max.
SH5.2) The ASAP endpoint SHOULD stop the establishment of SH5.2) The ASAP Endpoint SHOULD stop the establishment of
associations and connections with the transport addresses associations and connections with the transport addresses
selected in step SH1. selected in step SH1.
SH5.2) The ASAP endpoint SHOULD repeat trying to establish an SH5.2) The ASAP Endpoint SHOULD repeat trying to establish an
association or connection by proceeding to step SH1. It SHOULD association or connection by proceeding to step SH1. It SHOULD
attempt to select a different set of transport addresses with attempt to select a different set of transport addresses with
which to connect. which to connect.
SH6) The PE or PU shall pick one of the ENRP servers with which it SH6) The PE or PU shall pick one of the ENRP servers with which it
was able to establish an association or connection, and send all was able to establish an association or connection, and send all
subsequent ENRP request messages to this new Home ENRP server. subsequent ENRP request messages to this new Home ENRP server.
3.7. Handling ASAP Endpoint to ENRP Server Communication Failures 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures
Three types of failure may occur when the ASAP endpoint at ether PE Three types of failure may occur when the ASAP Endpoint at either the
or PU tries to communicate with an ENRP server: PE or PU tries to communicate with an ENRP server:
A) SCTP send failure A) SCTP send failure
B) T1-ENRPrequest timer expiration B) T1-ENRPrequest timer expiration
C) Registration failure C) Registration failure
3.7.1. SCTP Send Failure 3.7.1. SCTP Send Failure
This communication failure indicates that the SCTP layer was unable This communication failure indicates that the SCTP layer was unable
to deliver a message sent to an ENRP server. In other words, the to deliver a message sent to an ENRP server. In other words, the
ENRP server is unreachable. ENRP server is unreachable.
In such a case, the ASAP endpoint MUST NOT re-send the undeliverable In such a case, the ASAP Endpoint MUST NOT re-send the undeliverable
message. Instead, it SHOULD discard the message and start the ENRP message. Instead, it SHOULD discard the message and start the ENRP
server hunt procedure as described in Section 3.6 . After finding a Server Hunt procedure as described in Section 3.6. After finding a
new Home ENRP server, the ASAP endpoint should re-send the request. new Home ENRP server, the ASAP Endpoint should re-send the request.
Note that an ASAP endpoint MAY also choose to NOT discard the Note that an ASAP Endpoint MAY also choose to NOT discard the
message, but to queue it for retransmission after a new Home ENRP message, but to queue it for retransmission after a new Home ENRP
server is found. If an ASAP endpoint does choose to discard the server is found. If an ASAP Endpoint does choose to discard the
message, after a new Home ENRP server is found, the ASAP endpoint message, after a new Home ENRP server is found, the ASAP Endpoint
MUST be capable of reconstructing the original request. MUST be capable of reconstructing the original request.
3.7.2. T1-ENRPrequest Timer Expiration 3.7.2. T1-ENRPrequest Timer Expiration
When the T1-ENRPrequest timer expires, the ASAP endpoint should When the T1-ENRPrequest timer expires, the ASAP Endpoint should re-
resend the original request to the ENRP server and restart the T1- send the original request to the ENRP server and restart the T1-
ENRPrequest timer. In parallel, the ASAP endpoint should begin the ENRPrequest timer. In parallel, the ASAP Endpoint should begin the
ENRP server hunt procedures described in Section 3.6. ENRP server hunt procedures described in Section 3.6.
This should be repeated up to MAX-REQUEST-RETRANSMIT times. After This should be repeated up to MAX-REQUEST-RETRANSMIT times. After
that, an Error.Report notification should be generated to inform the that, an Error.Report notification should be generated to inform the
ASAP user and the ENRP request message associated with the T1- ASAP User, and the ENRP request message associated with the T1-
ENRPrequest timer should be discarded. It should be noted that if an ENRPrequest timer should be discarded. It should be noted that if an
alternate ENRP server responds the ASAP endpoint SHOULD adopt the alternate ENRP server responds, the ASAP Endpoint SHOULD adopt the
responding ENRP server as its new Home ENRP server and resend the responding ENRP server as its new Home ENRP server and re-send the
request to the new Home ENRP server. request to the new Home ENRP server.
3.7.3. Registration Failure 3.7.3. Registration Failure
Registration failure is discussed in Section 3.1. Registration failure is discussed in Section 3.1.
3.8. Cookie handling procedures 3.8. Cookie Handling Procedures
Whenever a PE wants, and a control channel exists, it can send an Whenever a PE wants, and a control channel exists, it can send an
ASAP_COOKIE message to a PU via the control channel. The PU's ASAP ASAP_COOKIE message to a PU via the control channel. The PU's ASAP
endpoint stores the Cookie parameter and discards an older cookie if endpoint stores the Cookie parameter and discards an older cookie if
it is previously stored. it is previously stored.
Note: a control channel is a communication channel between a PU and Note: A control channel is a communication channel between a PU and
PE that does not carry data passed to the user. This is accomplished PE that does not carry data passed to the user. This is accomplished
with SCTP by using a PPID to separate the ASAP messages (Cookie and with SCTP by using a PPID to separate the ASAP messages (Cookie and
Business Card) from normal data messages. Business Card) from normal data messages.
If the PU's ASAP endpoint detects a failure and initiates a failover If the PU's ASAP Endpoint detects a failure and initiates a failover
to a different PE, it SHOULD send the lastest received cookie to a different PE, it SHOULD send the latest received cookie
parameter in an ASAP_COOKIE_ECHO message to the new PE as the first parameter in an ASAP_COOKIE_ECHO message to the new PE as the first
message on the control channel. Upper layers may be involved in the message on the control channel. Upper layers may be involved in the
failover procedure. failover procedure.
The cookie handling procedure can be used for state sharing. The cookie handling procedure can be used for state sharing.
Therefore a cookie should be signed by the sending PE ASAP endpoint Therefore, a cookie should be signed by the sending PE ASAP Endpoint
and the cookie should be verified by the receiving PE's ASAP and the cookie should be verified by the receiving PE's ASAP
endpoint. The details of the verification procedure are out of scope Endpoint. The details of the verification procedure are out of scope
for this document. It is only important that the PU always stores for this document. It is only important that the PU always stores
the last received Cookie Parameter and sends that back unmodified in the last received Cookie parameter and sends that back unmodified in
case of a PE failure. case of a PE failure.
3.9. Business Card handling procedures 3.9. Business Card Handling Procedures
When communication begins between a PU and a PE either of which could When communication begins between a PU and a PE, either of which
be part of a PU/PE combination (i.e. a message is sent between the could be part of a PU/PE combination (i.e., a message is sent between
entities), a PE should always send a ASAP_BUSINESS_CARD message to a the entities), a PE should always send an ASAP_BUSINESS_CARD message
PU. A PU should send a ASAP_BUSINESS_CARD message to a PE only if it to a PU. A PU should send an ASAP_BUSINESS_CARD message to a PE only
is part of a PU/PE combination. A ASAP_BUSINESS_CARD message MUST if it is part of a PU/PE combination. An ASAP_BUSINESS_CARD message
ONLY be sent if a control channel exists between a PU and PE. After MUST ONLY be sent if a control channel exists between a PU and PE.
communication as been established between a PE and PU, a new After communication has been established between a PE and PU, a new
ASAP_BUSINESS_CARD message may be sent at any time by either entity ASAP_BUSINESS_CARD message may be sent at any time by either entity
to update its failover order. to update its failover order.
The ASAP_BUSINESS_CARD message serves two purposes. First it lists The ASAP_BUSINESS_CARD message serves two purposes. First, it lists
the pool handle. For a PU which is part of a PU/PE combination which the pool handle. For a PU that is part of a PU/PE combination that
is contacting a PE this is essential so that the PE learns the pool is contacting a PE, this is essential so that the PE learns the pool
handle of the PU/PE combination requesting service. Secondly the handle of the PU/PE combination requesting service. Secondly, the
ASAP_BUSINESS_CARD message tells the receiving entity a failover ASAP_BUSINESS_CARD message tells the receiving entity a failover
order that is recommended to follow. This should facilitate order that is recommended to follow. This should facilitate
rendezvous between entities that have been working together as well rendezvous between entities that have been working together, as well
to control the load redistribution upon the failure of any PE. as to control the load redistribution upon the failure of any PE.
Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13) Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13),
the receiving ASAP endpoint SHOULD: the receiving ASAP Endpoint SHOULD:
BC1) Unpack the message and if no entry exists in the translation BC1) Unpack the message, and if no entry exists in the translation
cache of the receiving ASAP endpoint for the pool handle listed cache of the receiving ASAP Endpoint for the pool handle listed
within the ASAP_BUSINESS_CARD message perform a within the ASAP_BUSINESS_CARD message, perform an
ASAP_HANDLE_RESOLUTION for that pool handle. If the translation ASAP_HANDLE_RESOLUTION for that pool handle. If the translation
cache does hold an entry for the pool handle, then it may be cache does hold an entry for the pool handle, then it may be
necessary to update the peer endpoint. necessary to update the peer endpoint.
BC2) Unpack the message and populate a preferred list for failover BC2) Unpack the message and populate a preferred list for failover
order. If the peers PE should fail this preferred list will be order. If the peer's PE should fail, this preferred list will be
used guide the ASAP endpoint in the selection of an alternate PE. used to guide the ASAP Endpoint in the selection of an alternate
PE.
4. Roles of Endpoints 4. Roles of Endpoints
A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION, and A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION and
ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore it MUST ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore, it MUST
support the handling of ASAP_ERROR messages. It MAY implement the support the handling of ASAP_ERROR messages. It MAY implement the
handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD
messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE
messages. messages.
A PE MUST implement the handling of ASAP_REGISTRATION, A PE MUST implement the handling of ASAP_REGISTRATION,
ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and
ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support
the handling of ASAP_ENDPOINT_KEEP_ALIVE, the handling of ASAP_ENDPOINT_KEEP_ALIVE,
ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and
ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE, ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE,
ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore it ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore, it
MAY support the handling of ASAP_SERVER_ANNOUNCE messages. MAY support the handling of ASAP_SERVER_ANNOUNCE messages.
An ENRP server MUST implement the handling of ASAP_REGISTRATION, An ENRP server MUST implement the handling of ASAP_REGISTRATION,
ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and
ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support
the handling of ASAP_ENDPOINT_KEEP_ALIVE, the handling of ASAP_ENDPOINT_KEEP_ALIVE,
ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and
ASAP_ERROR messages. Furthermore it MAY support the handling of ASAP_ERROR messages. Furthermore, it MAY support the handling of
ASAP_SERVER_ANNOUNCE messages. ASAP_SERVER_ANNOUNCE messages.
If a node acts as a PU and a PE, it MUST fullfil both roles. If a node acts as a PU and a PE, it MUST fulfill both roles.
5. SCTP Considerations 5. SCTP Considerations
Each ASAP message is considered as an SCTP user message. The PPID Each ASAP message is considered as an SCTP user message. The PPID
registered for ASAP SHOULD be used. The SCTP port used at the ENRP registered for ASAP SHOULD be used. The SCTP port used at the ENRP
server might be preconfigured or announced in the server might be preconfigured or announced in the
ASAP_SERVER_ANNOUNCE message or the well known ASAP port. ASAP_SERVER_ANNOUNCE message or the well-known ASAP port.
ASAP messages beloning to the control channel MUST be sent using the ASAP messages belonging to the control channel MUST be sent using the
PPID registered for ASAP. Messages belonging to the data channel PPID registered for ASAP. Messages belonging to the data channel
MUST NOT use the PPID registered for ASAP. MUST NOT use the PPID registered for ASAP.
6. The ASAP Interfaces 6. The ASAP Interfaces
This chapter will focus primarily on the primitives and notifications This chapter will focus primarily on the primitives and notifications
that form the interface between the ASAP-user and ASAP and that that form the interface between the ASAP User and ASAP and that
between ASAP and its lower layer transport protocol (e.g., SCTP). between ASAP and its lower-layer transport protocol (e.g., SCTP).
Note, the following primitive and notification descriptions are shown Note, the following primitive and notification descriptions are shown
for illustrative purposes. We believe that including these for illustrative purposes. We believe that including these
descriptions in this document is important to the understanding of descriptions in this document is important to the understanding of
the operation of many aspects of ASAP. But an ASAP implementation is the operation of many aspects of ASAP; but an ASAP implementation is
not required to use the exact syntax described in this section. not required to use the exact syntax described in this section.
An ASAP User passes primitives to the ASAP sub-layer to request An ASAP User passes primitives to the ASAP sub-layer to request
certain actions. Upon the completion of those actions or upon the certain actions. Upon the completion of those actions or upon the
detection of certain events, the ASAP layer will notify the ASAP detection of certain events, the ASAP layer will notify the ASAP
user. User.
6.1. Registration.Request Primitive 6.1. Registration.Request Primitive
Format: registration.request(poolHandle, Format: registration.request(Pool Handle,
User Transport parameter(s)) User Transport parameter(s))
The poolHandle parameter contains a NULL terminated ASCII string of The Pool Handle parameter contains a NULL terminated ASCII string of
fixed length. The optional User Transport parameter(s) indicate fixed length. The optional User Transport parameter(s) indicates
specific transport parameters and types to register with. If this specific transport parameters and types with which to register. If
optional parameter is left off, then the SCTP endpoint used to this optional parameter is left off, then the SCTP endpoint used to
communicate with the ENRP server is used as the default User communicate with the ENRP server is used as the default User
Transport parameter. Note that any IP address contained within a Transport parameter. Note that any IP address contained within a
User Transport parameter MUST be a bound IP address in the SCTP User Transport parameter MUST be a bound IP address in the SCTP
endpoint used to communicate with the ENRP server. endpoint used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the The ASAP User invokes this primitive to add itself to the
handlespace, thus becoming a Pool Element of a pool. The ASAP user handlespace, thus becoming a Pool Element of a pool. The ASAP User
must register itself with the ENRP server by using this primitive must register itself with the ENRP server by using this primitive
before other ASAP users using the handlespace can send message(s) to before other ASAP Users using the handlespace can send message(s) to
this ASAP user by Pool Handle or by PE handle (see Section 6.5.1 and this ASAP User by Pool Handle or by PE handle (see Sections 6.5.1 and
Section 6.5.3). 6.5.3).
In response to the registration primitive, the ASAP endpoint will In response to the registration primitive, the ASAP Endpoint will
send an ASAP_REGISTRATION message to the home ENRP server (See send an ASAP_REGISTRATION message to the Home ENRP server (see
Section 2.2.1 and Section 3.1), and start a T2-registration timer. Sections 2.2.1 and 3.1), and start a T2-registration timer.
6.2. Deregistration.Request Primitive 6.2. Deregistration.Request Primitive
Format: deregistration.request(poolHandle) Format: deregistration.request(Pool Handle)
The ASAP PE invokes this primitive to remove itself from the Server The ASAP PE invokes this primitive to remove itself from the Server
Pool. This should be used as a part of the graceful shutdown process Pool. This should be used as a part of the graceful shutdown process
by the application. by the application.
A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the An ASAP_DEREGISTRATION message will be sent by the ASAP Endpoint to
home ENRP server (see Section 2.2.2 and Section 3.2). the Home ENRP server (see Sections 2.2.2 and 3.2).
6.3. CachePopulateRequest Primitive 6.3. CachePopulateRequest Primitive
Format: cache_populate_request([Pool-Handle | Format: cache_populate_request([Pool-Handle |
Pool-Element-Handle]) Pool-Element-Handle])
If the address type is a Pool handle and a local handle translation If the address type is a Pool Handle and a local handle translation
cache exists, the ASAP endpoint should initiate a mapping information cache exists, the ASAP Endpoint should initiate a mapping information
query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle
and update it local cache when the response comes back from the ENRP and updating its local cache when the response comes back from the
server. ENRP server.
If a Pool-Element-Handle is passed then the Pool Handle is unpacked If a Pool-Element-Handle is passed, then the Pool Handle is unpacked
from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message
is sent to the ENRP server for resolution. When the response message is sent to the ENRP server for resolution. When the response message
returns from the ENRP server the local cache is updated. returns from the ENRP server, the local cache is updated.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache, this
primitive performs NO action. primitive performs NO action.
6.4. CachePurgeRequest Primitive 6.4. CachePurgeRequest Primitive
Format: cache_purge_request([Pool-Handle | Pool-Element-Handle]) Format: cache_purge_request([Pool-Handle | Pool-Element-Handle])
If the user passes a Pool handle and local handle translation cache If the user passes a Pool Handle and local handle translation cache
exists, the ASAP endpoint should remove the mapping information on exists, the ASAP Endpoint should remove the mapping information on
the Pool handle from its local cache. If the user passes a Pool- the Pool Handle from its local cache. If the user passes a Pool-
Element-Handle then the Pool handle within is used for the Element-Handle, then the Pool Handle within is used for the
cache_purge_request. cache_purge_request.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache, this
primitive performs NO action. primitive performs NO action.
6.5. DataSendRequest Primitive 6.5. DataSendRequest Primitive
Format: data_send_request(destinationAddress, typeOfAddress, Format: data_send_request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified Pool This primitive requests ASAP to send a message to some specified Pool
or Pool Element within the current Operational scope. or Pool Element within the current Operational scope.
Depending on the address type used for the send request, the senders Depending on the address type used for the send request, the sender's
ASAP endpoint may perform address translation and Pool Element ASAP Endpoint may perform address translation and Pool Element
selection before sending the message out. This also MAY dictate the selection before sending the message out. This MAY also dictate the
creation of a local transport endpoint in order to meet the required creation of a local transport endpoint in order to meet the required
transport type. transport type.
The data_send_request primitive can take different forms of address The data_send_request primitive can take different forms of address
types as described in the following sections. types, as described in the following sections.
6.5.1. Sending to a Pool Handle 6.5.1. Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case, the destinationAddress and typeOfAddress together
indicates a pool handle. indicate a pool handle.
This is the simplest form of send_data_request primitive. By This is the simplest form of send_data_request primitive. By
default, this directs ASAP to send the message to one of the Pool default, this directs ASAP to send the message to one of the Pool
Elements in the specified pool. Elements in the specified pool.
Before sending the message out to the pool, the senders ASAP endpoint Before sending the message out to the pool, the sender's ASAP
MUST first perform a pool handle to address translation. It may also endpoint MUST first perform a pool handle to address translation. It
need to perform Pool Element selection if multiple Pool Elements may also need to perform Pool Element selection if multiple Pool
exist in the pool. Elements exist in the pool.
If the senders ASAP implementation does not support a local cache of If the sender's ASAP implementation does not support a local cache of
the mapping information or if it does not have the mapping the mapping information, or if it does not have the mapping
information on the pool in its local cache, it will transmit a information on the pool in its local cache, it will transmit an
ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to ASAP_HANDLE_RESOLUTION message (see Sections 2.2.5 and 3.3) to the
the current home ENRP server, and MUST hold the outbound message in current Home ENRP server and MUST hold the outbound message in queue
queue while awaiting the response from the ENRP server (any further while awaiting the response from the ENRP server (any further send
send request to this pool before the ENRP server responds SHOULD also request to this pool before the ENRP server responds SHOULD also be
be queued). queued).
Once the necessary mapping information arrives from the ENRP server, Once the necessary mapping information arrives from the ENRP server,
the senders ASAP will: the sender's ASAP will:
A) map the pool handle into a list of transport addresses of the A) map the pool handle into a list of transport addresses of the
destination PE(s), destination PE(s);
B) if multiple PEs exist in the pool, ASAP will choose one of them B) if multiple PEs exist in the pool, choose one of them and transmit
and transmit the message to it. In that case, the choice of the the message to it. In that case, the choice of the PE is made by
PE is made by ASAP endpoint of the sender based on the server the ASAP Endpoint of the sender based on the server pooling
pooling policy as discussed in Section 6.5.2 policy, as discussed in Section 6.5.2;
C) Optionally create any transport endpoint that may be needed to C) optionally create any transport endpoint that may be needed to
communicate with the PE selected. communicate with the PE selected;
D) if no transport association or connection exists towards the D) if no transport association or connection exists towards the
destination PE, ASAP will establish any needed transport state, destination PE, establish any needed transport state;
E) send out the queued message(s) to the appropriate transport E) send out the queued message(s) to the appropriate transport
connection using the appropriate send mechanism (e.g. for SCTP the connection using the appropriate send mechanism (e.g., for SCTP,
SEND primitive in [RFC4960] would be used), and, the SEND primitive in [RFC4960] would be used); and,
F) if the local cache is implemented, append/update the local cache F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g. the response. Also, record the local transport information (e.g., the
SCTP association id) if any new transport state was created. SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures see For more on the ENRP server request procedures see [RFC5353].
[I-D.ietf-rserpool-enrp].
Optionally, the ASAP endpoint of the sender may return a Pool Element Optionally, the ASAP Endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that same PE (see Section 6.5.3). that same PE (see Section 6.5.3).
Section 3.7 defines the fail-over procedures for cases where the Section 3.7 defines the failover procedures for cases where the
selected PE is found unreachable. selected PE is found unreachable.
6.5.2. Pool Element Selection 6.5.2. Pool Element Selection
Each time an ASAP user sends a message to a pool that contains more Each time an ASAP User sends a message to a pool that contains more
than one PE, the senders ASAP endpoint must select one of the PEs in than one PE, the sender's ASAP Endpoint must select one of the PEs in
the pool as the receiver of the current message. The selection is the pool as the receiver of the current message. The selection is
done according to the current server pooling policy of the pool to made according to the current server pooling policy of the pool to
which the message is sent. which the message is sent.
Note, no selection is needed if the ASAP_SEND_TOALL option is set Note, no selection is needed if the ASAP_SEND_TOALL option is set
(see Section 6.5.5). (see Section 6.5.5).
Together with the server pooling policy, each PE can also specify a Together with the server pooling policy, each PE can also specify a
Policy Value for itself at the registration time. The meaning of the Policy Value for itself at the registration time. The meaning of the
policy value depends on the current server pooling policy of the Policy Value depends on the current server pooling policy of the
group. A PE can also change its policy value whenever it desires, by group. A PE can also change its Policy Value whenever it desires, by
re-registering itself with the handlespace with a new policy value. re-registering itself with the handlespace with a new Policy Value.
Re-registration shall be done by simply sending another Re-registration shall be done by simply sending another
ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). ASAP_REGISTRATION to its Home ENRP server (see Section 2.2.1).
One basic policy is defined in this document, others can be found in One basic policy is defined in this document; others can be found in
[I-D.ietf-rserpool-policies] [RFC5356]
6.5.2.1. Round Robin Policy 6.5.2.1. Round-Robin Policy
When an ASAP endpoint sends messages by Pool Handle and Round-Robin When an ASAP Endpoint sends messages by Pool Handle and Round-Robin
is the current policy of that Pool, the ASAP endpoint of the sender is the current policy of that Pool, the ASAP Endpoint of the sender
will select the receiver for each outbound message by round-Robining will select the receiver for each outbound message by Round-Robining
through all the registered PEs in that Pool, in an attempt to achieve through all the registered PEs in that Pool, in an attempt to achieve
an even distribution of outbound messages. Note that in a large an even distribution of outbound messages. Note that in a large
server pool, the ENRP server might not send back all PEs to the ASAP server pool, the ENRP server might not send back all PEs to the ASAP
client. In this case the client or PU will be performing a round client. In this case, the client or PU will be performing a Round-
robin policy on a subset of the entire Pool. Robin policy on a subset of the entire Pool.
6.5.3. Sending to a Pool Element Handle 6.5.3. Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case, the destinationAddress and typeOfAddress together
indicate an ASAP Pool Element handle. indicate an ASAP Pool Element handle.
This requests the ASAP endpoint to deliver the message to the PE This requests that the ASAP Endpoint deliver the message to the PE
identified by the Pool Element handle. identified by the Pool Element handle.
The Pool Element handle should contain the Pool Handle and a The Pool Element handle should contain the Pool Handle and a
destination transport address of the destination PE or the Pool destination transport address of the destination PE or the Pool
Handle and the transport type. Other implementation dependent Handle and the transport type. Other implementation dependent
elements may also be cached in a Pool Element handle. elements may also be cached in a Pool Element handle.
The ASAP endpoint shall use the transport address and transport type The ASAP Endpoint shall use the transport address and transport type
to identify the endpoint to communicate with. If no communication to identify the endpoint with which to communicate. If no
state exists with the peer endpoint (and is required by the transport communication state exists with the peer endpoint (and is required by
protocol) the ASAP endpoint MAY setup the needed state and then the transport protocol), the ASAP Endpoint MAY set up the needed
invoke the SEND primitive for the particular transport protocol to state and then invoke the SEND primitive for the particular transport
send the message to the PE. protocol to send the message to the PE.
In addition, if a local translation cache is supported the endpoint In addition, if a local translation cache is supported, the endpoint
will: will:
A) send out the message to the transport address (or association id) A) send out the message to the transport address (or association id)
designated by the PE handle. designated by the PE handle.
B) determine if the Pool Handle is in the local cache. B) determine if the Pool Handle is in the local cache.
If it is NOT, the endpoint will: If it is *not*, the endpoint will:
i) ask the home ENRP server for handle resolution on pool handle i) ask the Home ENRP server for handle resolution on the pool
by sending an ASAP_HANDLE_RESOLUTION message (see handle by sending an ASAP_HANDLE_RESOLUTION message (see
Section 2.2.5), and Section 2.2.5), and
ii) use the response to update the local cache. ii) use the response to update the local cache.
If the pool handle is in the cache, the endpoint will only If the pool handle is in the cache, the endpoint will only
update the pool handle if the cache is stale. A stale cache is update the pool handle if the cache is stale. A stale cache is
indicated by it being older than the protocol parameter indicated by it being older than the protocol parameter
'stale.cache.value' (see Section 7.2). 'stale.cache.value' (see Section 7.2).
Section 3.5 and Section 6.9 defines the fail-over procedures for Sections 3.5 and 6.9 define the failover procedures for cases where
cases where the PE pointed to by the Pool Element handle is found the PE pointed to by the Pool Element handle is found to be
unreachable. unreachable.
Optionally, the ASAP endpoint may return the actual Pool Element Optionally, the ASAP Endpoint may return the actual Pool Element
handle to which the message was sent (this may be different from the handle to which the message was sent (this may be different from the
Pool Element handle specified when the primitive is invoked, due to Pool Element handle specified when the primitive is invoked, due to
the possibility of automatic fail-over). the possibility of automatic failover).
6.5.4. Send by Transport Address 6.5.4. Send by Transport Address
In this case the destinationAddress and typeOfAddress together In this case, the destinationAddress and typeOfAddress together
indicate a transport address and transport type. indicate a transport address and transport type.
This directs the senders ASAP endpoint to send the message out to the This directs the sender's ASAP Endpoint to send the message out to
specified transport address. the specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint failover is supported when this form of send request is
used. This form of send request effectively by-passes the ASAP used. This form of send request effectively bypasses the ASAP
endpoint. endpoint.
6.5.5. Message Delivery Options 6.5.5. Message Delivery Options
The Options parameter passed in the various forms of the above The Options parameter passed in the various forms of the above
data_send_request primitive gives directions to the senders ASAP data_send_request primitive gives directions to the sender's ASAP
endpoint on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise "OR"ing The value of the Options parameter is generated by bit-wise "OR"ing
of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 Use default setting. ASAP_USE_DEFAULT: 0x0000 Use default setting.
ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In ASAP_SEND_FAILOVER: 0x0001 Enables PE failover on this message. In
case where the first selected PE or the PE pointed to by the PE the case where the first selected PE or the PE pointed to by the
handle is found unreachable, the sender's ASAP endpoint SHOULD re- PE handle is found unreachable, the sender's ASAP Endpoint SHOULD
select an alternate PE from the same pool if one exists, and re-select an alternate PE from the same pool if one exists, and
silently re-send the message to this newly selected endpoint. silently re-send the message to this newly selected endpoint.
Note that this is a best-effort service. Applications should be Note that this is a best-effort service. Applications should be
aware that messages can be lost during the failover process, even aware that messages can be lost during the failover process, even
if the underlying transport supports retrieval of unacknowledged if the underlying transport supports retrieval of unacknowledged
data (e.g. SCTP) (Example: messages acknowledged by the SCTP data (e.g., SCTP). (Example: messages acknowledged by the SCTP
layer at a PE, but not yet read by the PE when a PE failure layer at a PE, but not yet read by the PE when a PE failure
occurs.) In the case where the underlying transport does not occurs.) In the case where the underlying transport does not
support such retrieval (e.g. TCP), any data already submitted by support such retrieval (e.g., TCP), any data already submitted by
ASAP to the transport layer may be lost upon failover. ASAP to the transport layer may be lost upon failover.
ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the sender's
endpoint from re-sending the message to any alternate PE in case ASAP Endpoint from re-sending the message to any alternate PE in
that the first selected PE or the PE pointed to by the PE handle case that the first selected PE, or the PE pointed to by the PE
is found unreachable. Instead, the senders ASAP endpoint shall handle, is found to be unreachable. Instead, the sender's ASAP
notify its upper layer about the unreachability with an Endpoint shall notify its upper layer about the unreachability
Error.Report and return any unsent data. with an Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP ASAP_SEND_TO_LAST: 0x0004 This option requests that the sender's
endpoint to send the message to the same PE in the pool that the ASAP Endpoint send the message to the same PE in the pool to which
previous message destined to this pool was sent to. the previous message destined to this pool was sent.
ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option
directs the senders ASAP endpoint to send a copy of the message to directs the sender's ASAP endpoint to send a copy of the message
all the PEs, except for the sender itself if the sender is a PE, to all the PEs, except for the sender itself if the sender is a PE
in that pool. in that pool.
ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination
with ASAP_SEND_TO_ALL option. It permits the senders ASAP with the ASAP_SEND_TO_ALL option. It permits the sender's ASAP
endpoint also deliver a copy of the message to itself if the Endpoint to also deliver a copy of the message to itself if the
sender is a PE of the pool (i.e., loop-back). sender is a PE of the pool (i.e., loop-back).
ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer ASAP_SCTP_UNORDER: 0x1000 This option requests that the transport
to send the current message using un-ordered delivery (note the layer send the current message using un-ordered delivery (note the
underlying transport must support un-ordered delivery for this underlying transport must support un-ordered delivery for this
option to be effective). option to be effective).
6.6. Data.Received Notification 6.6. Data.Received Notification
Format: data.received(messageReceived, sizeOfMessage, Format: data.received(messageReceived, sizeOfMessage,
senderAddress, typeOfAddress) senderAddress, typeOfAddress)
When a new user message is received, the ASAP endpoint of the When a new user message is received, the ASAP Endpoint of the
receiver uses this notification to pass the message to its upper receiver uses this notification to pass the message to its upper
layer. layer.
Along with the message being passed, the ASAP endpoint of the Along with the message being passed, the ASAP Endpoint of the
receiver should also indicate to its upper layer the message senders receiver should also indicate to its upper layer the message senders
address. The senders address can be in the form of either an SCTP address. The sender's address can be in the form of either an SCTP
association id, TCP transport address, UDP transport address, or an association id, TCP transport address, UDP transport address, or an
ASAP Pool Element handle. ASAP Pool Element handle.
A) If the handle translation local cache is implemented at the A) If the handle translation local cache is implemented at the
receiver's ASAP endpoint, a reverse mapping from the senders IP receiver's ASAP Endpoint, a reverse mapping from the sender's IP
address to the pool handle should be performed and if the mapping address to the pool handle should be performed, and if the mapping
is successful, the senders ASAP Pool Element handle should be is successful, the sender's ASAP Pool Element handle should be
constructed and passed in the senderAddress field. constructed and passed in the senderAddress field.
B) If there is no local cache or the reverse mapping is not B) If there is no local cache or the reverse mapping is not
successful, the SCTP association id or other transport specific successful, the SCTP association id or other transport specific
identification (if SCTP is not being used) should be passed in the identification (if SCTP is not being used) should be passed in the
senderAddress field. senderAddress field.
6.7. Error.Report Notification 6.7. Error.Report Notification
Format: error.report(destinationAddress, typeOfAddress, Format: error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage) failedMessage, sizeOfMessage)
An error.report should be generated to notify the ASAP user about An error.report should be generated to notify the ASAP User about
failed message delivery as well as other abnormalities. failed message delivery as well as other abnormalities.
The destinationAddress and typeOfAddress together indicates to whom The destinationAddress and typeOfAddress together indicate to whom
the message was originally sent. The address type can be either a the message was originally sent. The address type can be either an
ASAP Pool Element handle, association id, or a transport address. ASAP Pool Element handle, association id, or a transport address.
The original message (or the first portion of it if the message is The original message (or the first portion of it if the message is
too big) and its size should be passed in the failedMessage and too big) and its size should be passed in the failedMessage and
sizeOfMessage fields, respectively. sizeOfMessage fields, respectively.
6.8. Examples 6.8. Examples
These examples assume an underlying SCTP transport between the PE and These examples assume an underlying SCTP transport between the PE and
PU. Other transports are possible but SCTP is utilized in the PU. Other transports are possible, but SCTP is utilized in the
examples for illustrative purposes. Note that all communication examples for illustrative purposes. Note that all communication
between PU and ENRP server and PE and ENRP servers would be using between the PU and ENRP server and the PE and ENRP servers would be
SCTP. using SCTP.
6.8.1. Send to a New Pool 6.8.1. Send to a New Pool
This example shows the event sequence when a Pool User sends the This example shows the event sequence when a Pool User sends the
message "hello" to a pool which is not in the local translation cache message "hello" to a pool that is not in the local translation cache
(assuming local caching is supported). (assuming local caching is supported).
ENRP Server PU new-handle:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
|2. ASAP_HANDLE_RESOLUTION +---+ | |2. ASAP_HANDLE_RESOLUTION +---+ |
|<-------------------------------| | |<-------------------------------| |
| +---+ | | +---+ |
skipping to change at page 42, line 26 skipping to change at page 40, line 9
| +---+ | | +---+ |
| | 5 | | | | 5 | |
| +---+ 6. "hello1" | | +---+ 6. "hello1" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data_send_request("new-handle", handle-type, "hello1", 6, 0); data_send_request("new-handle", handle-type, "hello1", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-handle" in The ASAP Endpoint, in response, looks up the pool "new-handle" in
its local cache but fails to find it. its local cache, but fails to find it.
2) The ASAP endpoint of PU queues the message, and sends an 2) The ASAP Endpoint of the PU queues the message and sends an
ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all
information about pool "new-handle". information about pool "new-handle".
3) A T1-ENRPrequest timer is started while the ASAP endpoint is 3) A T1-ENRPrequest timer is started while the ASAP Endpoint is
waiting for the response from the ENRP server. waiting for the response from the ENRP server.
4) The ENRP Server responds to the query with an 4) The ENRP server responds to the query with an
ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the
information about pool "new-handle". information about pool "new-handle".
5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local
cache with information on pool "new-handle". cache with information on pool "new-handle".
6) Based on the server pooling policy of pool "new-handle", ASAP at 6) Based on the server pooling policy of pool "new-handle", ASAP at
PU selects the destination PE (PEx), sets up, if necessary, an PU selects the destination PE (PEx), sets up, if necessary, an
SCTP association towards PEx (explicitly or implicitly), and send SCTP association towards PEx (explicitly or implicitly), and sends
out the queued "hello1" user message. out the queued "hello1" user message.
6.8.2. Send to a Cached Pool Handle 6.8.2. Send to a Cached Pool Handle
This shows the event sequence when the ASAP user PU sends another This shows the event sequence when the ASAP User PU sends another
message to the pool "new-handle" after what happened in message to the pool "new-handle" after what happened in
Section 6.8.1. Section 6.8.1.
ENRP Server PU new-handle:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello2" | | +---+ 2. "hello2" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
pdata_send_request("new-handle", handle-type, "hello2", 6, 0); data_send_request("new-handle", handle-type, "hello2", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-handle" in The ASAP Endpoint, in response, looks up the pool "new-handle" in
its local cache and find the mapping information. its local cache and finds the mapping information.
2) Based on the server pooling policy of "new-handle", ASAP at PU 2) Based on the server pooling policy of "new-handle", ASAP at PU
selects the PE (assume EPx is selected again), and sends out selects the PE (assuming EPx is selected again), and sends out
"hello2" message (assume the SCTP association is already set up). "hello2" message (assuming the SCTP association is already set
up).
6.9. PE send failure 6.9. PE Send Failure
When the ASAP endpoint in a PE or PU attempts to send a message to a When the ASAP Endpoint in a PE or PU attempts to send a message to a
PE and fails the failed sender will report the event as described in PE and fails, the failed sender will report the event as described in
Section 3.5 . Section 3.5.
Additional primitive are also defined in this section to support Additional primitives are also defined in this section to support
those user applications that do not wish to use ASAP as the actual those user applications that do not wish to use ASAP as the actual
transport. transport.
6.9.1. Translation.Request Primitive 6.9.1. Translation.Request Primitive
Format: translation.request(Pool-Handle) Format: translation.request(Pool-Handle)
If the address type is a Pool handle and a local handle translation If the address type is a Pool Handle and a local handle translation
cache exists, the ASAP endpoint should look within its translation cache exists, the ASAP Endpoint should look within its translation
cache and return the current known transport types, ports and cache and return the current known transport types, ports, and
addresses to the caller. addresses to the caller.
If the Pool handle does not exist in the local handle cache or no If the Pool Handle does not exist in the local handle cache or no
handle cache exists, the ASAP endpoint will send an handle cache exists, the ASAP Endpoint will send an
ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon ASAP_HANDLE_RESOLUTION request using the Pool Handle. Upon
completion of the handle resolution, the ASAP endpoint should completion of the handle resolution, the ASAP Endpoint should
populate the local handle cache (if a local handle cache is populate the local handle cache (if a local handle cache is
supported) and return the transport types, ports and addresses to the supported) and return the transport types, ports, and addresses to
caller. the caller.
6.9.2. Transport.Failure Primitive 6.9.2. Transport.Failure Primitive
Format: transport.failure(Pool-Handle, Transport-address) Format: transport.failure(Pool-Handle, Transport-address)
If an external user encounters a failure in sending to a PE and is If an external user encounters a failure in sending to a PE and is
NOT using ASAP it can use this primitive to report the failure to the *not* using ASAP, it can use this primitive to report the failure to
ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the the ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to
"home" ENRP server in response to this primitive. Note ASAP SHOULD the "Home" ENRP server in response to this primitive. Note ASAP
NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually SHOULD NOT send an ASAP_ENDPOINT_UNREACHABLE *unless* the user has
made a previous request to send data to the PE. actually made a previous request to send data to the PE.
7. Timers, Variables, and Thresholds 7. Timers, Variables, and Thresholds
The following is a summary of the timers, variables, and pre-set The following is a summary of the timers, variables, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
7.1. Timers 7.1. Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending an ASAP_REGISTRATION T2-registration - A timer started when sending an ASAP_REGISTRATION
request to the home ENRP server, normally set to 30 seconds. request to the Home ENRP server, normally set to 30 seconds.
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a de-registration
request to the home ENRP server, normally set to 30 seconds. request to the Home ENRP server, normally set to 30 seconds.
T4-reregistration - This timer is started after successful T4-reregistration - This timer is started after successful
registration into the ENRP handle space and is used to cause a re- registration into the ENRP handlespace and is used to cause a re-
registration at a periodic interval. This timer is normally set registration at a periodic interval. This timer is normally set
to 10 minutes or 20 seconds less than the Life Timer parameter to 10 minutes or 20 seconds less than the Lifetime parameter used
used in the registration request (whichever is less). in the registration request (whichever is less).
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP Server Hunt
procedure and is normally set to 10 seconds. procedure and is normally set to 10 seconds.
T6-Serverannounce - This timer gives the time between the sending of T6-Serverannounce - This timer gives the time between the sending of
consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to
1 second. 1 second.
T7-ENRPoutdate - This timer gives the time a server announcement is T7-ENRPoutdate - This timer gives the time a server announcement is
valid. It is normally set to 5 seconds. valid. It is normally set to 5 seconds.
7.2. Variables 7.2. Variables
skipping to change at page 46, line 6 skipping to change at page 43, line 16
MAX-REG-ATTEMPT - The maximum number of registration attempts to be MAX-REG-ATTEMPT - The maximum number of registration attempts to be
made before a server hunt is issued. The default value of this is made before a server hunt is issued. The default value of this is
set to 2. set to 2.
MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. The default value for this is 2. server hunt is issued. The default value for this is 2.
RETRAN-MAX - This value represents the maximum time between RETRAN-MAX - This value represents the maximum time between
registration attmempts and puts a ceiling on how far the registration attempts and puts a ceiling on how far the
registration timer will back-off. The default value for this is registration timer will back off. The default value for this is
normally set to 60 seconds. normally set to 60 seconds.
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: This document (RFC 5352) is the reference for all registrations
described in this section. All registrations have been listed on the
"RFCXXXX" is to be replaced by the RFC number you assign this Reliable Server Pooling (RSerPool) Parameters page.
document.
]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed on an
RSerPool specific page.
8.1. A New Table for ASAP Message Types 8.1. A New Table for ASAP Message Types
ASAP Message Types have to be maintained by IANA. Fourteen initial ASAP Message Types are maintained by IANA. Fourteen initial values
values should be assigned by IANA as described in Figure 1. This have been assigned by IANA as described in Figure 1. IANA created a
requires a new table "ASAP Message Types": new table, "ASAP Message Types":
Type Message Name Reference Type Message Name Reference
----- ------------------------- --------- ----- ------------------------- ---------
0x00 (reserved by IETF) RFCXXXX 0x00 (Reserved by IETF) RFC 5352
0x01 ASAP_REGISTRATION RFCXXXX 0x01 ASAP_REGISTRATION RFC 5352
0x02 ASAP_DEREGISTRATION RFCXXXX 0x02 ASAP_DEREGISTRATION RFC 5352
0x03 ASAP_REGISTRATION_RESPONSE RFCXXXX 0x03 ASAP_REGISTRATION_RESPONSE RFC 5352
0x04 ASAP_DEREGISTRATION_RESPONSE RFCXXXX 0x04 ASAP_DEREGISTRATION_RESPONSE RFC 5352
0x05 ASAP_HANDLE_RESOLUTION RFCXXXX 0x05 ASAP_HANDLE_RESOLUTION RFC 5352
0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFCXXXX 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFC 5352
0x07 ASAP_ENDPOINT_KEEP_ALIVE RFCXXXX 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFC 5352
0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFCXXXX 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFC 5352
0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX 0x09 ASAP_ENDPOINT_UNREACHABLE RFC 5352
0x0a ASAP_SERVER_ANNOUNCE RFCXXXX 0x0a ASAP_SERVER_ANNOUNCE RFC 5352
0x0b ASAP_COOKIE RFCXXXX 0x0b ASAP_COOKIE RFC 5352
0x0c ASAP_COOKIE_ECHO RFCXXXX 0x0c ASAP_COOKIE_ECHO RFC 5352
0x0d ASAP_BUSINESS_CARD RFCXXXX 0x0d ASAP_BUSINESS_CARD RFC 5352
0x0e ASAP_ERROR RFCXXXX 0x0e ASAP_ERROR RFC 5352
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (Available for Assignment) RFC 5352
Requests to register an ASAP Message Type in this table should be
For registering at IANA an ASAP Message Type in this table a request sent to IANA. The number must be unique. The "Specification
has to be made to assign such a number. This number must be unique. Required" policy of [RFC5226] MUST be applied.
The "Specification Required" policy of [RFC5226] MUST be applied.
8.2. Port numbers 8.2. Port Numbers
The references for the already assigned port numbers The references for the already assigned port numbers
asap-tcp 3863/tcp asap-tcp 3863/tcp
asap-udp 3863/udp asap-udp 3863/udp
asap-sctp 3863/sctp asap-sctp 3863/sctp
asap-tcp-tls 3864/tcp asap-tcp-tls 3864/tcp
asap-sctp-tls 3864/sctp asap-sctp-tls 3864/sctp
should be updated to RFCXXXX. have been updated to RFC 5352.
8.3. SCTP payload protocol identifier 8.3. SCTP Payload Protocol Identifier
The reference for the already assigned ASAP payload protocol The reference for the already assigned ASAP payload protocol
identifier 11 should be updated to RFCXXXX. identifier 11 has been updated to RFC 5352.
8.4. Multicast addresses 8.4. Multicast Addresses
IANA needs to assign an IPv4 and an IPv6 mulitcast address. The IPv4 IANA has assigned an IPv4 multicast address (224.0.1.185) and an IPv6
address should be part of the Internetwork Control Block multicast address (FF0X:0:0:0:0:0:0:133). The IPv4 address is part
(224.0.1/24). of the Internetwork Control Block (224.0.1/24).
9. Security Considerations 9. Security Considerations
We present a summary of the of the threats to the Rserpool We present a summary of the of the threats to the RSerPool
architecture and describe security requirements in response to architecture and describe security requirements in response in order
mitigate the threats. Next we present the security mechanisms, based to mitigate the threats. Next, we present the security mechanisms,
on TLS, that are implementation requirements in response to the based on TLS, that are implementation requirements in response to the
threats. Finally, we present a chain of trust argument that examines threats. Finally, we present a chain-of-trust argument that examines
critical data paths in Rserpool and shows how these paths are critical data paths in RSerPool and shows how these paths are
protected by the TLS implementation. protected by the TLS implementation.
9.1. Summary of Rserpool Security Threats 9.1. Summary of RSerPool Security Threats
Threats Introduced by Rserpool and Requirements for Security in "Threats Introduced by Reliable Server Pooling (RSerPool) and
Response to Threats [I-D.ietf-rserpool-threats] describes the threats Requirements for Security in Response to Threats" [RFC5355] describes
to the Rserpool architecture in detail lists the security the threats to the RSerPool architecture in detail and lists the
requirements in response to each threat. From the threats described security requirements in response to each threat. From the threats
in this document, the security services required for the Rserpool described in this document, the security services required for the
protocol are enumerated below. RSerPool protocol are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/de-registration flooding or spoofing.
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE.
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server.
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server.
Threat 1 and 2 taken together results in mutual authentication of the Threats 1 and 2, taken together, result in mutual authentication of
ENRP server and the PE. the ENRP server and the PE.
Threat 3) Malicious ENRP server joins the ENRP server pool Threat 3) Malicious ENRP server joins the ENRP server pool.
----------- -----------
Security mechanism in response: ENRP servers mutually authenticate Security mechanism in response: ENRP servers mutually authenticate.
Threat 4) A PU communicates with a malicious ENRP server for handle Threat 4) A PU communicates with a malicious ENRP server for handle
resolution resolution.
----------- -----------
Security mechanism in response: The PU authenticates the ENRP server Security mechanism in response: The PU authenticates the ENRP server.
Threat 5) Replay attack Threat 5) Replay attack.
----------- -----------
Security mechanism in response: Security protocol which has Security mechanism in response: Security protocol that has protection
protection from replay attacks from replay attacks.
Threat 6) Corrupted data which causes a PU to have misinformation Threat 6) Corrupted data that causes a PU to have misinformation
concerning a pool handle resolution concerning a pool handle resolution.
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol that supports
integrity protection integrity protection.
Threat 7) Eavesdropper snooping on handlespace information Threat 7) Eavesdropper snooping on handlespace information.
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol that supports data
confidentiality confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server ENRP server.
----------- -----------
Security mechanism in response: ASAP must control the number of ASAP Security mechanism in response: ASAP must control the number of ASAP
endpoint unreachable messages transmitted from the PU to the ENRP Endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server the ENRP server.
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE.
To summarize the threats 1-7 require security mechanisms which To summarize, the threats 1-7 require security mechanisms that
support authentication, integrity, data confidentiality, protection support authentication, integrity, data confidentiality, and
from replay attacks. protection from replay attacks.
For Rserpool we need to authenticate the following: For RSerPool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP server (mutual authentication)
9.2. Implementing Security Mechanisms 9.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use an existing IETF security responding to threats 1-7. Rather, we use an existing IETF security
protocol, specifically [RFC3237], to provide the security services protocol, specifically [RFC3237], to provide the security services
required. TLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported at a minimum by implementors of TLS for Rserpool. For supported, at a minimum, by implementers of TLS for RSerPool. For
purposes of backwards compatibility, ENRP SHOULD support purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other IETF approved ciphersuites. other IETF-approved ciphersuites.
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs MUST ENRP servers, PEs, and PUs MUST implement TLS. ENRP servers and PEs
support mutual authentication using PSK. ENRP servers MUST support MUST support mutual authentication using PSK (pre-shared-key). ENRP
mutual authentication among themselves using PSK. PUs MUST servers MUST support mutual authentication among themselves using
authenticate ENRP servers using certificates. PSK. PUs MUST authenticate ENRP servers using certificates.
TLS with PSK is mandatory to implement as the authentication TLS with PSK is mandatory to implement as the authentication
mechanism for ENRP to ENRP authentication and PE to ENRP mechanism for ENRP to ENRP authentication and PE to ENRP
authentication. For PSK, having a pre-shared-key constitutes authentication. For PSK, having a pre-shared-key constitutes
authorization.The network administrators of a pool need to decide authorization. The network administrators of a pool need to decide
which nodes are authorized to participate in the pool. The which nodes are authorized to participate in the pool. The
justification for PSK is that we assume that one administrative justification for PSK is that we assume that one administrative
domain will control and manage the server pool. This allows for PSK domain will control and manage the server pool. This allows for PSK
to be implemented and managed by a central security administrator. to be implemented and managed by a central security administrator.
TLS with certificates is mandatory to implement as the authentication TLS with certificates is mandatory to implement as the authentication
mechanism for PU to ENRP server. PUs MUST autnthenticate ENRP mechanism for PUs to the ENRP server. PUs MUST authenticate ENRP
servers using certificates. ENRP servers MUST possess a site servers using certificates. ENRP servers MUST possess a site
certificate whose subject corresponds to their canonical hostname. certificate whose subject corresponds to their canonical hostname.
PUs MAY have certificates of their own for mutual authentication with PUs MAY have certificates of their own for mutual authentication with
TLS, but no provisions are set forth in this document for their use. TLS, but no provisions are set forth in this document for their use.
All Rserpool elements that support TLS MUST have a mechanism for All RSerPool Elements that support TLS MUST have a mechanism for
validating certificates received during TLS negotiation; this entails validating certificates received during TLS negotiation; this entails
possession of one or more root certificates issued by certificate possession of one or more root certificates issued by certificate
authorities (preferably well-known distributors of site certificates authorities (preferably, well-known distributors of site certificates
comparable to those that issue root certificates for web browsers). comparable to those that issue root certificates for web browsers).
In order to prevent man-in-the-middle attacks, the client MUST verify In order to prevent man-in-the-middle attacks, the client MUST verify
the server's identity (as presented in the server's Certificate the server's identity (as presented in the server's Certificate
message). The client's understanding of the server's identity message). The client's understanding of the server's identity
(typically the identity used to establish the transport connection) (typically, the identity used to establish the transport connection)
is called the "reference identity". The client determines the type is called the "reference identity". The client determines the type
(e.g., DNS name or IP address) of the reference identity and performs (e.g., DNS name or IP address) of the reference identity and performs
a comparison between the reference identity and each subjectAltName a comparison between the reference identity and each subjectAltName
value of the corresponding type until a match is produced. Once a value of the corresponding type until a match is produced. Once a
match is produced, the server's identity has been verified, and the match is produced, the server's identity has been verified, and the
server identity check is complete. Different subjectAltName types server identity check is complete. Different subjectAltName types
are matched in different ways. The client may map the reference are matched in different ways. The client may map the reference
identity to a different type prior to performing a comparison. identity to a different type prior to performing a comparison.
Mappings may be performed for all available subjectAltName types to Mappings may be performed for all available subjectAltName types to
which the reference identity can be mapped; however, the reference which the reference identity can be mapped; however, the reference
identity should only be mapped to types for which the mapping is identity should only be mapped to types for which the mapping is
either inherently secure (e.g., extracting the DNS name from a URI to either inherently secure (e.g., extracting the DNS name from a URI to
compare with a subjectAltName of type dNSName) or for which the compare with a subjectAltName of type dNSName) or for which the
mapping is performed in a secure manner (e.g., using DNSSEC, or using mapping is performed in a secure manner (e.g., using DNS Security
user- or admin-configured host- to-address/address-to-host lookup (DNSSEC), or using user- or admin-configured host-to-address/
tables).. address-to-host lookup tables).
If the server identity check fails, user-oriented clients SHOULD If the server identity check fails, user-oriented clients SHOULD
either notify the user or close the transport connection and indicate either notify the user or close the transport connection and indicate
that the server's identity is suspect. Automated clients SHOULD that the server's identity is suspect. Automated clients SHOULD
close the transport connection and then return or log an error close the transport connection and then return or log an error
indicating that the server's identity is suspect or both. Beyond the indicating that the server's identity is suspect, or both. Beyond
server identity check described in this section, clients should be the server identity check described in this section, clients should
prepared to do further checking to ensure that the server is be prepared to do further checking to ensure that the server is
authorized to provide the service it is requested to provide. The authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making client may need to make use of local policy information in making
this determination. this determination.
If the reference identity is an internationalized domain name, If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of [RFC3490] before Encoding (ACE) format, as specified in Section 4 of [RFC3490], before
comparison with subjectAltName values of type dNSName. Specifically, comparison with subjectAltName values of type dNSName. Specifically,
conforming implementations MUST perform the conversion operation conforming implementations MUST perform the conversion operation
specified in Section 4 of [RFC3490] as follows: * in step 1, the specified in Section 4 of [RFC3490] as follows: * in step 1, the
domain name SHALL be considered a "stored string"; * in step 3, set domain name SHALL be considered a "stored string"; * in step 3, set
the flag called "UseSTD3ASCIIRules"; * in step 4, process each label the flag called "UseSTD3ASCIIRules"; * in step 4, process each label
with the "ToASCII" operation; and * in step 5, change all label with the "ToASCII" operation; and * in step 5, change all label
separators to U+002E (full stop). separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in MUST be compared for equality, according to the rules specified in
Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is
allowed in subjectAltName values of type dNSName, and then only as allowed in subjectAltName values of type dNSName, and then, only as
the left-most (least significant) DNS label in that value. This the left-most (least significant) DNS label in that value. This
wildcard matches any left-most DNS label in the server name. That wildcard matches any left-most DNS label in the server name. That
is, the subject *.example.com matches the server names a.example.com is, the subject *.example.com matches the server names a.example.com
and b.example.com, but does not match example.com or a.b.example.com. and b.example.com, but does not match example.com or a.b.example.com.
When the reference identity is an IP address, the identity MUST be When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation RFC converted to the "network byte order" octet string representation in
791[RFC0791][RFC2460][RFC2460]. For IP Version 4, as specified in [RFC0791] and [RFC2460]. For IP version 4, as specified in RFC 791,
RFC 791, the octet string will contain exactly four octets. For IP the octet string will contain exactly four octets. For IP version 6,
Version 6, as specified in RFC 2460, the octet string will contain as specified in RFC 2460, the octet string will contain exactly
exactly sixteen octets. This octet string is then compared against sixteen octets. This octet string is then compared against
subjectAltName values of type iPAddress. A match occurs if the subjectAltName values of type iPAddress. A match occurs if the
reference identity octet string and value octet strings are reference identity octet string and value octet strings are
identical. identical.
After a TLS layer is established in an session, both parties are to After a TLS layer is established in a session, both parties are to
each independently decide whether or not to continue based on local independently decide whether or not to continue based on local policy
policy and the security level achieved. If either party decides that and the security level achieved. If either party decides that the
the security level is inadequate for it to continue, it SHOULD remove security level is inadequate for it to continue, it SHOULD remove the
the TLS layer immediately after the TLS (re)negotiation has completed TLS layer immediately after the TLS (re)negotiation has completed
(see RFC4511)[RFC4511]. Implementations may reevaluate the security (see RFC 4511)[RFC4511]. Implementations may re-evaluate the
level at any time and, upon finding it inadequate, should remove the security level at any time and, upon finding it inadequate, should
TLS layer. remove the TLS layer.
Implementations MUST support TLS with SCTP as described in [RFC3436] Implementations MUST support TLS with SCTP, as described in [RFC3436]
or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we
must ensure that RSerPool does not use any features of SCTP that are must ensure that RSerPool does not use any features of SCTP that are
not available to an TLS/SCTP user. This is not a difficult technical not available to a TLS/SCTP user. This is not a difficult technical
problem, but simply a requirement. When describing an API of the problem, but simply a requirement. When describing an API of the
RSerPool lower layer we have also to take into account the RSerPool lower layer, we also have to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5) to the ENRP
to the ENRP server. server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
[I-D.ietf-rserpool-enrp]). [RFC5353]).
There is no security mechanism defined for the multicast There is no security mechanism defined for the multicast
announcements. Therefore a receiver of such an announcement can not announcements. Therefore, a receiver of such an announcement cannot
consider the source address of such a message to be a trustworthy consider the source address of such a message to be a trustworthy
address of an ENRP server. A receiver must also be prepared to address of an ENRP server. A receiver must also be prepared to
receive a large number of multicast announcements from attackers. receive a large number of multicast announcements from attackers.
9.3. Chain of trust 9.3. Chain of Trust
Security is mandatory to implement in Rserpool and is based on TLS Security is mandatory to implement in RSerPool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
Rserpool -- namely PU, PE and ENRP server. We define an ENRP server RSerPool -- namely PU, PE, and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
the security. the security.
PU <---> secured ENRP Server (authentication of ENRP server; PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS) queries over TLS)
PE <---> secured ENRP server (mutual authentication; PE <---> secured ENRP server (mutual authentication;
registration/deregistration over TLS) registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication; secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS) database updates using TLS)
If all components of the system authenticate and communicate using If all components of the system authenticate and communicate using
TLS, the chain of trust is sound. The root of the trust chain is the TLS, the chain of trust is sound. The root of the trust chain is the
ENRP server. If that is secured using TLS, then security will be ENRP server. If that is secured using TLS, then security will be
enforced for all ENRP and PE components that try to connect to it. enforced for all ENRP and PE components that try to connect to it.
Summary of interaction between secured and unsecured components: If Summary of interaction between secured and unsecured components: If
the PE does not use TLS and tries to register with a secure ENRP the PE does not use TLS and tries to register with a secure ENRP
server, it will receive an error message response indicated as error server, it will receive an error message response indicated as an
due to security considerations and the registration will be rejected. error due to security considerations and the registration will be
If an ENRP server which does not use TLS tries to update the database rejected. If an ENRP server that does not use TLS tries to update
of a secure ENRP server, then the update will be rejected. If an PU the database of a secure ENRP server, then the update will be
does not use TLS and communicates with a secure ENRP server, it will rejected. If a PU does not use TLS and communicates with a secure
get a response with the understanding that the response is not secure ENRP server, it will get a response with the understanding that the
as the response can be tampered with in transit even if the ENRP response is not secure, as the response can be tampered with in
database is secured. transit even if the ENRP database is secured.
The final case is the PU sending a secure request to ENRP. It might The final case is the PU sending a secure request to ENRP. It might
be that ENRP and PEs are not secured and this is an allowable be that ENRP and PEs are not secured and this is an allowable
configuration. The intent is to secure the communication over the configuration. The intent is to secure the communication over the
Internet between the PU and the ENRP server. Internet between the PU and the ENRP server.
Summary: Summary:
Rserpool architecture components can communicate with each other to RSerPool architecture components can communicate with each other to
establish a chain of trust. Secured PE and ENRP servers reject any establish a chain of trust. Secured PE and ENRP servers reject any
communications with unsecured ENRP or PE servers. communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for If the above is enforced, then a chain of trust is established for
the Rserpool user. the RSerPool user.
10. Acknowledgments 10. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 56, line 30 skipping to change at page 50, line 45
Server Pooling", RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-rserpool-policies] [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling
Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", RFC 5356, September 2008.
Policies", draft-ietf-rserpool-policies-09 (work in
progress), May 2008.
[I-D.ietf-rserpool-common-param] [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint "Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-17 (work in progress), RFC 5354, September 2008.
May 2008.
[I-D.ietf-rserpool-enrp] [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), (ENRP)", RFC 5353, September 2008.
May 2008.
[I-D.ietf-rserpool-threats] [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M.,
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. and S. Sengodan, "Threats Introduced by Reliable Server
Sengodan, "Threats Introduced by RSerPool and Requirements Pooling (RSerPool) and Requirements for Security in
for Security in Response to Threats", Response to Threats", RFC 5355, September 2008.
draft-ietf-rserpool-threats-15 (work in progress),
July 2008.
11.2. Informative References 11.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
4875 Forest Drive The Resource Group
Suite 200 1700 Pennsylvania Ave NW
Columbia, SC 29206 Suite 560
Washington, D.C., 20006
USA USA
Phone: EMail: randall@lakerest.net
Email: randall@lakerest.net
Qiaobing Xie Qiaobing Xie
The Resource Group
1700 Pennsylvania Ave NW
Suite 560
Washington, D.C., 20006
USA USA
Phone: +1 224-465-5954 Phone: +1 224-465-5954
Email: Qiaobing.Xie@gmail.org EMail: Qiaobing.Xie@gmail.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 1167 Peachtree Ct.
Ithaca, NY 14850 Naperville, IL 60540
USA USA
Phone: EMail: maureen.stillman@nokia.com
Email: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 430 change blocks. 
881 lines changed or deleted 849 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/