draft-ietf-rserpool-asap-12.txt   draft-ietf-rserpool-asap-13.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: January 19, 2006 Q. Xie Expires: August 11, 2006 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
July 18, 2005 February 7, 2006
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-12.txt draft-ietf-rserpool-asap-13.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 January 19, 2006. This Internet-Draft will expire on August 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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) [7] 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.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
PE's and ENRP servers MUST use SCTP. PE's and ENRP servers MUST use SCTP.
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
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . 10
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 . . . . . . . 11
2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12
2.2.8 ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13
2.2.9 ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13
2.2.10 ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . 13 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 13
2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14 2.2.11. COOKIE message . . . . . . . . . . . . . . . . . . . . 14
2.2.12 ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . 14 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 14
2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 14 2.2.13. BUSINESS_CARD message . . . . . . . . . . . . . . . . 14
2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Handle resolution . . . . . . . . . . . . . . . . . . . . 18 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.5. Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 3.7. Handle ASAP to ENRP Communication Failures . . . . . . . . 22
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 23 3.9. Business Card handling procedures . . . . . . . . . . . . 23
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . 25 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 25
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25 4.1. Registration.Request Primitive . . . . . . . . . . . . . . 25
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25 4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 25
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 4.3. Cache.Populate.Request Primitive . . . . . . . . . . . . . 26
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 4.4. Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 4.5. Data.Send.Request Primitive . . . . . . . . . . . . . . . 26
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . 27 4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 27
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . 28 4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 28
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . 29 4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 29
4.5.4 Send by Transport Address . . . . . . . . . . . . . . 30 4.5.4. Send by Transport Address . . . . . . . . . . . . . . 30
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . 31 4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 31
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32 4.6. Data.Received Notification . . . . . . . . . . . . . . . . 32
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32 4.7. Error.Report Notification . . . . . . . . . . . . . . . . 32
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . 33 4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 33
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . 34 4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 34
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34 4.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 34
4.9.1 Translation.Request Primitive . . . . . . . . . . . . 35 4.9.1. Translation.Request Primitive . . . . . . . . . . . . 35
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . 35 4.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 35
5. Timers, Variables, and Thresholds . . . . . . . . . . . . . 36 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 36
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 39 6.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1 Normative References . . . . . . . . . . . . . . . . . . . 42 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41
8.2 Informational References (non-normative) . . . . . . . . . 42 8.2. Informational References (non-normative) . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a handle-based addressing model which isolates a networks. ASAP uses a handle-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. single point of failure.
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 the
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. ASAP depends on the services of a high availability
pool handle database a.k.a. ENRP [7]. 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];
Operational scope: See [6]; Operational scope: See [6];
Pool (or server pool): See [6]; Pool (or server pool): See [6];
skipping to change at page 6, line 44 skipping to change at page 6, line 44
use of multi-cast or a named list of ENRP servers. use of multi-cast 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 ASAP message formats. In Section 3 we give the
detailed ASAP procedures for the ASAP implementer. And in Section 4 detailed ASAP procedures for the ASAP implementer. And in Section 4
we give the details of the ASAP interface, focusing on the we give the details of the ASAP interface, focusing on the
communication primitives between the applications above ASAP and ASAP communication primitives between the applications above ASAP and ASAP
itself, and the communications primitives between ASAP and SCTP (or itself, and the communications primitives between ASAP and SCTP (or
other transport layer). Also included in this discussion is relevant other transport layer). Also included in this discussion is relevant
timers and configurable parameters as appropriate. Section 5 timers and configurable parameters as appropriate. Section 5
provides threshold and protocol variables. 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
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 the 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. We propose a
flat peer-to-peer model. Pools of servers will exist in different flat peer-to-peer model. Pools of servers will exist in different
administrative domains. For example, suppose we want to use ASAP/ administrative domains. For example, suppose we want to use ASAP/
ENRP. First, the PU may use DNS to contact an ENRP server. Suppose ENRP. First, the PU may use DNS to contact an ENRP server. Suppose
a PU in North America wishes to contact the server pool in Japan a PU in North America wishes to contact the server pool in Japan
instead of North America. The PU would use DNS to get the list of IP instead of North America. The PU would use DNS to get the list of IP
addresses of the Japanese server pool domain, that is, the ENRP addresses of the Japanese server pool domain, that is, the ENRP
client channel in Japan. From there the PU would query the ENRP client channel in Japan. From there the PU would query the ENRP
server and then directly contact the PE(s) of interest. server 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 octets, a number in a pair of parentheses may follow
the field name to indicate the length of the field in number of the field name to indicate the length of the field in number of
octets. 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 [5]. 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 [5]. The parameter descriptions may also be found in
Section 3 of ENRP-ASAP [5]. Section 3 of ENRP-ASAP [5].
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
----- ------------------------- ----- -------------------------
skipping to change at page 9, line 5 skipping to change at page 9, line 5
0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE
0x07 - ASAP_ENDPOINT_KEEP_ALIVE 0x07 - ASAP_ENDPOINT_KEEP_ALIVE
0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK
0x09 - ASAP_ENDPOINT_UNREACHABLE 0x09 - ASAP_ENDPOINT_UNREACHABLE
0x0a - ASAP_SERVER_ANNOUNCE 0x0a - ASAP_SERVER_ANNOUNCE
0x0b - ASAP_COOKIE 0x0b - ASAP_COOKIE
0x0c - ASAP_COOKIE_ECHO 0x0c - ASAP_COOKIE_ECHO
0x0d - ASAP_BUSINESS_CARD 0x0d - ASAP_BUSINESS_CARD
0x0e - ASAP_ERROR 0x0e - ASAP_ERROR
2.2.1 ASAP_REGISTRATION message 2.2.1. 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 = 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 The pool handle parameter field specifies the handle to be
registered. The PE Parameter field MUST be filled in by the registered. The PE Parameter field MUST be filled in by the
registrant endpoint to declare its transport address, server pooling registrant endpoint to declare its transport address, server pooling
policy and value, and other operational preferences. Note that the policy and value, and other operational preferences. Note that the
ASAP_REGISTRATION message MUST use SCTP and the IP address(es) of the ASAP_REGISTRATION message MUST use SCTP and the IP address(es) of the
PE registered within the Pool Element Parameter MUST be a subset of PE registered within the Pool Element Parameter MUST be a subset of
the addresses of the SCTP association in respective of the transport the addresses of the SCTP association in respective of the transport
protocol registered by the PE. protocol registered by the PE.
2.2.2 ASAP_DEREGISTRATION message 2.2.2. ASAP_DEREGISTRATION 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 = 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 The PE sending the ASAP_DEREGISTRATION shall 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
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 32 skipping to change at page 10, line 32
has rejected the registration. Otherwise, the registration is has rejected the registration. Otherwise, the registration is
granted. granted.
Operational Error Operational Error
This optional TLV parameter may be included if the registration was This optional TLV parameter may be included if the registration was
rejected. This TLV, if present, indicates the cause of the rejected. This TLV, if present, indicates the cause of the
rejection. If the registration was successful this parameter is not rejection. If the registration was successful this parameter is not
included. included.
2.2.4 ASAP_DEREGISTRATION_RESPONSE message 2.2.4. ASAP_DEREGISTRATION_RESPONSE 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 = 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 Operational Error
This optional TLV parameter is included if an error occurred during This optional TLV parameter is included if an error occurred during
the deregistration process. If the deregistration was successful the deregistration process. If the deregistration was successful
this parameter is not included. this parameter is not included.
2.2.5 ASAP_HANDLE_RESOLUTION message 2.2.5. ASAP_HANDLE_RESOLUTION 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 = 0x05 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server to request translation of the This message is sent to a ENRP server to request translation of the
Pool Handle to a list of Pool Elements. If sent from a PE the SCTP Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used. association used for registration SHOULD be used.
2.2.6 ASAP_HANDLE_RESOLUTION_RESPONSE message 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE 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 = 0x06 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x06 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) : : Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 17 skipping to change at page 12, line 17
the response is negative, no PE TLVs are included. the response is negative, no PE TLVs are included.
Operational Error Operational Error
The presence of this TLV indicates that the response is negative The presence of this TLV indicates that the response is negative
(i.e., the handle resolution request was rejected by the ENRP (i.e., the handle resolution request was rejected by the ENRP
server). The cause code in this TLV (if present) will indicate the server). The cause code in this TLV (if present) will indicate the
reason the handle resolution request was rejected (e.g., the reason the handle resolution request was rejected (e.g., the
requested pool handle was not found). requested pool handle was not found).
2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE 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 = 0x07 |0|0|0|0|0|0|0|H| Message Length | | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier | | Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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
message.
This message is sent to a PE by the ENRP server as a "health" check. This message is sent to a PE by the ENRP server as a "health" check.
If the transport level Heart Beat mechanism is insufficient, this If the transport level Heart Beat mechanism is insufficient, this
adds heartbeat messages with the goal of determining health status at adds heartbeat messages with the goal of determining health status at
ASAP level in a possibly more timely fashion. (The transport level ASAP level in a possibly more timely fashion. (The transport level
Heart Beat may sometimes be considered insufficient due to that time Heart Beat may sometimes be considered insufficient due to that time
outs are set for too long or heartbeats are not frequent enough, or, outs are set for too long or heartbeats are not frequent enough, or,
that the transport level Heart Beat mechanism's coverage is limited that the transport level Heart Beat mechanism's coverage is limited
only to the transport level at the two ends.) only to the transport level at the two ends.)
Using ASAP keepalive also has additional value to the reliability of Using ASAP keepalive also has additional value to the reliability of
fault detection when SCTP stack is in the kernel. In such a case, fault detection when SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity while SCTP level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, ASAP keepalive monitors the end-to-end between the two SCTP stacks, ASAP keepalive monitors the end-to-end
liveliness of the ASAP layer above it. liveliness of the ASAP layer above it.
Server Identifier field indicates the sender ENRP server of the 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message
message.
2.2.8 ASAP_ENDPOINT_KEEP_ALIVE_ACK 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 = 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 This message is sent by the PE to the ENRP server as an
acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message. acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message.
2.2.9 ASAP_ENDPOINT_UNREACHABLE message 2.2.9. ASAP_ENDPOINT_UNREACHABLE 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 = 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 A PE or PU will send this message to an ENRP server to report the
unreachability of the specified PE. unreachability of the specified PE.
2.2.10 ASAP_SERVER_ANNOUNCE message 2.2.10. ASAP_SERVER_ANNOUNCE 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 = 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 13 skipping to change at page 14, line 13
: Transport param #n : : Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by an ENRP server such that PUs and PEs know the This message is sent by an ENRP server such that PUs and PEs know the
transport layer information necessary to connect to the ENRP server. transport layer information necessary to connect to the ENRP server.
The transport parameters are optional and only TCP and SCTP transport The transport parameters are optional and only TCP and SCTP transport
parameters are allowed. Server Identifier field indicates the sender parameters are allowed. Server Identifier field indicates the sender
ENRP server of the message. ENRP server of the message.
2.2.11 COOKIE message 2.2.11. COOKIE 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 = 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 This message is sent by a PE to a PU. It may only be sent when a
control channel exists between the PE and PU. control channel exists between the PE and PU.
2.2.12 ASAP_COOKIE_ECHO message 2.2.12. ASAP_COOKIE_ECHO 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 = 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 This message is sent by a PU to a PE in case of a failover. The
Cookie Parameter is one received latest from the failed PE. Cookie Parameter is one received latest from the failed PE.
2.2.13 BUSINESS_CARD message 2.2.13. BUSINESS_CARD message
This message is sent by a PU to a PE or from a PE to a PU. This This message is sent by a PU to a PE or from a PE to a PU. This
parameter MUST NOT be sent if a control channel does NOT exists parameter MUST NOT be sent if a control channel does NOT exists
between the PE and PU. between the PE and PU.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 22 skipping to change at page 15, line 22
: 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 The sender of this message lists both the Pool that the sender
belongs to and a preferred list of failover candidates. belongs to and a preferred list of failover candidates.
2.2.14 ASAP_ERROR message 2.2.14. ASAP_ERROR message
This message is used to report an operational error. Currently the This message is used to report an operational error. Currently the
use of this message is undefined, it is reserved for future use use of this message is undefined, it is reserved for future use
[Editors Note: we need to come up with concrete uses or get rid of [Editors Note: we need to come up with concrete uses or get rid of
the message]. 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 join its server pool it MUST use the procedures
outlined in this section to register. Often the registration will be outlined in this section to register. Often the registration will be
triggered by a user request primitive (discussed in Section 4.1). triggered by a user request primitive (discussed in Section 4.1).
The ASAP endpoint MUST register using an SCTP association between the The ASAP endpoint MUST register using an SCTP association between the
ASAP endpoint and the ENRP server. If the ASAP endpoint has not ASAP endpoint and the ENRP server. If the ASAP endpoint has not
established its Home ENRP server it MUST follow the procedures 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 to establish its Home ENRP server.
Once the ASAP endpoint has established its Home ENRP server the Once the ASAP endpoint has established its Home ENRP server the
skipping to change at page 17, line 46 skipping to change at page 17, line 46
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 attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count exceeds registration time-outs or failures occurs and the local count exceeds
the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the
error to its upper layer and stop attempting registration. 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 the PE wishes to deregister from its server pool
(normally via an upper layer requests see Section 4.2) it SHOULD use (normally via an upper layer requests see Section 4.2) it SHOULD use
the following procedures. Note that an alternate method of the following procedures. Note 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. lift time to expire.
When deregistering the PE SHOULD use the same SCTP association with When deregistering the PE SHOULD use the same SCTP association with
its Home ENRP server that was used for registration. To deregister its Home ENRP server that was used for registration. To deregister
the ASAP endpoint MUST take the following actions: the ASAP endpoint MUST take the following actions:
skipping to change at page 18, line 36 skipping to change at page 18, line 36
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 deregistration response, the ASAP endpoint
MUST stop the T3-deregistration timer. MUST stop the T3-deregistration timer.
Note that after a successful deregistration the PE MAY still receive Note that after a successful deregistration the PE MAY still receive
requests for some period of time. The PE MAY wish to still remain requests for some period of time. The PE MAY wish to still remain
active and service these requests or may wish to ignore these active and service these requests or may wish to ignore these
requests and exit. requests and exit.
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 Endpoint sends to a Pool handle ( Section 4.5.1) or
requests a cache population (Section 4.3) but may occur for other requests a cache population (Section 4.3) but may occur for other
reasons (e.g. the internal ASAP PE wishes to know its peers for reasons (e.g. the internal ASAP PE wishes to know its peers for
sending a message to all of them). When an Endpoint (PE or PU) sending a message to all of them). When an Endpoint (PE or PU)
wishes to resolve a pool handle it MUST take the following actions: wishes to resolve a pool handle 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.
skipping to change at page 19, line 42 skipping to change at page 19, line 42
a new handle resolution to be issued to update the cache. a new handle resolution to be issued to update the cache.
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 request an update and answer the request or block the user and
wait for an updated cache before proceeding with the users 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 make a handle
resolution request but instead use the entry from the cache. resolution request but instead 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 Periodically an ENRP server may choose to "audit" a PE. It does this
by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7).
Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message the following Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message the following
actions MUST be taken: actions MUST be taken:
KA1) The PE must verify that the Pool Handle is correct and matches KA1) The PE must verify that the Pool Handle is correct and matches
the Pool Handle sent in its earlier ASAP_REGISTRATION. If the the Pool Handle sent in its earlier ASAP_REGISTRATION. If the
Pool Handle does not match silently discard the message. Pool Handle does not match silently discard the message.
skipping to change at page 20, line 24 skipping to change at page 20, line 24
KA2.2) Fill in the PE Identifier that was used with this PE for KA2.2) Fill in the PE Identifier that was used with this PE for
registration. registration.
KA2.3) Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the KA2.3) Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the
appropriate SCTP association for that ENRP server. appropriate SCTP association for that ENRP server.
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, 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 that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP endpoint This may occur by a specific SCTP error realized by the ASAP endpoint
or via an ASAP user report via the Transport.Failure Primitive or 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. The Endpoint should fill in the
Pool Handle and PE identifier of the unreachable endpoint. If the Pool Handle and PE identifier of the unreachable endpoint. If the
sender is a PE the message MUST be sent via SCTP to the Endpoints sender is a PE the message MUST be sent via SCTP to the Endpoints
Home ENRP server. Note: an ASAP endpoint MUST report No more than Home ENRP server. Note: an ASAP endpoint MUST report No more than
once each time it encounters such an event. once each time it encounters such an event.
Note: when processing a Transport.Failure Primitive (Section 4.9.2) Note: when processing a Transport.Failure Primitive (Section 4.9.2)
the ASAP endpoint MUST NOT send a unreachable report unless the ASAP the ASAP endpoint MUST NOT send a unreachable report unless the ASAP
endpoint has sent at least one message to the PE specified by the endpoint has sent at least one message to the PE specified by the
primitive. 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.
If the multicast capabilities are used an ENRP server MUST send If the multicast capabilities are used an ENRP server MUST send
periodically every T6-Serverannounce an ASAP_SERVER_ANNOUNCE message periodically every T6-Serverannounce an ASAP_SERVER_ANNOUNCE message
(Section 2.2.10) including all the transport addresses available for (Section 2.2.10) including all the transport addresses available for
ASAP communication to the multicast channel. ASAP communication to the multicast 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 address in its list of ENRP
skipping to change at page 22, line 15 skipping to change at page 22, line 15
SH5.2) The endpoint SHOULD repeat trying to establish an SH5.2) The 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 to
connect to. connect to.
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 that it was able
to establish an association or connection with, and send all its to establish an association or connection with, and send all its
subsequent the handlespace service requests to this new home ENRP subsequent the handlespace service requests to this new home ENRP
server. server.
3.7 Handle ASAP to ENRP Communication Failures 3.7. Handle ASAP to ENRP 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 an
endpoint tries to communicate with the ENRP server: endpoint tries to communicate with the 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 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 indicates that the SCTP layer failed to deliver a message sent
to the ENRP server. In other words, the ENRP server is currently to the ENRP server. In other words, the ENRP server is currently
unreachable. 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 failed
message. Instead, it should discard the failed message and start the message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section 3.6 ENRP server hunt procedure as described in Section 3.6
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 a T1-ENRPrequest timer expires, the ASAP should re-send the
original request to the ENRP server and re-start the T1-ENRPrequest original request to the ENRP server and re-start the T1-ENRPrequest
timer. In parallel, the server hunt procedure should be started as timer. In parallel, the server hunt procedure should be started as
outlined in Section 3.6. outlined 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 timer
should be discarded. Note that if an alternate ENRP server responds should be discarded. Note that if an alternate ENRP server responds
the ASAP endpoint SHOULD adopt the responding ENRP server as its new the ASAP endpoint SHOULD adopt the responding ENRP server as its new
"home" server and resend the request to the new "home" server. "home" server and resend the request to the new "home" server.
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 the PU via the control channel. The ASAP
layer at the PU stores the Cookie parameter and discards an older one layer at the PU stores the Cookie parameter and discards an older one
if it is present. if it is present.
If the ASAP layer detects a failure and initiates a failover to a If the ASAP layer detects a failure and initiates a failover to a
different PE, the ASAP layer sends the last received Cookie parameter different PE, the ASAP layer sends the last received Cookie parameter
in an ASAP_COOKIE_ECHO message to the new PE. The upper layer may be in an ASAP_COOKIE_ECHO message to the new PE. The upper layer may be
involved in the failover procedure. involved in the failover procedure.
This cookie mechanism can be used as a simple method for state This cookie mechanism can be used as a simple method for state
sharing. Therefore a cookie should be signed by the sending PE and sharing. Therefore a cookie should be signed by the sending PE and
this should be verified by the receiving PE. The details of this are this should be verified by the receiving PE. The details of this are
out of scope of this document. It is only important that the PU out of scope of this document. It is only important that the PU
stores always the last received Cookie Parameter and sends that back stores always the last received Cookie Parameter and sends that back
unmodified in case of a PE failure. 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 (i.e. the first
message is sent from the PU to the PE) the ASAP layer in the PU message is sent from the PU to the PE) the ASAP layer in the PU
SHOULD send an ASAP_BUSINESS_CARD IF the sender is also registered as SHOULD send an ASAP_BUSINESS_CARD IF the sender is also registered as
a PE. A PE may also send back to a PU a business card as well. An a PE. A PE may also send back to a PU a business card as well. An
ASAP_BUSINESS_CARD MUST NOT be sent if a control channel does NOT ASAP_BUSINESS_CARD MUST NOT be sent if a control channel does NOT
exist between the PU and PE. After communication as been established exist between the PU and PE. After communication as been established
between a PE and PU at any time either entity may update its failover between a PE and PU at any time either entity may update its failover
distribution by sending a new ASAP_BUSINESS_CARD. distribution by sending a new ASAP_BUSINESS_CARD.
skipping to change at page 25, line 21 skipping to change at page 25, line 21
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 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
communicate with the ENRP server is used as the default User communicate with the ENRP server is used as the default User
Transport parameter. Note that any IP address contained within a Transport parameter. Note that any IP address contained within a
skipping to change at page 25, line 46 skipping to change at page 25, line 46
handlespace, thus becoming a Pool Element of a pool. The ASAP user handlespace, thus becoming a Pool Element of a pool. The ASAP user
must register itself with the ENRP server by using this primitive must register itself with the ENRP server by using this primitive
before other ASAP users using the handlespace can send message(s) to before other ASAP users using the handlespace can send message(s) to
this ASAP user by Pool Handle or by PE handle (see Section 4.5.1 and this ASAP user by Pool Handle or by PE handle (see Section 4.5.1 and
Section 4.5.3). Section 4.5.3).
In response to the registration primitive, the ASAP endpoint will In response to the registration primitive, the ASAP endpoint will
send an ASAP_REGISTRATION message to the home ENRP server (See send an ASAP_REGISTRATION message to the home ENRP server (See
Section 2.2.1 and Section 3.1), and start a T2-registration timer. Section 2.2.1 and Section 3.1), and start a T2-registration timer.
4.2 Deregistration.Request Primitive 4.2. Deregistration.Request Primitive
Format: deregistration.request(poolHandle) Format: deregistration.request(poolHandle)
The ASAP PE invokes this primitive to remove itself from the Server The ASAP PE invokes this primitive to remove itself from the Server
Pool. This should be used as a part of the graceful shutdown process Pool. This should be used as a part of the graceful shutdown process
by the application. by the application.
A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the
home ENRP server (see Section 2.2.2 and Section 3.2). home ENRP server (see Section 2.2.2 and Section 3.2).
4.3 Cache.Populate.Request Primitive 4.3. Cache.Populate.Request Primitive
Format: cache.populate.request([Pool-Handle | Format: cache.populate.request([Pool-Handle |
Pool-Element-Handle]) Pool-Element-Handle])
If the address type is a Pool handle and a local handle translation If the address type is a Pool handle and a local handle translation
cache exists, the ASAP endpoint should initiate a mapping information cache exists, the ASAP endpoint should initiate a mapping information
query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle
and update it local cache when the response comes back from the ENRP and update it local cache when the response comes back from the ENRP
server. server.
If a Pool-Element-Handle is passed then the Pool Handle is unpacked If a Pool-Element-Handle is passed then the Pool Handle is unpacked
from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message
is sent to the ENRP server for resolution. When the response message is sent to the ENRP server for resolution. When the response message
returns from the ENRP server the local cache is updated. returns from the ENRP server the local cache is updated.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.4 Cache.Purge.Request Primitive 4.4. Cache.Purge.Request Primitive
Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) Format: cache.purge.request([Pool-Handle | Pool-Element-Handle])
If the user passes a Pool handle and local handle translation cache If the user passes a Pool handle and local handle translation cache
exists, the ASAP endpoint should remove the mapping information on exists, the ASAP endpoint should remove the mapping information on
the Pool handle from its local cache. If the user passes a Pool- the Pool handle from its local cache. If the user passes a Pool-
Element-Handle then the Pool handle within is used for the Element-Handle then the Pool handle within is used for the
cache.purge.request. cache.purge.request.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.5 Data.Send.Request Primitive 4.5. Data.Send.Request Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data.send.request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified Pool This primitive requests ASAP to send a message to some specified Pool
or Pool Element within the current Operational scope. or Pool Element within the current Operational scope.
Depending on the address type used for the send request, the senders Depending on the address type used for the send request, the senders
ASAP endpoint may perform address translation and Pool Element ASAP endpoint may perform address translation and Pool Element
selection before sending the message out. This also MAY dictate the selection before sending the message out. This also MAY dictate the
creation of a local transport endpoint in order to meet the required creation of a local transport endpoint in order to meet the required
transport type. transport type.
The data.send.request primitive can take different forms of address The data.send.request primitive can take different forms of address
types as described in the following sections. types as described in the following sections.
4.5.1 Sending to a Pool Handle 4.5.1. Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a pool handle. indicates a pool handle.
This is the simplest form of send.data.request primitive. By This is the simplest form of send.data.request primitive. By
default, this directs ASAP to send the message to one of the Pool default, this directs ASAP to send the message to one of the Pool
Elements in the specified pool. Elements in the specified pool.
Before sending the message out to the pool, the senders ASAP endpoint Before sending the message out to the pool, the senders ASAP endpoint
MUST first perform a pool handle to address translation. It may also MUST first perform a pool handle to address translation. It may also
skipping to change at page 28, line 19 skipping to change at page 28, line 19
For more on the ENRP server request procedures see ENRP [7]. For more on the ENRP server request procedures see ENRP [7].
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
Each time an ASAP user sends a message to a pool that contains more Each time an ASAP user sends a message to a pool that contains more
than one PE, the senders ASAP endpoint must select one of the PEs in than one PE, the senders ASAP endpoint must select one of the PEs in
the pool as the receiver of the current message. The selection is the pool as the receiver of the current message. The selection is
done according to the current server pooling policy of the pool to done according to the current server pooling policy of the pool to
which the message is sent. which the message is sent.
Note, no selection is needed if the ASAP_SEND_TOALL option is set Note, no selection is needed if the ASAP_SEND_TOALL option is set
(see Section 4.5.5). (see Section 4.5.5).
skipping to change at page 28, line 42 skipping to change at page 28, line 42
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 Four basic server pooling policies are defined in ASAP, namely the
Round Robin, Least Used, Least Used Degrading and Weighted Round Round Robin, Least Used, Least Used Degrading and Weighted Round
Robin. The following sections describes each of these policies. 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 4.5.2.2. Least Used Policy
When the destination Pool is under the Least Used server pooling When the destination Pool is under the Least Used server pooling
policy, the ASAP endpoint of the message sender will select the PE 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 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 current message. If more than one PE from the group share the same
lowest policy value, the selection will be done round Robin amongst lowest policy value, the selection will be done round Robin amongst
those PEs. those PEs.
It is important to note that this policy means that the same PE will 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 be always selected as the message receiver by the sender until the
load control information of the pool is updated and changed in 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). local cache of the sender (via a cache update see Section 3.3).
4.5.2.3 Least Used with Degradation Policy 4.5.2.3. Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception 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 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 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 incremented, and thus it may no longer be the lowest value in the
Pool. Pool.
This provides a degradation of the policy towards round Robin policy This provides a degradation of the policy towards round Robin policy
over time. As with the Least Used policy, every local cache update over time. As with the Least Used policy, every local cache update
at the sender will bring the policy back to Least Used with at the sender will bring the policy back to Least Used with
Degradation. Degradation.
4.5.2.4 Weighted Round Robin Policy 4.5.2.4. Weighted Round Robin Policy
[TBD] [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 dependant
skipping to change at page 30, line 37 skipping to change at page 30, line 37
Section 3.5 and Section 4.9 defines the fail-over procedures for Section 3.5 and Section 4.9 defines the fail-over procedures for
cases where the PE pointed to by the Pool Element handle is found cases where the PE pointed to by the Pool Element handle is found
unreachable. unreachable.
Optionally, the ASAP endpoint may return the actual Pool Element Optionally, the ASAP endpoint may return the actual Pool Element
handle to which the message was sent (this may be different from the handle to which the message was sent (this may be different from the
Pool Element handle specified when the primitive is invoked, due to Pool Element handle specified when the primitive is invoked, due to
the possibility of automatic fail-over). the possibility of automatic fail-over).
4.5.4 Send by Transport Address 4.5.4. Send by Transport Address
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate a transport address and transport type. indicate a transport address and transport type.
This directs the senders ASAP endpoint to send the message out to the This directs the senders ASAP endpoint to send the message out to the
specified transport address. specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint fail-over is support when this form of send request is
used. This form of send request effectively by-passes the ASAP used. This form of send request effectively by-passes the ASAP
endpoint. endpoint.
4.5.5 Message Delivery Options 4.5.5. Message Delivery Options
The Options parameter passed in the various forms of the above The Options parameter passed in the various forms of the above
data.send.request primitive gives directions to the senders ASAP data.send.request primitive gives directions to the senders ASAP
endpoint on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise "OR"ing The value of the Options parameter is generated by bit-wise "OR"ing
of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 Use default setting. ASAP_USE_DEFAULT: 0x0000 Use default setting.
skipping to change at page 32, line 10 skipping to change at page 32, line 10
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 to
send the current message using un-ordered delivery (note the 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
layer. layer.
Along with the message being passed, the ASAP endpoint of the Along with the message being passed, the ASAP endpoint of the
receiver should also indicate to its upper layer the message senders receiver should also indicate to its upper layer the message senders
skipping to change at page 32, line 36 skipping to change at page 32, line 36
receiver's ASAP endpoint, a reverse mapping from the senders IP receiver's ASAP endpoint, a reverse mapping from the senders IP
address to the pool handle should be performed and if the mapping address to the pool handle should be performed and if the mapping
is successful, the senders ASAP Pool Element handle should be is successful, the senders ASAP Pool Element handle should be
constructed and passed in the senderAddress field. constructed and passed in the senderAddress field.
B) If there is no local cache or the reverse mapping is not B) If there is no local cache or the reverse mapping is not
successful, the SCTP association id or other transport specific successful, the SCTP association id or other transport specific
identification (if SCTP is not being used) should be passed in the identification (if SCTP is not being used) should be passed in the
senderAddress field. senderAddress field.
4.7 Error.Report Notification 4.7. Error.Report Notification
Format: error.report(destinationAddress, typeOfAddress, Format: error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage) failedMessage, sizeOfMessage)
An error.report should be generated to notify the ASAP user about An error.report should be generated to notify the ASAP user about
failed message delivery as well as other abnormalities. failed message delivery as well as other abnormalities.
The destinationAddress and typeOfAddress together indicates to whom The destinationAddress and typeOfAddress together indicates to whom
the message was originally sent. The address type can be either a the message was originally sent. The address type can be either a
ASAP Pool Element handle, association id, or a transport address. ASAP Pool Element handle, association id, or a transport address.
The original message (or the first portion of it if the message is The original message (or the first portion of it if the message is
too big) and its size should be passed in the failedMessage and too big) and its size should be passed in the failedMessage and
sizeOfMessage fields, respectively. sizeOfMessage fields, respectively.
4.8 Examples 4.8. Examples
These examples assume an underlying SCTP transport between the PE and These examples assume an underlying SCTP transport between the PE and
PU. Other transports are possible but SCTP is utilized in the PU. Other transports are possible but SCTP is utilized in the
examples for illustrative purposes. Note that all communication examples for illustrative purposes. Note that all communication
between PU and ENRP server and PE and ENRP servers would be using between PU and ENRP server and PE and ENRP servers would be using
SCTP. SCTP.
4.8.1 Send to a New Pool 4.8.1. Send to a New Pool
This example shows the event sequence when a Pool User sends the This example shows the event sequence when a Pool User sends the
message "hello" to a pool which is not in the local translation cache message "hello" to a pool which is not in the local translation cache
(assuming local caching is supported). (assuming local caching is supported).
ENRP Server PU new-handle:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
skipping to change at page 34, line 20 skipping to change at page 34, line 17
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.
4.8.2 Send to a Cached Pool Handle 4.8.2. Send to a Cached Pool Handle
This shows the event sequence when the ASAP user PU sends another This shows the event sequence when the ASAP user PU sends another
message to the pool "new-handle" after what happened in message to the pool "new-handle" after what happened in
Section 4.8.1. Section 4.8.1.
ENRP Server PU new-handle:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
skipping to change at page 34, line 46 skipping to change at page 34, line 43
pdata.send.request("new-handle", handle-type, "hello2", 6, 0); pdata.send.request("new-handle", handle-type, "hello2", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-handle" in The ASAP endpoint, in response, looks up the pool "new-handle" in
its local cache and find the mapping information. its local cache and find the mapping information.
2) Based on the server pooling policy of "new-handle", ASAP at PU 2) Based on the server pooling policy of "new-handle", ASAP at PU
selects the PE (assume EPx is selected again), and sends out selects the PE (assume EPx is selected again), and sends out
"hello2" message (assume the SCTP association is already set up). "hello2" message (assume the SCTP association is already set up).
4.9 PE send failure 4.9. PE send failure
When the ASAP endpoint in a PE or PU attempts to send a message to a When the ASAP endpoint in a PE or PU attempts to send a message to a
PE and fails the failed sender will report the event as described in PE and fails the failed sender will report the event as described in
Section 3.5 . Section 3.5 .
Additional primitive are also defined in this section to support Additional primitive are also defined in this section to support
those user applications that do not wish to use ASAP as the actual those user applications that do not wish to use ASAP as the actual
transport. transport.
4.9.1 Translation.Request Primitive 4.9.1. Translation.Request Primitive
Format: translation.request(Pool-Handle) Format: translation.request(Pool-Handle)
If the address type is a Pool handle and a local handle translation If the address type is a Pool handle and a local handle translation
cache exists, the ASAP endpoint should look within its translation cache exists, the ASAP endpoint should look within its translation
cache and return the current known transport types, ports and cache and return the current known transport types, ports and
addresses to the caller. addresses to the caller.
If the Pool handle does not exist in the local handle cache or no If the Pool handle does not exist in the local handle cache or no
handle cache exists, the ASAP endpoint will send an handle cache exists, the ASAP endpoint will send an
ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon
completion of the handle resolution, the ASAP endpoint should completion of the handle resolution, the ASAP endpoint should
populate the local handle cache (if a local handle cache is populate the local handle cache (if a local handle cache is
supported) and return the transport types, ports and addresses to the supported) and return the transport types, ports and addresses to the
caller. caller.
4.9.2 Transport.Failure Primitive 4.9.2. Transport.Failure Primitive
Format: transport.failure(Pool-Handle, Transport-address) Format: transport.failure(Pool-Handle, Transport-address)
If an external user encounters a failure in sending to a PE and is If an external user encounters a failure in sending to a PE and is
NOT using ASAP it can use this primitive to report the failure to the NOT using ASAP it can use this primitive to report the failure to the
ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the
"home" ENRP server in response to this primitive. Note ASAP SHOULD "home" ENRP server in response to this primitive. Note ASAP SHOULD
NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually
made a previous request to send data to the PE. made a previous request to send data to the PE.
5. Timers, Variables, and Thresholds 5. Timers, Variables, and Thresholds
The following is a summary of the timers, variables, and pre-set The following is a summary of the timers, variables, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
5.1 Timers 5.1. Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending an ASAP_REGISTRATION T2-registration - A timer started when sending an ASAP_REGISTRATION
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a deregistration
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
skipping to change at page 36, line 38 skipping to change at page 36, line 38
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 120 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.
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.
6. Security Considerations 6. Security Considerations
skipping to change at page 39, line 41 skipping to change at page 38, line 41
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other 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]). [7]).
6.1 Implementing Security Mechanisms 6.1. 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
skipping to change at page 42, line 7 skipping to change at page 41, line 7
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
feedback. feedback.
8. References 8. References
8.1 Normative References 8.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[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., Allen, C., Treese, W., Karlton, P., Freier, A., and [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, RFC 2246, January 1999.
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] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Handlespace Server Access Protocol (ASAP) and Endpoint Handlespace
Redundancy Protocol (ENRP) Parameters", Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-09 (work in progress), draft-ietf-rserpool-common-param-09 (work in progress),
July 2005. July 2005.
skipping to change at page 42, line 45 skipping to change at page 41, line 44
draft-ietf-rserpool-enrp-12 (work in progress), July 2005. draft-ietf-rserpool-enrp-12 (work in progress), July 2005.
[8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. [8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
Holdrege, "Threats Introduced by Rserpool and Requirements for Holdrege, "Threats Introduced by Rserpool and Requirements for
Security in Response to Threats", draft-ietf-rserpool-threats-05 Security in Response to Threats", draft-ietf-rserpool-threats-05
(work in progress), July 2005. (work in progress), July 2005.
[9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", [9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP",
RFC 3436, December 2002. RFC 3436, December 2002.
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.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
skipping to change at page 44, line 41 skipping to change at page 43, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 71 change blocks. 
140 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/