draft-ietf-rserpool-asap-10.txt   draft-ietf-rserpool-asap-11.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: April 14, 2005 Q. Xie Expires: August 22, 2005 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
October 14, 2004 February 18, 2005
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-10.txt draft-ietf-rserpool-asap-11.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 14, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Name Resolution 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
name-based addressing model which isolates a logical communication handle-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
pool, providing full transparent support for server-pooling and load pool, providing full transparent support for server-pooling and load
sharing. It also allows dynamic system scalability - members of a sharing. It also allows dynamic system scalability - members of a
server pool can be added or removed at any time without interrupting server pool can be added or removed at any time without interrupting
the service. the service.
ASAP is designed to take full advantage of the network level ASAP is designed to take full advantage of the network level
redundancy provided by the Stream Transmission Control Protocol redundancy provided by the Stream Transmission Control Protocol
(SCTP) RFC2960 [4]. Each transport protocol to be used by Pool (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool
Elements (PE) and Pool Users (PU) MUST have an accompanying Elements (PE) and Pool Users (PU) MUST have an accompanying
transports mapping document. Note that ASAP messages passed between transports mapping document. Note that ASAP messages passed between
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 name to address translation, load sharing management, interface for pool handle to address translation, load sharing
and fault management while ENRP defines the high availability name management, and fault management while ENRP defines the high
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 REGISTRATION message . . . . . . . . . . . . . . . . . 9 2.2.1 ASAP_REGISTRATION message . . . . . . . . . . . . . . 9
2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . 9 2.2.2 ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9
2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . 10 2.2.3 ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10
2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . 10 2.2.4 ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10
2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . 11 2.2.5 ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11
2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . 11 2.2.6 ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 11
2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . 12 2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . 13 2.2.8 ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13
2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . 13 2.2.9 ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13
2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . 14 2.2.10 ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . 14
2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14
2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . 14 2.2.12 ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . 15
2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 15 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 15
2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15 2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 3.3 Handle resolution . . . . . . . . . . . . . . . . . . . . 19
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 20
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 21
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 21
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 23
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 23
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 23
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 24
3.9 Business Card handling procedures . . . . . . . . . . . . 23 3.9 Business Card handling procedures . . . . . . . . . . . . 24
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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . 37
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 41 8.1 Normative References . . . . . . . . . . . . . . . . . . . 41
8.2 Informational References (non-normative) . . . . . . . . . . 41 8.2 Informational References (non-normative) . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 43 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 name-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.
When multiple receiver instances exist under the same name, a.k.a, a When multiple receiver instances exist under the same handle, a.k.a,
server pool, ASAP will select one Pool Element (PE), based on the a server pool, ASAP will select one Pool Element (PE), based on the
current load sharing policy indicated by the server pool, and deliver current load sharing policy indicated by the server pool, and deliver
the message to the selected PE. the message to the selected PE.
While delivering the message, ASAP monitors the reachability of the While delivering the message, ASAP monitors the reachability of the
selected PE. If it is found unreachable, before notifying the sender selected PE. If it is found unreachable, before notifying the sender
of the failure, ASAP can automatically select another PE (if one of the failure, ASAP can automatically select another PE (if one
exists) under that pool and attempt to deliver the message to that exists) under that pool and attempt to deliver the message to that
PE. In other words, ASAP is capable of transparent fail-over amongst PE. In other words, ASAP is capable of transparent fail-over amongst
instances of a server pool. instances of a server pool.
ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a ASAP uses the Endpoint Handlespace Redundancy Protocol (ENRP) to
high availability name space. ASAP is responsible for the provide a high availability pool handle space. ASAP is responsible
abstraction of the underlying transport technologies, load for the abstraction of the underlying transport technologies, load
distribution management, fault management, as well as the distribution management, fault management, as well as the
presentation to the upper layer (i.e., the ASAP user) a unified presentation to the upper layer (i.e., the ASAP user) a unified
primitive interface. primitive interface.
When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by the can seamlessly incorporate the link-layer redundancy provided by 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
name space 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.
Operation scope: See [6]; Operational scope: See [6];
Operation scope: See [6]; Operational scope: See [6];
Pool (or server pool): See [6]; Pool (or server pool): See [6];
Pool handle: See [6]; Pool handle: See [6];
Pool element (PE): See [6]; Pool element (PE): See [6];
Pool user (PU): See [6]; Pool user (PU): See [6];
Pool element handle: See [6]; Pool element handle: See [6];
ENRP handlespace (or handlespace): See [6]; ENRP handlespace (or handlespace): See [6];
pool registrar: A server program running on a host that manages the pool registrar: A server program running on a host that manages the
name space collectively with its peer ENRP servers and replies to handle space collectively with its peer ENRP servers and replies
the service requests from any Pool User or Pool Element. to the service requests from any Pool User or Pool Element.
Home ENRP server: The ENRP server to which a PE or PU currently Home ENRP server: The ENRP server to which a PE or PU currently
belongs. A PE MUST only have one home ENRP server at any given belongs. A PE MUST only have one home ENRP server at any given
time and both the PE and its home ENRP server MUST keep track of time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
skipping to change at page 8, line 34 skipping to change at page 8, line 34
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
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - Registration 0x01 - ASAP_REGISTRATION
0x02 - Deregistration 0x02 - ASAP_DEREGISTRATION
0x03 - Registration Response 0x03 - ASAP_REGISTRATION_RESPONSE
0x04 - Deregistration Response 0x04 - ASAP_DEREGISTRATION_RESPONSE
0x05 - Name Resolution 0x05 - ASAP_HANDLE_RESOLUTION
0x06 - Name Resolution Response 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE
0x07 - Endpoint Keep Alive 0x07 - ASAP_ENDPOINT_KEEP_ALIVE
0x08 - Endpoint Keep Alive Acknowledgement 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK
0x09 - Endpoint Unreachable 0x09 - ASAP_ENDPOINT_UNREACHABLE
0x0a - Server Announce 0x0a - ASAP_SERVER_ANNOUNCE
0x0b - Cookie 0x0b - ASAP_COOKIE
0x0c - Cookie-Echo 0x0c - ASAP_COOKIE_ECHO
0x0d - Business Card 0x0d - ASAP_BUSINESS_CARD
0x0e - ASAP Error 0x0e - ASAP_ERROR
2.2.1 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 name to be registered. The pool handle parameter field specifies the handle to be
The PE Parameter field MUST be filled in by the registrant endpoint registered. The PE Parameter field MUST be filled in by the
to declare its transport address, server pooling policy and value, registrant endpoint to declare its transport address, server pooling
and other operation preferences. Note that the registration message policy and value, and other operational preferences. Note that the
MUST use SCTP and the IP address(es) of the PE registered within the ASAP_REGISTRATION message MUST use SCTP and the IP address(es) of the
Pool Element Parameter MUST be a subset of the addresses of the SCTP PE registered within the Pool Element Parameter MUST be a subset of
association in respective of the transport protocol registered by the the addresses of the SCTP association in respective of the transport
PE. protocol registered by the PE.
2.2.2 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 DEREGISTRATION shall fill in the pool handle and The PE sending the ASAP_DEREGISTRATION shall fill in the pool handle
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 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 37 skipping to change at page 10, line 37
This optional TLV parameter is included if an error or some atypical This optional TLV parameter is included if an error or some atypical
events occurred during the registration process. When the 'R' flag events occurred during the registration process. When the 'R' flag
is set to '1', this TLV, if present, indicates the cause of the is set to '1', this TLV, if present, indicates the cause of the
rejection. When the 'R' flag is set to '0', this TLV, if present, rejection. When the 'R' flag is set to '0', this TLV, if present,
serves as a warning to the registering PE, informing it that some of serves as a warning to the registering PE, informing it that some of
its registration values may have been modified or overruled by the its registration values may have been modified or overruled by the
ENRP server (e.g., the selection policy type overruled). If the ENRP server (e.g., the selection policy type overruled). If the
registration was successful and there is no warning this parameter is registration was successful and there is no warning this parameter is
not included. not included.
2.2.4 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 NAME_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 NAME_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 16 skipping to change at page 12, line 16
Pool Element Parameters Pool Element Parameters
When the response is positive, an array of PE TLVs are included, When the response is positive, an array of PE TLVs are included,
indicating the current PEs and their information in the named pool. indicating the current PEs and their information in the named pool.
In a positive response, at least one PE TLV MUST be present. When In a positive response, at least one PE TLV MUST be present. When
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 name resolution request was rejected by the ENRP server). (i.e., the handle resolution request was rejected by the ENRP
The cause code in this TLV (if present) will indicate the reason the server). The cause code in this TLV (if present) will indicate the
name resolution request was rejected (e.g., the requested pool handle reason the handle resolution request was rejected (e.g., the
was not found). requested pool handle was not found).
2.2.7 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|0| Message Length | | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message Server Identifier field indicates the sender ENRP server of the
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 has an This message is sent by the PE to the ENRP server has an
acknowledgment to the ENDPOINT_KEEP_ALIVE message. acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message.
2.2.9 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 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 ID | | Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #1 : : Transport param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #2 : : Transport param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ..... : : ..... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n : : Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by an ENRP server such that PUs and PEs know the 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. parameters are allowed. Server Identifier field indicates the sender
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 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
skipping to change at page 15, line 32 skipping to change at page 15, line 43
: .. : : .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 operation error. Currently the use This message is used to report an operational error. Currently the
of this message is undefined, it is reserved for future use [Editors use of this message is undefined, it is reserved for future use
Note: we need to come up with concrete uses or get rid of the [Editors Note: we need to come up with concrete uses or get rid of
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation 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
skipping to change at page 16, line 29 skipping to change at page 17, line 29
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
following procedures MUST be followed to register: following procedures MUST be followed to register:
R1) The SCTP endpoint used to communicate with the ENRP server MUST R1) The SCTP endpoint used to communicate with the ENRP server MUST
be bound to all IP addresses that will be used by the PE be bound to all IP addresses that will be used by the PE
(irregardless of what protocol will be used to service user (irregardless of what protocol will be used to service user
requests to the PE). requests to the PE).
R2) The ASAP endpoint MUST formulate a Registration message as R2) The ASAP endpoint MUST formulate an ASAP_REGISTRATION message as
defined in Section 2.2.1 In formulating the message the ASAP defined in Section 2.2.1 In formulating the message the ASAP
endpoint MUST: endpoint MUST:
R2.1) Fill in the Pool Handle to specify which server pool the R2.1) Fill in the Pool Handle to specify which server pool the
ASAP endpoint wishes to join. ASAP endpoint wishes to join.
R2.2) Fill in a PE identifier using a good quality randomly R2.2) Fill in a PE identifier using a good quality randomly
generated number (RFC1750 [10] provides some information on generated number (RFC1750 [10] provides some information on
randomness guidelines). randomness guidelines).
skipping to change at page 17, line 7 skipping to change at page 18, line 7
R2.4) Fill in a User Transport Parameter for the type of transport R2.4) Fill in a User Transport Parameter for the type of transport
and the data/control channel usage the PE is willing to and the data/control channel usage the PE is willing to
support. Note, to join an existing server pool, the PE MUST support. Note, to join an existing server pool, the PE MUST
follow the overall transport type and overall data/control follow the overall transport type and overall data/control
channel usage of the pool. Otherwise, the registration may be channel usage of the pool. Otherwise, the registration may be
rejected by the ENRP server. rejected by the ENRP server.
R2.5) Fill in the preferred Member selection policy. R2.5) Fill in the preferred Member selection policy.
R2.6) PE does not need to fill in the ASAP transport parameter.
The ASAP transport TLV will be filled in and used by the home
ENRP server.
R3) Send the Registration request to the Home ENRP server using SCTP. R3) Send the Registration request to the Home ENRP server using SCTP.
R4) Start a T2-registration timer. R4) Start a T2-registration timer.
If the T2-registration timer expires before receiving a If the T2-registration timer expires before receiving an
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the received from the SCTP layer, the ASAP endpoint shall start the
Server Hunt procedure (see Section 3.6) in an attempt to get service Server Hunt procedure (see Section 3.6) in an attempt to get service
from a different ENRP server. After establishing a new Home ENRP from a different ENRP server. After establishing a new Home ENRP
server the ASAP endpoint SHOULD restart the registration procedure. server the ASAP endpoint SHOULD restart the registration procedure.
At the reception of the registration response, the ASAP endpoint MUST At the reception of the registration response, the ASAP endpoint MUST
stop the T2-Registration timer. If the response indicated success, stop the T2-Registration timer. If the response indicated success,
then the PE is now registered and will be considered an available then the PE is now registered and will be considered an available
member of the server pool. If the registration response indicates a member of the server pool. If the registration response indicates a
failure, the ASAP endpoint must either re-attempt registration after failure, the ASAP endpoint must either re-attempt registration after
correcting the error or return a failure indication to the ASAP correcting the error or return a failure indication to the ASAP
endpoints upper layer. The ASAP endpoint MUST NOT re-attempt endpoints upper layer. The ASAP endpoint MUST NOT re-attempt
registration without correcting the error condition. registration without correcting the error condition.
The registration response may also indicate that the registration is
accepted with a warning, often indicating that the ENRP server might
have made modifications to the value of some registration attribute
or attributes (such as policy type, transport usage, etc.). When
this happens, the PE SHOULD immediately notify its upper layer about
the registration modifications. This gives the upper layer a chance,
for example, to withdraw itself from the pool if such modifications
are unacceptable for its operation.
At any time a registered PE MAY wish to re-register to either update At any time a registered PE MAY wish to re-register to either update
its member selection policy value or registration expiration time. its member selection policy value or registration expiration time.
When re-registering the PE MUST use the same PE identifier. When re-registering the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration After successful registration the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting timer. At its expiration a re-registration SHOULD be made starting
at step R1 including (at completion) restarting the T4-reregistration at step R1 including (at completion) restarting the T4-reregistration
timer. timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
skipping to change at page 18, line 17 skipping to change at page 19, line 9
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:
D1) Fill in the Pool Handle parameter of the Deregistration message ( D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION
Section 2.2.2) using the same Pool Handle parameter sent during message ( Section 2.2.2) using the same Pool Handle parameter sent
registration. during registration.
D2) Fill in the PE Identifier. The identifier MUST be the same one D2) Fill in the PE Identifier. The identifier MUST be the same one
used during registration. used during registration.
D3) Send the deregistration message to the Home ENRP server using the D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server
SCTP association. using the SCTP association.
D4) Start a T3-Deregistration timer. D4) Start a T3-Deregistration timer.
If the T3-Deregistration timer expires before receiving a If the T3-Deregistration timer expires before receiving an
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the received from the SCTP layer, the ASAP endpoint shall start the
Server Hunt procedure (see Section 3.6) in an attempt to get service Server Hunt procedure (see Section 3.6) in an attempt to get service
from a different ENRP server. After establishing a new Home ENRP from a different ENRP server. After establishing a new Home ENRP
server the ASAP endpoint SHOULD restart the deregistration procedure. server the ASAP endpoint SHOULD restart the deregistration procedure.
At the reception of the deregistration response, the ASAP endpoint At the reception of the 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 Name resolution 3.3 Handle resolution
At any time a PE or PU may wish to resolve a name. This usually will At any time a PE or PU may wish to resolve a handle. This usually
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 name it MUST take the following actions: wishes to resolve a pool handle it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with
Handle to be resolved. the Pool Handle to be resolved.
NR2) If the endpoint does not have a Home ENRP server start the ENRP NR2) If the endpoint does not have a Home ENRP server start the ENRP
Server Hunt procedures specified in Section 3.6 to obtain one. Server Hunt procedures specified in Section 3.6 to obtain one.
Otherwise proceed to step NR3. Otherwise proceed to step NR3.
NR3) Send the NAME_RESOLUTION message to the Home ENRP server using NR3) Send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server
SCTP. using SCTP.
NR4) Start a T1-ENRPrequest timer. NR4) Start a T1-ENRPrequest timer.
If the T1-ENRPrequest timer expires before receiving a response If the T1-ENRPrequest timer expires before receiving a response
message, or a SEND.FAILURE notification is received from the SCTP message, the ASAP endpoint SHOULD take the steps described in
layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see Section 3.7.2. If a SEND.FAILURE notification is received from the
Section 3.6) in an attempt to get service from a different ENRP SCTP layer, the ASAP endpoint SHOULD start the Server Hunt procedure
(see Section 3.6) in an attempt to get service from a different ENRP
server. After establishing a new Home ENRP server the ASAP endpoint server. After establishing a new Home ENRP server the ASAP endpoint
SHOULD restart the name resolution procedure. SHOULD restart the handle resolution procedure.
At the reception of the response message (i.e., a At the reception of the response message (i.e., an
NAME_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-ENRPrequest ASAP_HANDLE_RESOLUTION_RESPONSE) the endpoint MUST stop its
timer. After stopping the T1 timer the endpoint SHOULD process the T1-ENRPrequest timer. After stopping the T1 timer the endpoint
name response as appropriate (e.g. populate a local cache, give the SHOULD process the pool handle response as appropriate (e.g.
response to the ASAP user, and/or use the response to send the ASAP populate a local cache, give the response to the ASAP user, and/or
users message). use the response to send the ASAP users message).
Note that some ASAP endpoints MAY use a cache to minimize the number Note that some ASAP endpoints MAY use a cache to minimize the number
of name resolutions made. If such a cache is used it SHOULD: of handle resolutions made. If such a cache is used it SHOULD:
C1) Be consulted before requesting a name resolution. C1) Be consulted before requesting a handle resolution.
C2) Have a stale timeout time associated with the cache so that even C2) Have a stale timeout time associated with the cache so that even
in the event of a cache-hit, if the cache is "stale" it will cause in the event of a cache-hit, if the cache is "stale" it will cause
a new name_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 C4) If the cache is NOT stale, the endpoint SHOULD NOT make a handle
name_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 a ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). Upon by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7).
reception of an ENDPOINT_KEEP_ALIVE message the following actions Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message the following
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 Registration. If the Pool the Pool Handle sent in its earlier ASAP_REGISTRATION. If the
Handle does not match silently discard the message. Pool Handle does not match silently discard the message.
KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by:
KA2.1) Filling in the Pool Handle Parameter with the PE's Pool KA2.1) Filling in the Pool Handle Parameter with the PE's Pool
Handle. Handle.
KA2.2) Fill in the PE Identifier that was used with this PE for KA2.2) Fill in the PE Identifier that was used with this PE for
registration. registration.
KA2.3) Send off the 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) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the KA2.4) Adopt the sender of the ASAP_ENDPOINT_KEEP_ALIVE message as
new home ENRP server. 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 ENDPOINT_UNREACHABLE message unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE
to its home ENRP server. The Endpoint should fill in the Pool Handle message to its home ENRP server. The Endpoint should fill in the
and PE identifier of the unreachable endpoint. If the sender is a PE Pool Handle and PE identifier of the unreachable endpoint. If the
the message MUST be sent via SCTP to the Endpoints Home ENRP server. sender is a PE the message MUST be sent via SCTP to the Endpoints
Note: an ASAP endpoint MUST report No more than once each time it Home ENRP server. Note: an ASAP endpoint MUST report No more than
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 a SERVER_ANNOUNE 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 a SERVER_ANNOUNCE message is received by a PU or PE it SHOULD If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE it
insert all new included transport address in its list of ENRP server SHOULD insert all new included transport address in its list of ENRP
addresses and start a T7-ENRPoutdate timer for each address. For all server addresses and start a T7-ENRPoutdate timer for each address.
already known addresses the T7-ENRPoutdate timers MUST be restarted. For all already known addresses the T7-ENRPoutdate timers MUST be
If no transport parameters are included in the SERVER_ANNOUNCE restarted. If no transport parameters are included in the
message the source IP address and the IANA registered ASAP port ASAP_SERVER_ANNOUNCE message the source IP address and the IANA
number are used instead. It is also assumed that the transport registered ASAP port number are used instead. It is also assumed
protocol used is SCTP. If a T7-ENRP timer for a transport address that the transport protocol used is SCTP. If a T7-ENRP timer for a
expires the corresponding address is deleted from the list of transport address expires the corresponding address is deleted from
transport addresses. the list of transport addresses.
If no multicast capabilities are used each PU and PE MUST have a If no multicast capabilities are used each PU and PE MUST have a
configured list of transport addresses of ENRP servers. configured list of transport addresses of ENRP servers.
At its startup, or when it fails to send to (i.e., timed-out on a At its startup, or when it fails to send to (i.e., timed-out on a
service request) with its current home ENRP server, a PE or PU shall service request) with its current home ENRP server, a PE or PU shall
establish its Home ENRP server, i.e. setup a TCP connection or SCTP establish its Home ENRP server, i.e. setup a TCP connection or SCTP
association with an ENRP server. association with an ENRP server.
To establish a new association or connection the following rules MUST To establish a new association or connection the following rules MUST
skipping to change at page 23, line 9 skipping to change at page 24, line 7
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 a Cookie Whenever a PE wants and a control channel exists it can send an
Message to the PU via the control channel. The ASAP layer at the PU ASAP_COOKIE Message to the PU via the control channel. The ASAP
stores the Cookie parameter and discards an older one if it is layer at the PU stores the Cookie parameter and discards an older one
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 a 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 a Business card IF the sender is also registered as a PE. SHOULD send an ASAP_BUSINESS_CARD IF the sender is also registered as
A PE may also send back to a PU a business card as well. A Business a PE. A PE may also send back to a PU a business card as well. An
card MUST NOT be sent if a control channel does NOT exist between the ASAP_BUSINESS_CARD MUST NOT be sent if a control channel does NOT
PU and PE. After communication as been established between a PE and exist between the PU and PE. After communication as been established
PU at any time either entity may update its failover distribution by between a PE and PU at any time either entity may update its failover
sending a new Business Card. distribution by sending a new ASAP_BUSINESS_CARD.
The business card serves two purposes (for both endpoints PU and PE). The business card serves two purposes (for both endpoints PU and PE).
First it lists the endpoints pool handle. For a PU contacting a PE First it lists the endpoints pool handle. For a PU contacting a PE
this is essential so that the PE may also gain the full benefits of this is essential so that the PE may also gain the full benefits of
ASAP if the PU is also a PE. Secondly the business card tells the ASAP if the PU is also a PE. Secondly the business card tells the
receiver a failover order that is recommended to follow. This may receiver a failover order that is recommended to follow. This may
facilitate rendezvous between PE's as well as some control of load facilitate rendezvous between PE's as well as some control of load
redistribution upon the failure of any given PE. redistribution upon the failure of any given PE.
Upon receipt of a Business Card Message (see Section 2.2.13) the Upon receipt of an ASAP_BUSINESS_CARD Message (see Section 2.2.13)
receiver SHOULD: the receiver SHOULD:
BC1) Unpack the business card, and if no entry exists in the BC1) Unpack the ASAP_BUSINESS_CARD, and if no entry exists in the
translation cache and one exists, populate the new Pool Handle translation cache and one exists, populate the new Pool Handle
into the cache and request a NAME.RESOLUTION of the pool handle. into the cache and request a handle resolution of the pool handle.
BC2) Create a list for this PE of preferred failover order so that in BC2) Create a list for this PE of preferred failover order so that in
the event of a failure the preferred list will be used to guide the event of a failure the preferred list will be used to guide
the ASAP endpoint in the selection of an alternate PE. the ASAP endpoint in the selection of an alternate PE.
4. The ASAP Interfaces 4. The ASAP Interfaces
This chapter will focus primarily on the primitives and notifications This chapter will focus primarily on the primitives and notifications
that form the interface between the ASAP-user and ASAP and that that form the interface between the ASAP-user and ASAP and that
between ASAP and its lower layer transport protocol (e.g., SCTP). between ASAP and its lower layer transport protocol (e.g., SCTP).
skipping to change at page 25, line 43 skipping to change at page 25, line 43
endpoint used to communicate with the ENRP server. endpoint used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the The ASAP user invokes this primitive to add itself to the
handlespace, thus becoming a Pool Element of a pool. The ASAP user handlespace, thus becoming a Pool Element of a pool. The ASAP user
must register itself with the ENRP server by using this primitive must register itself with the ENRP server by using this primitive
before other ASAP users using the handlespace can send message(s) to before other ASAP users using the handlespace can send message(s) to
this ASAP user by Pool Handle or by PE handle (see Section 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 a REGISTRATION message to the home ENRP server (See Section send an ASAP_REGISTRATION message to the home ENRP server (See
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 DEREGISTRATION message will be sent by ASAP endpoint to the home A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the
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 name 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 a NAME.RESOLUTION message on the Pool handle and query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle
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 NAME.RESOLUTION message is sent from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message
to the ENRP server for resolution. When the response message returns is sent to the ENRP server for resolution. When the response message
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 name 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 the Pool handle from its local cache. If the user passes a
Pool-Element-Handle then the Pool handle within is used for the Pool-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
skipping to change at page 27, line 25 skipping to change at page 27, line 25
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
need to perform Pool Element selection if multiple Pool Elements need to perform Pool Element selection if multiple Pool Elements
exist in the pool. exist in the pool.
If the senders ASAP implementation does not support a local cache of If the senders ASAP implementation does not support a local cache of
the mapping information or if it does not have the mapping the mapping information or if it does not have the mapping
information on the pool in its local cache, it will transmit a information on the pool in its local cache, it will transmit a
NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to
current home ENRP server, and MUST hold the outbound message in queue the current home ENRP server, and MUST hold the outbound message in
while awaiting the response from the ENRP server (any further send queue while awaiting the response from the ENRP server (any further
request to this pool before the ENRP server responds SHOULD also be send request to this pool before the ENRP server responds SHOULD also
queued). be queued).
Once the necessary mapping information arrives from the ENRP server, Once the necessary mapping information arrives from the ENRP server,
the senders ASAP will: the senders ASAP will:
A) map the pool handle into a list of transport addresses of the A) map the pool handle into a list of transport addresses of the
destination PE(s), destination PE(s),
B) if multiple PEs exist in the pool, ASAP will choose one of them B) if multiple PEs exist in the pool, ASAP will choose one of them
and transmit the message to it. In that case, the choice of the and transmit the message to it. In that case, the choice of the
PE is made by ASAP endpoint of the sender based on the server PE is made by ASAP endpoint of the sender based on the server
skipping to change at page 28, line 35 skipping to change at page 28, line 35
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).
Together with the server pooling policy, each PE can also specify a Together with the server pooling policy, each PE can also specify a
Policy Value for itself at the registration time. The meaning of the Policy Value for itself at the registration time. The meaning of the
policy value depends on the current server pooling policy of the policy value depends on the current server pooling policy of the
group. A PE can also change its policy value whenever it desires, by group. A PE can also change its policy value whenever it desires, by
re-registering itself with the handlespace with a new policy value. re-registering itself with the handlespace with a new policy value.
Re-registration shall be done by simply sending another REGISTRATION Re-registration shall be done by simply sending another
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 a ASAP endpoint sends messages by Pool Handle and Round-Robin is When an ASAP endpoint sends messages by Pool Handle and Round-Robin
the current policy of that Pool, the ASAP endpoint of the sender will is the current policy of that Pool, the ASAP endpoint of the sender
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
skipping to change at page 30, line 17 skipping to change at page 30, line 17
In addition, if a local translation cache is supported the endpoint In addition, if a local translation cache is supported the endpoint
will: will:
A) send out the message to the transport address (or association id) A) send out the message to the transport address (or association id)
designated by the PE handle. designated by the PE handle.
B) determine if the Pool Handle is in the local cache. B) determine if the Pool Handle is in the local cache.
If it is NOT, the endpoint will: If it is NOT, the endpoint will:
i) ask the home ENRP server for name resolution on pool handle by i) ask the home ENRP server for handle resolution on pool handle
sending a NAME.RESOLUTION message (see Section 2.2.5), and by sending an ASAP_HANDLE_RESOLUTION message (see
Section 2.2.5), and
ii) use the response to update the local cache. ii) use the response to update the local cache.
If the pool handle is in the cache, the endpoint will only If the pool handle is in the cache, the endpoint will only
update the pool handle if the cache is stale. A stale cache is update the pool handle if the cache is stale. A stale cache is
indicated by it being older than the protocol parameter indicated by it being older than the protocol parameter
'stale.cache.value' (see Section 5.2). 'stale.cache.value' (see Section 5.2).
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
skipping to change at page 32, line 22 skipping to change at page 32, line 22
Format: data.received(messageReceived, sizeOfMessage, senderAddress, Format: data.received(messageReceived, sizeOfMessage, senderAddress,
typeOfAddress) typeOfAddress)
When a new user message is received, the ASAP endpoint of the When a new user message is received, the ASAP endpoint of the
receiver uses this notification to pass the message to its upper receiver uses this notification to pass the message to its upper
layer. layer.
Along with the message being passed, the ASAP endpoint of the Along with the message being passed, the ASAP endpoint of the
receiver should also indicate to its upper layer the message senders receiver should also indicate to its upper layer the message senders
address. The senders address can be in the form of either an SCTP address. The senders address can be in the form of either an SCTP
association id, TCP transport address, UDP transport address, or a association id, TCP transport address, UDP transport address, or an
ASAP Pool Element handle. ASAP Pool Element handle.
A) If the name translation local cache is implemented at the A) If the handle translation local cache is implemented at the
receiver's ASAP endpoint, a reverse mapping from the senders IP receiver's ASAP endpoint, a reverse mapping from the 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.
skipping to change at page 33, line 20 skipping to change at page 33, line 20
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-name:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| 2. NAME_RESOLUTION +---+ | |2. ASAP_HANDLE_RESOLUTION +---+ |
|<-------------------------------| | |<-------------------------------| |
| +---+ | | +---+ |
| | 3 | | | | 3 | |
| 4. NAME_RESOLUTION_REPONSE +---+ | |4. ASAP_HANDLE_RESOLUTION_RSP +---+ |
|------------------------------->| | |------------------------------->| |
| +---+ | | +---+ |
| | 5 | | | | 5 | |
| +---+ 6. "hello1" | | +---+ 6. "hello1" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data.send.request("new-name", name-type, "hello1", 6, 0); data.send.request("new-handle", handle-type, "hello1", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-name" in The ASAP endpoint, in response, looks up the pool "new-handle" in
its local cache but fails to find it. its local cache but fails to find it.
2) The ASAP endpoint of PU queues the message, and sends a 2) The ASAP endpoint of PU queues the message, and sends an
NAME_RESOLUTION request to the ENRP server asking for all ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all
information about pool "new-name". information about pool "new-handle".
3) A T1-ENRPrequest timer is started while the ASAP endpoint is 3) A T1-ENRPrequest timer is started while the ASAP endpoint is
waiting for the response from the ENRP server. waiting for the response from the ENRP server.
4) The ENRP Server responds to the query with a 4) The ENRP Server responds to the query with an
NAME_RESOLUTION_REPONSE message that contains all the information ASAP_HANDLE_RESOLUTION_REPONSE message that contains all the
about pool "new-name". 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-name". cache with information on pool "new-handle".
6) Based on the server pooling policy of pool "new-name", ASAP at PU 6) Based on the server pooling policy of pool "new-handle", ASAP at
selects the destination PE (PEx), sets up, if necessary, an SCTP PU selects the destination PE (PEx), sets up, if necessary, an
association towards PEx (explicitly or implicitly), and send out SCTP association towards PEx (explicitly or implicitly), and send
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-name" after what happened in Section 4.8.1. message to the pool "new-handle" after what happened in
Section 4.8.1.
ENRP Server PU new-name:PEx ENRP Server PU new-handle:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello2" | | +---+ 2. "hello2" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
pdata.send.request("new-name", name-type, "hello2", 6, 0); pdata.send.request("new-handle", handle-type, "hello2", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-name" 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-name", 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 name 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 name cache or no name If the Pool handle does not exist in the local handle cache or no
cache exists, the ASAP endpoint will send a NAME.RESOLUTION request handle cache exists, the ASAP endpoint will send an
using the Pool-Handle. Upon completion of the name resolution, the ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon
ASAP endpoint should populate the local name cache (if a local name completion of the handle resolution, the ASAP endpoint should
cache is supported) and return the transport types, ports and populate the local handle cache (if a local handle cache is
addresses to the caller. supported) and return the transport types, ports and addresses to the
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 ENDPOINT_UNREACHABLE to the "home" ASAP endpoint. ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the
ENRP server in response to this primitive. Note ASAP SHOULD NOT send "home" ENRP server in response to this primitive. Note ASAP SHOULD
a ENDPOINT_UNREACHABLE UNLESS the user has actually made a previous NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually
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 a registration request T2-registration - A timer started when sending an ASAP_REGISTRATION
to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a deregistration
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T4-reregistration - This timer is started after successful T4-reregistration - This timer is started after successful
registration into the ASAP name space and is used to cause a registration into the ASAP handle space and is used to cause a
re-registration at a periodic interval. This timer is normally re-registration at a periodic interval. This timer is normally
set to 10 minutes or 20 seconds less than the Life Timer parameter set to 10 minutes or 20 seconds less than the Life Timer parameter
used in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 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 SERVER_ANNOUNCE messages. It is normally set to 1 consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to
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
skipping to change at page 37, line 29 skipping to change at page 37, line 29
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
Threat 1 and 2 taken together results in mutual authentication of the Threat 1 and 2 taken together results in mutual authentication of the
ENRP server and the PE. ENRP server and the PE.
Threat 3) Malicious ENRP server joins the ENRP server pool Threat 3) Malicious ENRP server joins the ENRP server pool
----------- -----------
Security mechanism in response: ENRP servers mutually authenticate Security mechanism in response: ENRP servers mutually authenticate
Threat 4) A PU communicates with a malicious ENRP server for name Threat 4) A PU communicates with a malicious ENRP server for handle
resolution resolution
----------- -----------
Security mechanism in response: The PU authenticates the ENRP server Security mechanism in response: The PU authenticates the ENRP server
Threat 5) Replay attack Threat 5) Replay attack
----------- -----------
Security mechanism in response: Security protocol which has Security mechanism in response: Security protocol which has
protection from replay attacks protection from replay attacks
Threat 6) Corrupted data which causes a PU to have misinformation Threat 6) Corrupted data which causes a PU to have misinformation
concerning a pool handle resolution concerning a pool handle resolution
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol which supports
integrity protection integrity protection
Threat 7) Eavesdropper snooping on handlespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP Threat 8) Flood of ASAP Endpoint_Unreachable messages from the PU to
server ENRP server
----------- -----------
Security mechanism in response: ASAP must control the number of Security mechanism in response: ASAP must control the number of ASAP
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
ENRP server the ENRP server
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of Endpoint_KeepAlive messages to the PE of ASAP_ENDPOINT_KEEP_AlIVE messages to the PE
To summarize the threats 1-7 require security mechanisms which To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection support authentication, integrity, data confidentiality, protection
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
skipping to change at page 38, line 34 skipping to change at page 38, line 34
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports protocols to provide the security services required. TLS supports
all these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of ASAP
Endpoint_Unreachable messages (see Section 3.5) 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
Endpoint_KeepAlive messages to the PE (see section x.y??? in [7]). ASAP_ENDPOINT_KEEP_ALIVE messages to the PE (see section x.y??? in
[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
skipping to change at page 41, line 9 skipping to change at page 41, line 9
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon
Ong, and many others for their invaluable comments. Ong, and many others for their invaluable comments.
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3",
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. and C. Allen, "The TLS Protocol Version 1.0", RFC [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
2246, January 1999. P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Name Resolution Server Access Protocol (ASAP) and Endpoint Handlespace
Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-07 Redundancy Protocol (ENRP) Parameters",
(work in progress), October 2004. Internet-Draft draft-ietf-rserpool-common-param-08, February
2005.
[6] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [6] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
"Architecture for Reliable Server Pooling", "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-07 (work in progress), October 2003. Internet-Draft draft-ietf-rserpool-arch-09, February 2005.
[7] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [7] Xie, Q., Stewart, R., Stillman, M., Tuexen, M. and A. Silverton,
Protocol (ENRP)", draft-ietf-rserpool-enrp-10 (work in "Endpoint Handlespace Redundancy Protocol (ENRP)",
progress), October 2004. Internet-Draft draft-ietf-rserpool-enrp-11, February 2005.
[8] Stillman, M., "Threats Introduced by Rserpool and Requirements [8] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-03 (work in progress), July 2004. Internet-Draft draft-ietf-rserpool-threats-04, January 2005.
[9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP",
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
Columbia, SC 29206 Columbia, SC 29206
USA USA
Phone: Phone:
EMail: rrs@cisco.com Email: rrs@cisco.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: Phone:
EMail: qxie1@email.mot.com Email: qxie1@email.mot.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: Phone:
EMail: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Germany Germany
Phone: Phone:
EMail: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 43, 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 (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

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