draft-ietf-rserpool-asap-13.txt   draft-ietf-rserpool-asap-14.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 11, 2006 Q. Xie Intended status: Informational Q. Xie
Motorola, Inc. Expires: April 21, 2007 Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
February 7, 2006 October 18, 2006
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-13.txt draft-ietf-rserpool-asap-14.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 11, 2006. This Internet-Draft will expire on April 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Handlespace Redundancy Protocol (ENRP) [7] provides a high Endpoint Handlespace Redundancy Protocol (ENRP) [8] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
handle-based addressing model which isolates a logical communication handle-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes 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) RFC2960 [4]. Each transport protocol to be used by Pool (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool
Elements (PE) and Pool Users (PU) MUST have an accompanying Elements (PE) and Pool Users (PU) MUST have an accompanying
transports mapping document. Note that ASAP messages passed between transports mapping document. It should be noted that ASAP messages
PE's and ENRP servers MUST use SCTP. passed between PE's and ENRP 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Organization of this document . . . . . . . . . . . . . . 6 1.2. Organization of this document . . . . . . . . . . . . . . 6
1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8
2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8
2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9
2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9
2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10
2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10 2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 11
2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 11 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 12
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 14
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 15
2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 15
2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 13 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 16
2.2.11. COOKIE message . . . . . . . . . . . . . . . . . . . . 14 2.2.11. ASAP_COOKIE message . . . . . . . . . . . . . . . . . 16
2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 14 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 17
2.2.13. BUSINESS_CARD message . . . . . . . . . . . . . . . . 14 2.2.13. ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . 17
2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 15 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 18
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 18 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 22
3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 23
3.5. Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.5. Reporting unreachable endpoints . . . . . . . . . . . . . 24
3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 24
3.7. Handle ASAP to ENRP Communication Failures . . . . . . . . 22 3.7. Handling ASAP Endpoint to ENRP Server Communication
3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 Failures . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 26
3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 26
3.9. Business Card handling procedures . . . . . . . . . . . . 23 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 27
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 25 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 27
4.1. Registration.Request Primitive . . . . . . . . . . . . . . 25 3.9. Business Card handling procedures . . . . . . . . . . . . 27
4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 25 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 29
4.3. Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 4.1. Registration.Request Primitive . . . . . . . . . . . . . . 29
4.4. Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 29
4.5. Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 4.3. Cache.Populate.Request Primitive . . . . . . . . . . . . . 30
4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 27 4.4. Cache.Purge.Request Primitive . . . . . . . . . . . . . . 30
4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 28 4.5. Data.Send.Request Primitive . . . . . . . . . . . . . . . 30
4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 29 4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 31
4.5.4. Send by Transport Address . . . . . . . . . . . . . . 30 4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 32
4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 31 4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 33
4.6. Data.Received Notification . . . . . . . . . . . . . . . . 32 4.5.4. Send by Transport Address . . . . . . . . . . . . . . 34
4.7. Error.Report Notification . . . . . . . . . . . . . . . . 32 4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 34
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6. Data.Received Notification . . . . . . . . . . . . . . . . 35
4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 33 4.7. Error.Report Notification . . . . . . . . . . . . . . . . 36
4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 34 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 34 4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 36
4.9.1. Translation.Request Primitive . . . . . . . . . . . . 35 4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 38
4.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 35 4.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 38
5. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 36 4.9.1. Translation.Request Primitive . . . . . . . . . . . . 38
5.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 39
5.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 40
5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38 5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 40
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 44
8.2. Informational References (non-normative) . . . . . . . . . 41 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 43 8.1. Normative References . . . . . . . . . . . . . . . . . . . 47
8.2. Informational References (non-normative) . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7] The Aggregate Server Access Protocol (ASAP) when used in conjunction
provides a high availability data transfer mechanism over IP with Endpoint Name Resolution Protocol [8] provides a high
networks. ASAP uses a handle-based addressing model which isolates a availability data transfer mechanism over IP networks. ASAP uses a
logical communication endpoint from its IP address(es), thus handle-based addressing model which isolates a logical communication
effectively eliminating the binding between the communication endpoint from its IP address(es), thus effectively eliminating the
endpoint and its physical IP address(es) which normally constitutes a binding between the communication endpoint and its physical IP
single point of failure. address(es) which normally constitutes a 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 (a.k.a,
a server pool, ASAP will select one Pool Element (PE), based on the a server pool),an ASAP endpoint will select one Pool Element (PE),
current load sharing policy indicated by the server pool, and deliver based on the current load sharing policy indicated by the server
the message to the selected PE. pool, and deliver its message to the selected PE.
While delivering the message, ASAP monitors the reachability of the While delivering the message, ASAP can be used to monitor the
selected PE. If it is found unreachable, before notifying the sender reachability of the selected PE. If it is found unreachable, before
of the failure, ASAP can automatically select another PE (if one notifying the message sender (an ASAP user) of the failure, ASAP can
exists) under that pool and attempt to deliver the message to that automatically select another PE (if one exists) under that pool and
PE. In other words, ASAP is capable of transparent fail-over amongst attempt to deliver the message to that PE. In other words, ASAP is
instances of a server pool. capable of transparent fail-over amongst PE instances within a server
pool.
ASAP uses the Endpoint Handlespace Redundancy Protocol (ENRP) to ASAP depends on ENRP which provides a high availability pool handle
provide a high availability pool handle space. ASAP is responsible space. ASAP is responsible for the abstraction of the underlying
for the abstraction of the underlying transport technologies, load transport technologies, load distribution management, fault
distribution management, fault management, as well as the management, as well as presentation to the upper layer (aka an ASAP
presentation to the upper layer (i.e., the ASAP user) a unified user) via a unified primitive interface.
primitive interface.
When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by the can seamlessly incorporate the link-layer redundancy provided by
SCTP. SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high availability
server pool. ASAP depends on the services of a high availability server pool.
pool handle database a.k.a. ENRP [7].
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 PU that uses ASAP.
Operational scope: See [6];
Operational scope: See [6];
Pool (or server pool): See [6]; Operational scope: The part of the network visible to pool users by
a specific instance of the reliable server pooling protocols.
Pool handle: See [6]; Pool (or server pool): A collection of servers providing the same
application functionality.
Pool element (PE): See [6]; Pool handle: A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a unique
pool handle.
Pool user (PU): See [6]; Pool element: A server entity having registered to a pool.
Pool element handle: See [6]; Pool user: A server pool user.
ENRP handlespace (or handlespace): See [6]; Pool element handle (or endpoint handle): A logical pointer to a
particular pool element in a pool, consisting of the pool handle
and a destination transport address of the pool element.
pool registrar: A server program running on a host that manages the Handle space: A cohesive structure of pool handles and relations
handle space collectively with its peer ENRP servers and replies that may be queried by an internal or external agent.
to the service requests from any Pool User or Pool Element.
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
belongs. A PE MUST only have one home ENRP server at any given sends all namespace service requests. A PE MUST only have one
time and both the PE and its home ENRP server MUST keep track of home ENRP server at any given time and both the PE and its home
this master/slave relationship between them. A PU SHOULD select ENRP server MUST know and keep track of this relationship. A PU
one of the available ENRP servers as its home ENRP server, but the SHOULD select one of the available ENRP servers as its Home ENRP
ENRP server does not need to know, nor does it need to keep track server but the collective ENRP servers may change this by the
of this relationship. sending or a 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 (either a PE or PU) requests ENRP handlespace service. The User sends all namespace service requests. The client channel is
client channel is usually defined by the transport address of the usually defined by the transport address of the Home ENRP server
home server and a well known port number. The channel MAY make and a well known port number. The channel MAY make use of
use of multi-cast 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, a.k.a 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. Organization of this document
Section 2 details ASAP message formats. In Section 3 we give the Section 2 details the ASAP message formats. Section 3 details the
detailed ASAP procedures for the ASAP implementer. And in Section 4 ASAP procedures for an ASAP implementor. Section 4 illustrate
we give the details of the ASAP interface, focusing on the details of the ASAP interface, focusing on the communication
communication primitives between the applications above ASAP and ASAP primitives employed between ASAP itself and the applications that
itself, and the communications primitives between ASAP and SCTP (or leverage ASAP, and the communications primitives between ASAP and
other transport layer). Also included in this discussion is relevant SCTP (or another transport layer). Also included in this discussion
timers and configurable parameters as appropriate. Section 5 are relevant timers and configurable parameters as appropriate.
provides threshold and protocol variables. Section 5 provides threshold and protocol variables.
1.3. Scope of ASAP 1.3. 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 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 will NOT share building a mechanism to share state but ASAP in itself will NOT share
any state. any state.
1.3.1. Extent of the Handlespace 1.3.1. Extent of the Handlespace
The scope of the 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. We propose a neither hierarchical nor arbitrarily large like DNS. A flat peer-to-
flat peer-to-peer model. Pools of servers will exist in different peer model is detailed. Pools of servers will exist in different
administrative domains. For example, suppose we want to use ASAP/ administrative domains. For example, suppose the use of ASAP and
ENRP. First, the PU may use DNS to contact an ENRP server. Suppose ENRP is wanted. First, the PU may use DNS to contact an ENRP server.
a PU in North America wishes to contact the server pool in Japan Suppose a PU in North America wishes to contact a server pool in
instead of North America. The PU would use DNS to get the list of IP Japan instead of North America. The PU would use DNS to get the list
addresses of the Japanese server pool domain, that is, the ENRP of IP addresses of the Japanese server pool, that is, the ENRP client
client channel in Japan. From there the PU would query the ENRP channel in Japan. From there the PU would query the Home ENRP server
server and then directly contact the PE(s) of interest. it established and then directly contact the PE(s) of interest.
1.4. Conventions 1.4. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
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 octets, a number in a pair of parentheses may follow bigger than 4 bytes, a number in a pair of parentheses may follow the
the field name to indicate the length of the field in number of field name to indicate the length of the field in number of bytes.
octets.
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
ENRP-ASAP [5]. Note also that ALL ASAP messages exchanged between an ENRP-ASAP [7]. Note also that ALL ASAP messages exchanged between an
ENRP server and a PE MUST use SCTP as transport, while ASAP messages ENRP server and a PE MUST use SCTP as transport, while ASAP messages
exchanged between an ENRP server and a PU MUST use either SCTP or TCP exchanged between an ENRP server and a PU MUST use either SCTP or TCP
as transport. PE to PU data traffic MAY use any transport protocol as transport. PE to PU data traffic MAY use 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 ENRP-ASAP [5]. The parameter descriptions may also be found in of ENRP-ASAP [7]. The parameter descriptions can be found in Section
Section 3 of ENRP-ASAP [5]. 3 of ENRP-ASAP [7].
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
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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
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
either create a new pool or to add itself to an existing pool. The
PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle
parameter and the Pool Element parameter. The Pool Handle parameter
specifies the name to be registered. The Pool Element parameter MUST
be filled in by the registrant as outlined in Section 3.1. Note that
the PE sending the registration message MUST send the message using
an SCTP association. Furthermore the IP address(es) of the PE that
is registered within the Pool Element parameter MUST be a subset of
the IP address(es) used in the SCTP association regardless of the
registered transport protocol
0 1 2 3 0 1 2 3
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the handle to be Pool Handle Parameter:
registered. The PE Parameter field MUST be filled in by the
registrant endpoint to declare its transport address, server pooling See [7] section 3.7
policy and value, and other operational preferences. Note that the
ASAP_REGISTRATION message MUST use SCTP and the IP address(es) of the Pool Element Parameter:
PE registered within the Pool Element Parameter MUST be a subset of
the addresses of the SCTP association in respective of the transport See [7] section 3.8
protocol registered by the PE.
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
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
The PE sending the ASAP_DEREGISTRATION shall fill in the pool handle Pool Handle Parameter:
See [7] section 3.7
PE Identifier Parameter:
See [7] section 3.12
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 deregistration is NOT
allowed by proxy, in other words a PE may only deregister itself. allowed by proxy, in other words a PE may only deregister 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
Home ENRP Server to the PE that sent a 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', indicate that the ENRP server that sent this message When set to '1', this flag indicates that the ENRP server sending
has rejected the registration. Otherwise, the registration is this message has rejected the registration. Otherwise when this flag
granted. is set to '0', this indicates the registration has been granted.
Operational Error Pool Handle Parameter:
This optional TLV parameter may be included if the registration was See [7] section 3.7.
rejected. This TLV, if present, indicates the cause of the
rejection. If the registration was successful this parameter is not PE Identifier Parameter:
included.
See [7] section 3.12
Operational Error Parameter (optional):
See [7] section 3.10
This parameter is included if an error or some atypical events
occurred during the registration process. When the R flag is set to
'1', this parameter, if present, indicates the cause of the
rejection. When the R flag is set to '0', this parameter, if
present, serves as a warning to the registering PE, informing it that
some of its registration values may have been modified by the ENRP
server. If the registration was successful and there is no warning,
this parameter is not included.
2.2.4. ASAP_DEREGISTRATION_RESPONSE message 2.2.4. ASAP_DEREGISTRATION_RESPONSE message
The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP
Server to a PE in response to a ASAP_DEREGISTRATION message or due to
the expiration of the registration life of the PE in the pool
0 1 2 3 0 1 2 3
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Pool Handle Parameter:
This optional TLV parameter is included if an error occurred during See [7] section 3.7.
the deregistration process. If the deregistration was successful
this parameter is not included. PE Identifier Parameter:
See [7] section 3.12.
Operational Error:
See [7] section 3.10.
This parameter is included if an error or some atypical events
occurred during the deregistration process. If the deregistration
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
its Home ENRP Server to resolve a pool handle into a list of pool
elements that are members of the pool indicated by the pool handle.
0 1 2 3 0 1 2 3
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|0| Message Length | | Type = 0x05 |0|0|0|0|0|0|0|S| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server to request translation of the The 'S' bit:
Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used. The 'S' bit, if set to '1', requests the Home ENRP server to send
updates to this Pool dynamically when the Pool changes. Dynamic
updates to the pool will consist of additional
ASAP_HANDLE_RESOLUTION_RESPONSE messages, without the user needing to
send in a ASAP_HANDLE_RESOLUTION.
If the 'S' bit is set to '0' no dynamic updates are requested.
Note that if a new Home ENRP server is adopted any 'dynamic update
request' will need to be resent to the new Home ENPR server if the
endpoint would like to continue to recieve updates. In other words,
the ENRP servers do NOT share state regarding which of its PU's are
requesting automatic update of state. Thus upon change of Home ENRP
Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message
with the 'S' bit set to 1. Note also, that the 'S' bit will only
cause dynamic update of a Pool when the Pool exists. If a negative
response is returned, no further updates to the Pool (when it is
created) will occur.
Pool Handle parameter:
See [7] section 3.7.
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 Home ENRP server of the PU or PE that sent a
ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if
the PU as 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|0| 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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Overall PE Selection Policy: A bit:
This TLV is a PE selection policy parameter and can be present when This bit is set to '1' if the ENRP server accepts the request to send
the response is positive. It indicates the overall selection policy automatic updates (i.e. the S bit was set on the request). If this
of the pool. If not present, round-robin is assumed. This TLV is bit is set to '0' either the ENRP server does NOT support automatic
not present when the response is negative (i.e., a rejection). update, it has resource issues and cannot supply this feature or the
user did not request it.
Note, any load policy parameter inside the Pool Element Parameter (if Pool Handle parameter:
See [7] section 3.7.
Overall PE Selection Policy (optional):
See [7] section 3.6.
This parameter can be present when the response is positive. If
present, it indicates the overall pool member selection policy of the
pool. If not present, a round robin overall pool member selection
policy is assumed. This parameter is not present when the response
is negative.
Note, any load policy parameter within a Pool Element Parameter (if
present) MUST be ignored, and MUST NOT be used to determine the present) MUST be ignored, and MUST NOT be used to determine the
overall pool policy. overall pool member selection policy.
Pool Element Parameters Pool Element Parameters (optional):
When the response is positive, an array of PE TLVs are included,
indicating the current PEs and their information in the named pool.
In a positive response, at least one PE TLV MUST be present. When
the response is negative, no PE TLVs are included.
Operational Error See [7] section 3.10.
The presence of this TLV indicates that the response is negative When the response is positive, an array of PE parameters are
(i.e., the handle resolution request was rejected by the ENRP included, indicating the current information about the PEs in the
server). The cause code in this TLV (if present) will indicate the named pool. At least one PE parameter MUST be present. When the
reason the handle resolution request was rejected (e.g., the response is negative, no PE parameters are included.
requested pool handle was not found).
Operational Error (optional):
See [7] section 3.10.
The presence of this parameter indicates that the response is
negative (the handle resolution request was rejected by the ENRP
server). The cause code in this parameter (if present) will indicate
the reason the handle resolution request was rejected (e.g., the
requested pool handle was not found). The absence of this parmaeter
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
PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the
PE is reachable and requires the PE to adopt the sending server as
its new Home ENRP Server if the H bit is set to 1. Regardless of the
setting of the H bit, an ASAP endpoint MUST respond with an
ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages
that arrive.
0 1 2 3 0 1 2 3
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', indicate that the ENRP server that sends this
message want to be the home ENRP server of the receiver of this message want to be the home ENRP server of the receiver of this
message. message.
Server Identifier field indicates the sender ENRP server of the Server Identifier: 32 bit (unsigned integer)
message.
This message is sent to a PE by the ENRP server as a "health" check. This is the ID of the ENRP server, as discussed in Section 3.2.1 of
If the transport level Heart Beat mechanism is insufficient, this ENRP [8].
adds heartbeat messages with the goal of determining health status at
ASAP level in a possibly more timely fashion. (The transport level
Heart Beat may sometimes be considered insufficient due to that time
outs are set for too long or heartbeats are not frequent enough, or,
that the transport level Heart Beat mechanism's coverage is limited
only to the transport level at the two ends.)
Using ASAP keepalive also has additional value to the reliability of Pool Handle parameter:
fault detection when SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity See [7] section 3.7.
between the two SCTP stacks, ASAP keepalive monitors the end-to-end
liveliness of the ASAP layer above it.
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
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by the PE to the ENRP server as an Pool Handle parameter:
acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message.
See [7] section 3.7.
PE Identifier parameter:
See [7] section 3.12.
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
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PE or PU will send this message to an ENRP server to report the Pool Handle parameter:
unreachability of the specified PE.
See [7] section 3.7.
PE Identifier parameter:
See [7] section 3.12.
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
PUs and PEs know the transport information necessary to connect to
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 :
skipping to change at page 14, line 4 skipping to change at page 16, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #1 : : Transport param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #2 : : Transport param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ..... : : ..... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n : : Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by an ENRP server such that PUs and PEs know the Server Identifier: 32 bit (unsigned integer)
transport layer information necessary to connect to the ENRP server.
The transport parameters are optional and only TCP and SCTP transport
parameters are allowed. Server Identifier field indicates the sender
ENRP server of the message.
2.2.11. COOKIE message This is the ID of the ENRP server, as discussed in Section 3.2.1 in
ENRP [8].
Transport parameters (optional):
See [7] seections 3.3 and 3.4 for the SCTP and TCP Transport
parameters respectively.
Only SCTP and TCP Transport parameters are allowed for use within the
SERVER_ANNOUNCE message.
2.2.11. ASAP_COOKIE message
The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to
convey information it wishes to share using a control channel.
0 1 2 3 0 1 2 3
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by a PE to a PU. It may only be sent when a Cookie Parameter :
control channel exists between the PE and PU.
See [7] section 3.11.
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
detects a failure with the current PE to aid in failover. The Cookie
Parameter sent by the PE is the latest one received from the failed
PE.
0 1 2 3 0 1 2 3
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by a PU to a PE in case of a failover. The Cookie Parameter:
Cookie Parameter is one received latest from the failed PE.
2.2.13. BUSINESS_CARD message See [7] section 3.11.
This message is sent by a PU to a PE or from a PE to a PU. This 2.2.13. ASAP_BUSINESS_CARD message
parameter MUST NOT be sent if a control channel does NOT exists
between the PE and PU. The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE
to a PU using a control channel to convey the pool handle and a
preferred failover ordering.
0 1 2 3 0 1 2 3
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender of this message lists both the Pool that the sender Pool Handle parameter:
belongs to and a preferred list of failover candidates.
See [7] section 3.7.
Pool Element parameters:
See [7] section 3.8.
2.2.14. ASAP_ERROR message 2.2.14. ASAP_ERROR message
This message is used to report an operational error. Currently the The ASAP_ERROR message is sent in response by an ASAP endpoint
use of this message is undefined, it is reserved for future use receiving an unknown message or an unknown parameter to the sending
[Editors Note: we need to come up with concrete uses or get rid of ASAP endpoint to report the problem or issue.
the 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 = 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:
See [7] section 3.10
When an ASAP endpoint receives an ASAP message with an unknown
message type or a message of known type that contains an unknown
parameter, it SHOULD handle the unknown message or the unknown
parameter according to the unrecognized message and parameter
handling rules defined in Section 3.
According to the rules, if an error report to the message sender is
needed, the ASAP endpoint that discovered the error SHOULD send back
an ASAP_ERROR message which includes an Operation Error parameter
with the proper cause code, cause length, and case specific
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. failure detection and management are also discussed. Also please
note that ASAP messages, sent between a PE and PU are identified by
an SCTP Payload Protocol Identifier (PPID) (or equivilant mapped
function if using TCP).
3.1. Registration 3.1. Registration
When a PE wishes to join its server pool it MUST use the procedures When a PE wishes to initiate or join a server pool it MUST use the
outlined in this section to register. Often the registration will be procedures outlined in this section for registration. Often, the
triggered by a user request primitive (discussed in Section 4.1). registration will be triggered by a user request primitive (discussed
The ASAP endpoint MUST register using an SCTP association between the in Section 4.1). The PE MUST register using an SCTP association
ASAP endpoint and the ENRP server. If the ASAP endpoint has not established between itself and the Home ENRP server. If the PE has
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 to establish its Home ENRP server. specified in Section 3.6.
Once the 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 SCTP endpoint used to communicate with the ENRP server MUST R1) The PE's SCTP endpoint used to communicate with the Home ENRP
be bound to all IP addresses that will be used by the PE server MUST be bound to all IP addresses that will be used by the
(irregardless of what protocol will be used to service user PE (irregardless of what transport protocol will be used to
requests to the PE). service user requests to the PE).
R2) The ASAP endpoint MUST formulate an ASAP_REGISTRATION message as R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION
defined in Section 2.2.1 In formulating the message the ASAP message as defined in Section 2.2.1. In formulating the message,
endpoint MUST: the PE MUST:
R2.1) Fill in the Pool Handle to specify which server pool the R2.1) Fill in the Pool Handle Parameter to specify which server
ASAP endpoint wishes to join. pool the ASAP endpoint wishes to join.
R2.2) Fill in a PE identifier using a good quality randomly R2.2) Fill in the PE identifier using a good quality randomly
generated number (RFC1750 [10] provides some information on generated number (RFC1750 [10] provides some information on
randomness guidelines). randomness guidelines).
R2.3) Fill in the registration life time parameter with the number R2.3) Fill in the Registration Life time parameter with the
of seconds that this registration is good for. Note a PE that number of seconds that this registration is valid for. Note a
wishes to continue service MUST re-register after the PE that wishes to continue service MUST re-register after the
registration expires. registration expires.
R2.4) Fill in a User Transport Parameter for the type of transport R2.4) Fill in a User Transport Parameter to specify the type of
and the data/control channel usage the PE is willing to transport and the data/control channel usage the PE is willing
support. Note, to join an existing server pool, the PE MUST to support. Note, in joining an existing server pool, the PE
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 Member selection policy. R2.5) Fill in the preferred Pool Member Selection Policy
parameter.
R2.6) PE does not need to fill in the ASAP transport parameter.
The ASAP transport TLV will be filled in and used by the home
ENRP server.
R3) Send the Registration request to the Home ENRP server using SCTP. R3) Send the Registration message to the Home ENRP server using
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
parameter. The ASAP transport parameter will be filled in and used
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 ASAP endpoint shall start the received from the SCTP layer, the PE shall start the Server Hunt
Server Hunt procedure (see Section 3.6) in an attempt to get service procedure (see Section 3.6) in an attempt to get service from a
from a different ENRP server. After establishing a new Home ENRP different ENRP server. After establishing a new Home ENRP server the
server the ASAP endpoint SHOULD restart the registration procedure. PE SHOULD restart the registration procedure.
At the reception of the registration response, the ASAP endpoint MUST At the reception of the registration response, the PE MUST stop the
stop the T2-Registration timer. If the response indicated success, T2-Registration timer. If the response indicates success, the PE is
then the PE is now registered and will be considered an available registered and will be considered an available member of the server
member of the server pool. If the registration response indicates a pool. If the registration response indicates a failure, the PE must
failure, the ASAP endpoint must either re-attempt registration after either re-attempt registration after correcting the error or return a
correcting the error or return a failure indication to the ASAP failure indication to the PE's upper layer. The PE MUST NOT re-
endpoints upper layer. The ASAP endpoint MUST NOT re-attempt attempt registration without correcting the error condition.
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-reregistration
timer. 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 attempts it makes in a local variable. If repeated registration (and reregistration) attempts it makes in a local
registration time-outs or failures occurs and the local count exceeds variable that gets set to zero before the initial registration
the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the attempt to the Home ENRP server or after a successful re-
error to its upper layer and stop attempting registration. registration.If repeated registration time-outs or failures occurs
and the local count exceeds the Threshold 'MAX-REG-ATTEMPT' the
implementation SHOULD report the error to its upper layer and stop
attempting registration.
3.2. Deregistration 3.2. Deregistration
In the event the PE wishes to deregister from its server pool In the event a PE wishes to deregister from its server pool (normally
(normally via an upper layer requests see Section 4.2) it SHOULD use via an upper layer requests see Section 4.2), it SHOULD use the
the following procedures. Note that an alternate method of following procedure. It should be noted that an alternate method of
deregistration is to NOT re-register and to allow the registration deregistration is to NOT re-register and to allow the registration
lift time to expire. life of the PE to expire. In this case a
ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP
endpoint to indicate the removal of the PE from the pool it
registered.
When deregistering the PE SHOULD use the same SCTP association with When deregistering the PE SHOULD use the SCTP association that was
its Home ENRP server that was used for registration. To deregister used for registration with its Home ENRP server. To deregister, the
the 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. The identifier MUST be the same one D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION
used during registration. message. The identifier MUST be the same as used during
registration. The use of the same Pool Handle and Pool Identifier
parameters used in registration allows the identity of the PE ASAP
endpoint be verified before deregisteration 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 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 an If the T3-Deregistration timer expires before receiving either a
ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification
received from the SCTP layer, the ASAP endpoint shall start the from the PE's SCTP endpint, the PE's ASAP endpoint shall start the
Server Hunt procedure (see Section 3.6) in an attempt to get service ENRP Server Hunt procedure (see Section 3.6) in an attempt to get
from a different 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 procedure. server, the ASAP endpoint SHOULD restart the deregistration
procedure.
At the reception of the deregistration response, the ASAP endpoint At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP
MUST stop the T3-deregistration timer. endpoint MUST stop the T3-deregistration timer.
Note that after a successful deregistration the PE MAY still receive It should be noted that after a successful deregistration the PE MAY
requests for some period of time. The PE MAY wish to still remain still receive requests for some period of time. The PE MAY wish to
active and service these requests or may wish to ignore these remain active and service these requests or to exit and ignore these
requests and exit. requests.
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 Endpoint sends to a Pool handle ( Section 4.5.1) or will occur when a ASAP Endpoint sends to a Pool handle (
requests a cache population (Section 4.3) but may occur for other Section 4.5.1) to its home ENRP server or requests a cache population
reasons (e.g. the internal ASAP PE wishes to know its peers for (Section 4.3). It may also occur for other reasons (e.g. the
sending a message to all of them). When an Endpoint (PE or PU) internal ASAP PE wishes to know its peers for sending a message to
wishes to resolve a pool handle it MUST take the following actions: all of them). When an ASAP Endpoint (PE or PU) wishes to resolve a
pool handle to a list of accesible transport addresses of the member
PEs of the pool, it MUST 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 ENRP
Server Hunt procedures specified in Section 3.6 to obtain one. Server Hunt procedures specified in Section 3.6 to obtain one.
Otherwise proceed to step NR3. Otherwise, proceed to step NR3.
NR3) Send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server NR3) If a PE, send the ASAP_HANDLE_RESOLUTION message to the home
using SCTP. ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION
message to the Home ENRP server using either TCP or SCTP. If sent
from a PE, the SCTP association used for registration SHOULD be
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 layer, the ASAP endpoint SHOULD start the Server Hunt procedure SCTP or TCP layer, the ASAP endpoint SHOULD start the Server Hunt
(see Section 3.6) in an attempt to get service from a different ENRP procedure (see Section 3.6) in an attempt to get service from a
server. After establishing a new Home ENRP server the ASAP endpoint different ENRP server. After establishing a new Home ENRP server,
SHOULD restart the handle resolution procedure. the ASAP endpoint SHOULD restart the handle resolution procedure.
At the reception of the response message (i.e., an At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message the
ASAP_HANDLE_RESOLUTION_RESPONSE) the endpoint MUST stop its T1- ASAP endpoint MUST stop its T1-ENRPrequest timer. After stopping the
ENRPrequest timer. After stopping the T1 timer the endpoint SHOULD T1-ENRPrequest timer the ASAP endpoint SHOULD process the message as
process the pool handle response as appropriate (e.g. populate a appropriate (e.g. populate a local cache, give the response to the
local cache, give the response to the ASAP user, and/or use the ASAP user, and/or use the response to send the ASAP users message).
response to send the ASAP users 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 made. If such a cache is used it SHOULD: of handle resolutions sent. If a cache is used, it SHOULD:
C1) Be consulted before requesting a handle resolution. C1) Be consulted before sending a handle resolution.
C2) Have a stale timeout time associated with the cache so that even C2) Have a stale timeout timer associated with the cache. If the
in the event of a cache-hit, if the cache is "stale" it will cause cache is determined to be stale upon a cache hit, a handle
a new handle resolution to be issued to update the cache. resolution message SHOULD be sent so the cache can be updated.
C3) In the case of a "stale" cache the implementation may in parallel C3) In the case of a stale cache the implementation may in parallel
request an update and answer the request or block the user and update the cache and answer the request or it may block the user
wait for an updated cache before proceeding with the users and wait for an updated cache before proceeding with the users
request. request.
C4) If the cache is NOT stale, the endpoint SHOULD NOT make a handle C4) If the cache is NOT stale, the endpoint SHOULD NOT send a handle
resolution request but instead use the entry from the cache. resolution request but instead SHOULD use the entry from the
cache.
3.4. Endpoint keep alive 3.4. Endpoint keep alive
Periodically an ENRP server may choose to "audit" a PE. It does this The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a
by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). PE in order to verify it is reachable. If the transport level heart
Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message the following beat mechanism is insufficient, this message can be used in a heart
beat mechanism for the ASAP level whose goal is determining the
health status of the ASAP level in a timely fashion. (The transport
level heart beat mechanism may be insufficient due to either the time
outs or the heart beat interval being set too long, or, that the
transport level heart beat mechanism's coverage is limited only to
the transport level at the two ends.) Additionally, the
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,
while SCTP level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, the ASAP level heartbeat monitors the
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 ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below.
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. If the the Pool Handle sent in its earlier ASAP_REGISTRATION message. If
Pool Handle does not match silently discard the message. the Pool Handle does not match, the PE MUST silently discard the
message.
KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as
follows:
KA2.1) Filling 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 that was used with this PE for KA2.2) Fill in the PE Identifier parameter using the PE
registration. identifier used by this PE for registration.
KA2.3) Send off 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 that ENRP server. appropriate SCTP association for the ENRP server which sent the
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, adopt the sender of the 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
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. Reporting unreachable endpoints 3.5. Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable. Occasionally, an ASAP endpoint may realize a PE is unreachable. This
This may occur by a specific SCTP error realized by the ASAP endpoint may occur by a specific SCTP error realized by the ASAP endpoint or
or via an ASAP user report via the Transport.Failure Primitive via an ASAP user report via the Transport.Failure Primitive
(Section 4.9.2). In either case the ASAP endpoint SHOULD report the (Section 4.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 its home ENRP server. The Endpoint should fill in the message to its Home ENRP server. Before sending the
Pool Handle and PE identifier of the unreachable endpoint. If the ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in
sender is a PE the message MUST be sent via SCTP to the Endpoints the Pool Handle parameter and PE identifier parameter of the
Home ENRP server. Note: an ASAP endpoint MUST report No more than unreachable endpoint. If the sender is a PE, the message MUST be
once each time it encounters such an event. sent via SCTP. It should be noted that an ASAP endpoint MUST report
no more than once each time it encounters such an event.
Note: when processing a Transport.Failure Primitive (Section 4.9.2) Additionally, when processing a Transport.Failure Primitive
the ASAP endpoint MUST NOT send a unreachable report unless the ASAP (Section 4.9.2) the ASAP endpoint MUST NOT send an
endpoint has sent at least one message to the PE specified by the ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous
primitive. request to send data to the PE specified by the primitive.
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.
If the multicast capabilities are used an ENRP server MUST send If multicast capabilities are used within the operational scope an
periodically every T6-Serverannounce an ASAP_SERVER_ANNOUNCE message ENRP server MUST send periodically every T6-Serverannounce an
(Section 2.2.10) including all the transport addresses available for ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the
ASAP communication to the multicast channel. transport addresses available for ASAP communication on the multicast
ENRP client channel.
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 address in its list of ENRP SHOULD insert all new included transport addresses into its list of
server addresses and start a T7-ENRPoutdate timer for each address. ENRP server addresses and start a T7-ENRPoutdate timer for each
For all already known addresses the T7-ENRPoutdate timers MUST be address. For all already known included transport addresses, the T7-
restarted. If no transport parameters are included in the ENRPoutdate timer MUST be restarted for each address. If no
ASAP_SERVER_ANNOUNCE message the source IP address and the IANA transport parameters are included in the ASAP_SERVER_ANNOUNCE
registered ASAP port number are used instead. It is also assumed message, the SCTP transport protocol is assumed to be used and the
that the transport protocol used is SCTP. If a T7-ENRP timer for a source IP address and the IANA registered ASAP port number is used
transport address expires the corresponding address is deleted from for communication with the ENRP server. If a T7-ENRPoutdate timer
the list of transport addresses. for a transport address expires, the corresponding address is deleted
from the managed list of transport addresses of the PU or PE.
If no multicast capabilities are used each PU and PE MUST have a If multicast capabilities are not used within the operational scope,
configured list of transport addresses of ENRP servers. each PU and PE MUST have a configured list of transport addresses of
ENRP servers.
At its startup, or when it fails to send to (i.e., timed-out on a At its startup or when it fails to communicate with its home ENRP
service request) with its current home ENRP server, a PE or PU shall server (i.e., timed-out on a ENRP request), a PE or PU MUST establish
establish its Home ENRP server, i.e. setup a TCP connection or SCTP a new Home ENRP server (i.e. setup a TCP connection or SCTP
association with an ENRP server. association with a different ENRP server).
To establish a new association or connection the following rules MUST To establish a home ENRP server the following rules MUST be followed:
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 addresses. An connection with no more than three ENRP server's. An ASAP
endpoint MUST NOT try to establish more than three association or endpoint MUST NOT establish more than three associations or
connections at any single time. connections.
SH2) The endpoint shall start a T5-Serverhunt timer. SH2) The ASAP endpoint shall start a T5-Serverhunt timer.
SH3) If the endpoint establishes an association or connection it MUST SH3) If the ASAP endpoint establishes an association or connection
stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD
T5-Serverhunt value to its initial value and then proceed to step also reset the T5-Serverhunt timer to its initial value and then
SH6. proceed to step SH6.
SH4) If an association or connection establishment fails the endpoint SH4) If an association or connection establishment fails, the ASAP
SHOULD try to establish an association or connection by using a endpoint SHOULD try to establish an association or connection
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 endpoint MUST double the value of the T5-Serverhunt SH5.1) The ASAP endpoint MUST double the value of the T5-
timer. Serverhunt timer. Note that this doubling is capped at the
value RETRAN.max
SH5.2) The endpoint SHOULD stop the establishment of associations SH5.2) The ASAP endpoint SHOULD stop the establishment of
and connections. associations and connections with the transport addresses
selected in step SH1.
SH5.2) The 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 to attempt to select a different set of transport addresses with
connect to. which to connect.
SH6) The PE or PU shall pick one of the ENRP servers that it was able SH6) The PE or PU shall pick one of the ENRP servers with which it
to establish an association or connection with, and send all its was able to establish an association or connection, and send all
subsequent the handlespace service requests to this new home ENRP subsequent ENRP request messages to this new Home ENRP server.
server.
3.7. Handle ASAP to ENRP Communication Failures 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures
Three types of failure may occur when the ASAP endpoint at an Three types of failure may occur when the ASAP endpoint at ether PE
endpoint tries to communicate with the ENRP server: 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
Registration failure is discussed in Section 3.1
3.7.1. SCTP Send Failure 3.7.1. SCTP Send Failure
This indicates that the SCTP layer failed to deliver a message sent This communication failure indicates that the SCTP layer was uanble
to the ENRP server. In other words, the ENRP server is currently to deliver a message sent to an ENRP server. In other words, the
unreachable. ENRP server is unreachable.
In such a case, the ASAP endpoint should not re-send the failed In such a case, the ASAP endpoint should not re-send the
message. Instead, it should discard the failed message and start the undeliverable message. Instead, it should discard the message and
ENRP server hunt procedure as described in Section 3.6 start the ENRP server hunt procedure as described in Section 3.6 .
After finding a new Home ENRP server, the ASAP endpoint should
reconstruct and retransmit the request.
Note that an ASAP endpoint MAY also choose to NOT discard the
message, but to queue it for retransmission after a new Home ENRP
server is found. If an ASAP endpoint does choose to discard the
message, after a new Home ENRP server is found, the ASAP endpoint
MUST be capable of reconstructing the original request.
3.7.2. T1-ENRPrequest Timer Expiration 3.7.2. T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the When the T1-ENRPrequest timer expires, the ASAP endpoint should
original request to the ENRP server and re-start the T1-ENRPrequest resend the original request to the ENRP server and restart the T1-
timer. In parallel, the server hunt procedure should be started as ENRPrequest timer. In parallel, the ASAP endpoint should begin the
outlined 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 timer ASAP user and the ENRP request message associated with the T1-
should be discarded. Note that if an alternate ENRP server responds ENRPrequest timer should be discarded. It should be noted that if an
the ASAP endpoint SHOULD adopt the responding ENRP server as its new alternate ENRP server responds the ASAP endpoint SHOULD adopt the
"home" server and resend the request to the new "home" server. responding ENRP server as its new Home ENRP server and resend the
request to the new Home ENRP server.
3.7.3. Registration Failure
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 the PU via the control channel. The ASAP ASAP_COOKIE message to a PU via the control channel. The PU's ASAP
layer at the PU stores the Cookie parameter and discards an older one endpoint stores the Cookie parameter and discards an older cookie if
if it is present. it is previously stored.
If the ASAP layer detects a failure and initiates a failover to a Note: a control channel is a communication channel between a PU and
different PE, the ASAP layer sends the last received Cookie parameter PE that does not end in data passed to the user. This is
in an ASAP_COOKIE_ECHO message to the new PE. The upper layer may be accomplished with SCTP by using a PPID to seperate the ASAP messages
involved in the failover procedure. (Cookie and Business Card) from normal data messages.
This cookie mechanism can be used as a simple method for state If the PU's ASAP endpoint detects a failure and initiates a failover
sharing. Therefore a cookie should be signed by the sending PE and to a different PE, it SHOULD send the lastest received cookie
this should be verified by the receiving PE. The details of this are parameter in an ASAP_COOKIE_ECHO message to the new PE. Upper layers
out of scope of this document. It is only important that the PU may be involved in the failover procedure.
stores always the last received Cookie Parameter and sends that back
unmodified in case of a PE failure. The cookie handling procedure can be used for state sharing.
Therefore a cookie should be signed by the sending PE ASAP endpoint
and the cookie should be verified by the receiving PE's ASAP
endpoint. The details of the verification procedure are out of scope
for this document. It is only important that the PU always stores
the last received Cookie Parameter and sends that back unmodified in
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 (i.e. the first When communication begins between a PU and a PE either of which could
message is sent from the PU to the PE) the ASAP layer in the PU be part of a PU/PE combination (i.e. a message is sent between the
SHOULD send an ASAP_BUSINESS_CARD IF the sender is also registered as entities), a PE should always send a ASAP_BUSINESS_CARD message to a
a PE. A PE may also send back to a PU a business card as well. An PU. A PU should send a ASAP_BUSINESS_CARD message to a PE only if it
ASAP_BUSINESS_CARD MUST NOT be sent if a control channel does NOT is part of a PU/PE combination. A ASAP_BUSINESS_CARD message MUST
exist between the PU and PE. After communication as been established ONLY be sent if a control channel exists between a PU and PE. After
between a PE and PU at any time either entity may update its failover communication as been established between a PE and PU, a new
distribution by sending a new ASAP_BUSINESS_CARD. ASAP_BUSINESS_CARD message may be sent at any time by either entity
to update its failover order.
The business card serves two purposes (for both endpoints PU and PE). The ASAP_BUSINESS_CARD message serves two purposes. First it lists
First it lists the endpoints pool handle. For a PU contacting a PE the pool handle. For a PU which is part of a PU/PE combination which
this is essential so that the PE may also gain the full benefits of is contacting a PE this is essential so that the PE learns the pool
ASAP if the PU is also a PE. Secondly the business card tells the handle of the PU/PE combination requesting service. Secondly the
receiver a failover order that is recommended to follow. This may ASAP_BUSINESS_CARD message tells the receiving entity a failover
facilitate rendezvous between PE's as well as some control of load order that is recommended to follow. This should facilitate
redistribution upon the failure of any given PE. rendezvous between entities that have been working togehter as well
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 receiver SHOULD: the receiving ASAP endpoint SHOULD:
BC1) Unpack the ASAP_BUSINESS_CARD, and if no entry exists in the BC1) Unpack the message and if no entry exists in the translation
translation cache and one exists, populate the new Pool Handle cache of the receiving ASAP endpoint for the pool handle listed
into the cache and request a handle resolution of the pool handle. within the ASAP_BUSINESS_CARD message perform a
ASAP_HANDLE_RESOLUTION for that pool handle. If the translation
cache does hold an entry for the pool handle, then it may be
necessary to update the peer endpoint.
BC2) Create a list for this PE of preferred failover order so that in BC2) Unpack the message and populate a preferred list for failover
the event of a failure the preferred list will be used to guide order. If the peers PE should fail this preferred list will be
the ASAP endpoint in the selection of an alternate PE. used guide the ASAP endpoint in the selection of an alternate PE.
4. The ASAP Interfaces 4. 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 will notify the ASAP user. detection of certain events, the ASAP layer will notify the ASAP
user.
4.1. Registration.Request Primitive 4.1. Registration.Request Primitive
Format: registration.request(poolHandle, Format: registration.request(poolHandle,
User Transport parameter(s)) User Transport parameter(s))
The poolHandle parameter contains a NULL terminated ASCII string of The poolHandle 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) indicate
specific transport parameters and types to register with. If this specific transport parameters and types to register with. If this
optional parameter is left off, then the SCTP endpoint used to optional parameter is left off, then the SCTP endpoint used to
skipping to change at page 27, line 47 skipping to change at page 32, line 4
B) if multiple PEs exist in the pool, ASAP will choose one of them B) if multiple PEs exist in the pool, ASAP will choose one of them
and transmit the message to it. In that case, the choice of the and transmit the message to it. In that case, the choice of the
PE is made by ASAP endpoint of the sender based on the server PE is made by ASAP endpoint of the sender based on the server
pooling policy as discussed in Section 4.5.2 pooling policy as discussed in Section 4.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, ASAP will 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 the
SEND primitive in RFC2960 [4] would be used), and, SEND primitive in RFC2960 [4] 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 ENRP [7]. For more on the ENRP server request procedures see ENRP [8].
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 4.5.3). that same PE (see Section 4.5.3).
Section 3.7 defines the fail-over procedures for cases where the Section 3.7 defines the fail-over procedures for cases where the
selected PE is found unreachable. selected PE is found unreachable.
4.5.2. Pool Element Selection 4.5.2. Pool Element Selection
skipping to change at page 28, line 38 skipping to change at page 32, line 42
(see Section 4.5.5). (see Section 4.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).
Four basic server pooling policies are defined in ASAP, namely the One basic policy is defined in this document, others can be found in
Round Robin, Least Used, Least Used Degrading and Weighted Round [6]
Robin. The following sections describes each of these policies.
4.5.2.1. Round Robin Policy 4.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 MAY NOT send back all PEs to the ASAP server pool, the ENRP server MAY NOT send back all PEs to the ASAP
client. In this case the client or PU will be performing a round 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.
4.5.2.2. Least Used Policy
When the destination Pool is under the Least Used server pooling
policy, the ASAP endpoint of the message sender will select the PE
that has the lowest policy value in the group as the receiver of the
current message. If more than one PE from the group share the same
lowest policy value, the selection will be done round Robin amongst
those PEs.
It is important to note that this policy means that the same PE will
be always selected as the message receiver by the sender until the
load control information of the pool is updated and changed in the
local cache of the sender (via a cache update see Section 3.3).
4.5.2.3. Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception
that, each time the PE with the lowest policy value is selected from
the Pool as the receiver of the current message, its policy value is
incremented, and thus it may no longer be the lowest value in the
Pool.
This provides a degradation of the policy towards round Robin policy
over time. As with the Least Used policy, every local cache update
at the sender will bring the policy back to Least Used with
Degradation.
4.5.2.4. Weighted Round Robin Policy
[TBD]
4.5.3. Sending to a Pool Element Handle 4.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 the ASAP endpoint to 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 dependant 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 to communicate with. If no communication
state exists with the peer endpoint (and is required by the transport state exists with the peer endpoint (and is required by the transport
protocol) the ASAP endpoint MAY setup the needed state and then protocol) the ASAP endpoint MAY setup the needed state and then
invoke the SEND primitive for the particular transport protocol to invoke the SEND primitive for the particular transport protocol to
send the message to the PE. 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
skipping to change at page 32, line 5 skipping to change at page 35, line 26
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 senders ASAP endpoint to send a copy of the message to
all the PEs, except for the sender itself if the sender is a PE, 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 ASAP_SEND_TO_ALL option. It permits the senders ASAP
endpoint also deliver a copy of the message to itself if the endpoint 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 to ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer
send the current message using un-ordered delivery (note the to 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).
4.6. Data.Received Notification 4.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
skipping to change at page 34, line 6 skipping to change at page 37, line 37
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 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_REPONSE 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 send
out the queued "hello1" user message. out the queued "hello1" user message.
skipping to change at page 36, line 23 skipping to change at page 40, line 23
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 deregistration
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 ASAP handle space and is used to cause a re- registration into the ENRP handle space 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 Life Timer parameter
used in the registration request (whichever is less). used 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 120 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.
5.2. Variables 5.2. Variables
stale.cache.value - A threshold variable that indicates how long a stale.cache.value - A threshold variable that indicates how long a
cache entry is valid for. cache entry is valid for.
5.3. Thresholds 5.3. Thresholds
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. made before a server hunt is issued. The default value of this is
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. server hunt is issued. The default value for this is 2.
RETRAN-MAX - This value represents the maximum time between
registration attmempts and puts a ceiling on how far the
registration timer will back-off. The default value for this is
normally set to 60 seconds.
6. Security Considerations 6. Security Considerations
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [8] describes the threats to the Rserpool Response to Threats [9] describes the threats to the Rserpool
architecture in detail and lists the security requirements in architecture in detail and lists the security requirements in
response to each threat. From the threats described in this response to each threat. From the threats described in this
document, the security services required for the Rserpool protocol document, the security services required for the Rserpool protocol
are enumerated below. are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration 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
skipping to change at page 38, line 29 skipping to change at page 43, line 29
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)
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 existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports protocols to provide the security services required. TLS supports
all these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of minimum by implementors of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementors MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of ASAP Threat 8 requires the ASAP protocol to limit the number of ASAP
Endpoint_Unreachable messages (see Section 3.5) to the ENRP server. Endpoint_Unreachable messages (see Section 3.5) to the ENRP 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 to the PE (see section x.y??? in ASAP_ENDPOINT_KEEP_ALIVE messages to the PE (see section x.y??? in
[7]). [8]).
6.1. Implementing Security Mechanisms 6.1. Chain of trust
Security is mandatory to implement in Rserpool and is based on TLS
implementation in all three architecture components that comprise
Rserpool -- namely PU, PE and ENRP server.
Here is a description of all possible data paths and a description of
the security.
PU <---> ENRP Server (authentication of ENRP server; queries over
TLS)
PE <----> ENRP servers (mutual authentication; registration/
deregistration over TLS)
ENRP <----> ENRP servers (mutual authentication; database updates
using TLS)
If all components of the system are secured and authenticated, the
chain of trust is sound. The root of the trust chain is the ENRP
server. If that is secured, then security will be enforced for all
components that try to connect to it.
Summary of interaction between secured and unsecured components: If
the PE is not secure and tries to register with a secure ENRP server,
the registration will be rejected. If an insecure ENRP server tries
to update the database of an ENRP server, then the update will be
rejected. If an insecure PU communicates with an ENRP server, it
will get a response with the understanding that the response is not
secured.
**** The final case is the PU sending a secured request to ENRP. It
might be that ENRP and PEs are not secured and that is OK. The
intent may be to secure the communication over the internet. ****
Summary:
Unsecured architecture components can all communicate with each other
thus establishing a chain of trust. Secured PE and ENRP components
reject any communications with unsecured ENRP and PE components.
If the above is enforced, then a chain of trust is established for
the Rserpool user.
6.2. Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that well-known distributors of site certificates comparable to those that
issue root certificates for web browsers). issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436 Implementations MUST support TLS with SCTP as described in RFC3436
[9] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP [5] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that we 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 are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
7. Acknowledgments 7. 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
skipping to change at page 41, line 22 skipping to change at page 47, line 22
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Server Access Protocol (ASAP) and Endpoint Handlespace Security over Stream Control Transmission Protocol", RFC 3436,
Redundancy Protocol (ENRP) Parameters", December 2002.
draft-ietf-rserpool-common-param-09 (work in progress),
July 2005.
[6] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and [6] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",
A. Silverton, "Architecture for Reliable Server Pooling", draft-ietf-rserpool-policies-03 (work in progress),
draft-ietf-rserpool-arch-10 (work in progress), July 2005. September 2006.
[7] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. [7] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-enrp-12 (work in progress), July 2005. draft-ietf-rserpool-common-param-10 (work in progress),
February 2006.
[8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. [8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
Holdrege, "Threats Introduced by Rserpool and Requirements for draft-ietf-rserpool-enrp-13 (work in progress), February 2006.
Security in Response to Threats", draft-ietf-rserpool-threats-05
(work in progress), July 2005.
[9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", [9] Stillman, M., "Threats Introduced by Rserpool and Requirements
RFC 3436, December 2002. for Security in response to Threats",
draft-ietf-rserpool-threats-05 (work in progress), July 2005.
8.2. Informational References (non-normative) 8.2. Informational References (non-normative)
[10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 43, line 5 skipping to change at page 49, line 5
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 43, line 29 skipping to change at page 49, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 175 change blocks. 
533 lines changed or deleted 778 lines changed or added

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