draft-ietf-rserpool-asap-03.txt   draft-ietf-rserpool-asap-04.txt 
Network Working Group R. R. Stewart Network Working Group R. Stewart
INTERNET-DRAFT Cisco Systems Inc. Internet-Draft Cisco Systems, Inc.
Q. Xie Expires: December 29, 2002 Q. Xie
Motorola Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen
expires in six months May 3, 2002 Siemens AG
June 30, 2002
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
<draft-ietf-rserpool-asap-03.txt> draft-ietf-rserpool-asap-04.txt
Status of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. Internet-Drafts are all provisions of Section 10 of RFC2026.
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/ietf/1id-abstracts.txt Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 December 29, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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) [ENRP] provides a high Endpoint Name Resolution Protocol (ENRP) [6] 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 name-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 In addition, ASAP defines each logical communication destination as a
as a pool, providing full transparent support for server-pooling pool, providing full transparent support for server-pooling and load
and load sharing. It also allows dynamic system scalability - sharing. It also allows dynamic system scalability - members of a
members of a server pool can be added or removed at any time server pool can be added or removed at any time without interrupting
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) [SCTP]. 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 transports mapping document. Note that ASAP messages passed between
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 interface for name to address translation, load sharing management,
management, and fault management while ENRP defines the high and fault management while ENRP defines the high availability name
availability name translation service. translation service.
Table Of Contents Table of Contents
1. Introduction............................................... 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Definitions............................................ 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Organization of this document.......................... 5 1.2 Organization of this document . . . . . . . . . . . . . . 7
1.3 Scope of ASAP.......................................... 5 1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Extent of the Namespace.......................... 5 1.3.1 Extent of the Namespace . . . . . . . . . . . . . . . . . 7
1.4 Conventions........................................... 5 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Message Definitions........................................ 6 2. Message Definitions . . . . . . . . . . . . . . . . . . . 8
2.1 ASAP Parameter Formats................................. 6 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8
2.2 ASAP Message Formats................................... 6 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 REGISTRATION message............................. 6 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9
2.2.2 DEREGISTRATION message........................... 7 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9
2.2.3 REGISTRATION_RESPONSE message.................... 7 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10
2.2.4 NAME_RESOLUTION message.......................... 8 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10
2.2.5 NAME_RESOLUTION_RESPONSE message................. 8 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11
2.2.6 NAME_UNKNOWN message............................. 9 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11
2.2.7 ENDPOINT_KEEP_ALIVE message...................... 9 2.2.7 NAME_UNKNOWN message . . . . . . . . . . . . . . . . . . . 12
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message.................. 9 2.2.8 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12
2.2.9 ENDPOINT_UNREACHABLE message ....................10 2.2.9 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 12
2.2.10 SERVER_HUNT message ............................10 2.2.10 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13
2.2.11 SERVER_HUNT_RESPONSE message....................10 2.2.11 SERVER_HUNT message . . . . . . . . . . . . . . . . . . . 13
3. Procedures.................................................11 2.2.12 SERVER_HUNT_RESPONSE message . . . . . . . . . . . . . . . 13
3.1 Registration............................................11 2.2.13 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Deregistration..........................................12 2.2.14 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14
3.3 Name resolution.........................................13 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Endpoint keep alive.....................................14 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Reporting unreachable endpoints.........................14 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 16
3.6 ENRP server hunt procedures.............................14 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 17
3.7 Handle ASAP to ENRP Communication Failures..............15 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 18
3.7.1 SCTP Send Failure................................15 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 19
3.7.2 T1-ENRPrequest Timer Expiration..................15 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 19
4. The ASAP Interfaces........................................16 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 20
4.1 Registration.Request Primitive.........................16 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 20
4.2 Deregistration.Request Primitive.......................16 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 20
4.3 Cache.Populate.Request Primitive.......................17 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 21
4.4 Cache.Purge.Request Primitive..........................17 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 22
4.5 Data.Send.Request Primitive............................17 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 22
4.5.1 Sending to a Pool Handle.........................18 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 22
4.5.2 Pool Element Selection...........................19 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 23
4.5.2.1 Round Robin Policy.......................19 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 23
4.5.2.2 Least Used Policy........................19 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 23
4.5.2.3 Least Used with Degradation Policy.......20 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 24
4.5.2.4 Weighted Round Robin Policy..............20 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 25
4.5.3 Sending to a Pool Element Handle.................20 4.5.2.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 25
4.5.4 Send by Transport Address........................21 4.5.2.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 25
4.5.5 Message Delivery Options........................21 4.5.2.3 Least Used with Degradation Policy . . . . . . . . . . . . 26
4.6 Data.Received Notification.............................22 4.5.2.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 26
4.7 Error.Report Notification..............................23 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 26
4.8 Examples...............................................23 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 27
4.8.1 Send to a New Pool Handle........................23 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 27
4.8.2 Send to a Cached Pool Handle.....................24 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 28
4.9 PE send failure........................................25 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 29
4.9.1 Translation.Request Primitive....................25 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9.2 Transport.Failure Primitive......................25 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 29
5. Variables, Timers, and Constants...........................25 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 31
5.1 Timers.................................................25 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 31
5.2 Thresholds.............................................26 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 31
6. Security Considerations....................................26 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 32
7. References.................................................27 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 33
8. Acknowledgments............................................27 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Authors' Addresses.........................................28 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . 36
Informational References (non-normative) . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
[ENRP] 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 name-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 endpoint and its physical IP address(es) which normally constitutes a
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 name, a.k.a, a
server pool, ASAP will select one Pool Element (PE), based on the server pool, ASAP will select one Pool Element (PE), based on the
current load sharing policy indicated by the server pool, and current load sharing policy indicated by the server pool, and deliver
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 high ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a
availability name space. ASAP is responsible for the abstraction of high availability name space. ASAP is responsible for the
the underlying transport technologies, load distribution management, abstraction of the underlying transport technologies, load
fault management, as well as the presentation to the upper layer distribution management, fault management, as well as the
(i.e., the ASAP user) a unified primitive interface. presentation to the upper layer (i.e., the ASAP user) a unified
primitive interface.
When SCTP [RFC2960] is used as the transport layer protocol, ASAP can When SCTP RFC2960 [4]. is used as the transport layer protocol, ASAP
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 server This document defines the ASAP portion of the high availability
pool. ASAP depends on the services of a high availability name space server pool. ASAP depends on the services of a high availability
a.k.a. ENRP. name space a.k.a. ENRP [6].
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ASAP User: ASAP User: Either a PE or PU that uses ASAP.
Either a PE or PU that uses ASAP.
Operation scope:
The part of the network visible to Pool Users by a specific Operation scope: The part of the network visible to Pool Users by a
instance of the reliable server pooling protocols. specific instance of the reliable server pooling protocols.
Server pool (or Pool): Server pool (or Pool): A collection of servers providing the same
A collection of servers providing the same application application functionality.
functionality.
Pool handle (or pool name): Pool handle (or pool name): A logical pointer to a pool. Each server
A logical pointer to a pool. Each server pool will be pool will be identifiable in the operation scope of the system by
identifiable in the operation scope of the system by a unique a unique pool handle or "name".
pool handle or "name".
Pool Element (PE): Pool Element (PE): A server entity having registered to a pool.
A server entity having registered to a pool.
Pool User (PU): Pool User (PU): A server Pool User.
A server Pool User.
Pool Element handle (PE handle): Pool Element handle (PE handle): A logical pointer to a particular
A logical pointer to a particular Pool Element in a pool, Pool Element in a pool,
ENRP server: ENRP server: A server program running on a host that manages the name
A server program running on a host that manages the space collectively with its peer ENRP servers and replies to the
name space collectively with its peer ENRP servers and service requests from any Pool User or Pool Element.
replies to the service requests from any Pool User or
Pool Element.
Home ENRP server: Home ENRP server: The ENRP server to which a Pool Element currently
The ENRP server to which a Pool Element currently uses. A PU uses. A PU or PE normally chooses the ENRP server on their local
or PE normally chooses the ENRP server on their local host as host as the home ENRP server (if one exists). A PU or PE should
the home ENRP server (if one exists). A PU or PE should only only have one home ENRP server at any given time. Note that the
have one home ENRP server at any given time. Note that the "home" ENRP server concept exists only within ASAP. ENRP servers
"home" ENRP server concept exists only within ASAP. ENRP provide no special handling of PE's or PU's. Having a "home" ENRP
servers provide no special handling of PE's or PU's. Having server only provides a mechanism to minimize the number of
a "home" ENRP server only provides a mechanism to minimize associations a given PE will have.
the number of associations a given PE will have.
ENRP client channel: ENRP client channel: The communication channel through which an ASAP
The communication channel through which an ASAP User (either a User (either a PE or PU) requests ENRP namespace service. The
PE or PU) requests ENRP namespace service. The client channel client channel is usually defined by the transport address of the
is usually defined by the transport address of the home server and a well known port number. The channel MAY make
home server and a well known port number. The channel MAY use of multi-cast or a named list of ENRP servers.
make use of multi-cast or a named list of ENRP servers.
ENRP server channel: ENRP server channel: Defined by a well known multicast IP address and
Defined by a well known multicast IP address and a well known port a well known port number, OR a well known list of transport
number, OR a well known list of transport addresses for a group of addresses for a group of ENRP servers spanning an operational
ENRP servers spanning an operational scope. All ENRP servers in an scope. All ENRP servers in an operation scope can communicate
operation scope can communicate with one another through this with one another through this channel via either multicast OR
channel via either multicast OR direct point to point SCTP direct point to point SCTP associations.
associations.
ENRP name domain: ENRP name domain: Defined by the combination of the ENRP client
Defined by the combination of the ENRP client channel and the channel and the ENRP server channel in the operation scope.
ENRP server channel in the operation scope.
Network Byte Order: Network Byte Order: Most significant byte first, a.k.a Big Endian.
Most significant byte first, a.k.a Big Endian.
Transport address: Transport address: A Transport Address is traditionally defined by
A Transport Address is traditionally defined by Network Layer Network Layer address, Transport Layer protocol and Transport
address, Transport Layer protocol and Transport Layer port Layer port number. In the case of SCTP running over IP, a
number. In the case of SCTP running over IP, a transport transport address is defined by the combination of an IP address
address is defined by the combination of an IP address and an and an SCTP port number (where SCTP is the Transport protocol).
SCTP port number (where SCTP is the Transport protocol).
1.2 Organization of this document 1.2 Organization of this document
Chapter 3 details ASAP message formats. In Chapter 4 we give the Section 2 details ASAP message formats. In Section 3 we give the
details of the ASAP interface, focusing on the communication detailed ASAP procedures for the ASAP implementer. And in Section 4
primitives between the applications above ASAP and ASAP itself, and we give the details of the ASAP interface, focusing on the
the communications primitives between ASAP and SCTP (or other communication primitives between the applications above ASAP and ASAP
transport layer). Also included in this discussion is relevant itself, and the communications primitives between ASAP and SCTP (or
timers and configurable parameters as appropriate. Chapter 5 other transport layer). Also included in this discussion is relevant
provides settable protocol values. timers and configurable parameters as appropriate. Section 5
provides threshold and protocol variables.
1.3 Scope of ASAP 1.3 Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during transaction failover. If a host or application fails during
processing of a transaction this transaction may be lost. Some processing of a transaction this transaction may be lost. Some
services may provide a way to handle the failure, but this is not services may provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself will NOT building a mechanism to share state but ASAP in itself will NOT share
share any state. any state.
1.3.1 Extent of the Namespace 1.3.1 Extent of the Namespace
The scope of the ASAP/ENRP is NOT Internet wide. The namespace is The scope of the ASAP/ENRP is NOT Internet wide. The namespace is
neither hierarchical nor arbitrarily large like DNS. We propose a neither hierarchical nor arbitrarily large like DNS. We propose a
flat peer-to-peer model. Pools of servers will exist in different flat peer-to-peer model. Pools of servers will exist in different
administrative domains. For example, suppose we want to use administrative domains. For example, suppose we want to use ASAP/
ASAP/ENRP. First, the PU may use DNS to contact an ENRP server. ENRP. First, the PU may use DNS to contact an ENRP server. Suppose
Suppose a PU in North America wishes to contact the server pool in a PU in North America wishes to contact the server pool in Japan
Japan instead of North America. The PU would use DNS to get the list of instead of North America. The PU would use DNS to get the list of IP
IP addresses of the Japanese server pool domain, that is, addresses of the Japanese server pool domain, that is, the ENRP
the ENRP client channel in Japan. From there the PU would query the client channel in Japan. From there the PU would query the ENRP
ENRP server and then directly contact the PE(s) of interest. server and then directly contact the PE(s) of interest.
1.4 Conventions 1.4 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. RFC2119 [2].
2. Message Definitions 2. Message Definitions
All messages as well as their fields described below shall be in All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length Network Byte Order during transmission. For fields with a length
bigger than 4 octets, a number in a pair of parentheses may follow bigger than 4 octets, a number in a pair of parentheses may follow
the filed name to indicate the length of the field in number of the field name to indicate the length of the field in number of
octets. octets.
2.1 ASAP Parameter Formats 2.1 ASAP Parameter Formats
The basic message format and all parameter formats can be found The basic message format and all parameter formats can be found in
in [ENRP-ASAP]. Note also that ALL ASAP message exchanged between ENRP-ASAP [5]. Note also that ALL ASAP message exchanged between the
the ENRP server and either a PE or PU MUST user SCTP. PE to PU ENRP server and either a PE or PU MUST user SCTP. PE to PU data
data traffic MAY use any transport protocol specified by the PE traffic MAY use any transport protocol specified by the PE during
during registration. registration.
2.2 ASAP Messages 2.2 ASAP Messages
This section details the individual messages used by ASAP. These This section details the individual messages used by ASAP. These
messages are composed of a standard message format found in messages are composed of a standard message format found in Section 4
Section 4 or [ENRP-ASAP], elements and parameters. The parameter or ENRP-ASAP [5]. The parameter descriptions may also be found in
descriptions may also be found in Section 3 of [ENRP-ASAP]. 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-0x06 - defined by [ENRP] 0x01 - Registration
0x07 - Registration 0x02 - Deregistration
0x08 - Deregistration 0x03 - Registration Response
0x09 - Registration Response 0x04 - Deregistration Response
0x0a - Name Resolution 0x05 - Name Resolution
0x0b - Name Resolution Response 0x06 - Name Resolution Response
0x0c - Name Unknown 0x07 - Name Unknown
0x0d - Endpoint Keep Alive 0x08 - Endpoint Keep Alive
0x0e - Endpoint Keep Alive Acknowledgement 0x09 - Endpoint Keep Alive Acknowledgement
0x0f - Endpoint Unreachable 0x0a - Endpoint Unreachable
0x10 - Server Hunt 0x0b - Server Hunt
0x11 - Server Hunt Response 0x0c - Server Hunt Response
0x0d - Cookie
0x0e - Cookie-Echo
2.2.1 REGISTRATION message 2.2.1 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 = 0x7 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the name to be registered. The pool handle parameter field specifies the name to be registered.
The PE Parameter field shall be filled in by the registrant endpoint The PE Parameter field shall be filled in by the registrant endpoint
to declare its transports and addresses, server pooling policy and to declare its transports and addresses, server pooling policy and
value, and other operation preferences. Note that the registration value, and other operation preferences. Note that the registration
message MUST use SCTP and the IP addresses of the PE registered message MUST use SCTP and the IP addresses of the PE registered
within the Pool Element Parameter MUST be a subset of the addresses within the Pool Element Parameter MUST be a subset of the addresses
of the SCTP association irrespective of the transport protocol of the SCTP association irrespective of the transport protocol
regestered by the PE. regestered by the PE.
2.2.2 DEREGISTRATION message 2.2.2 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 = 0x8 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier | | PE Identifier Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PE sending the DEREGISTRATION shall fill in the pool handle The PE sending the DEREGISTRATION shall fill in the pool handle and
and the PE identifier in order to allow the ENRP server to verify the PE identifier parameter in order to allow the ENRP server to
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 only a PE may only deregister allowed by proxy, in other words only a PE may only deregister
itself. itself.
2.2.3 REGISTRATION_RESPONSE message 2.2.3 REGISTRATION_RESPONSE message
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 = 0x3 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action code | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Error (optional) | | Operational Error (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operational Error
Action: (8 bits)
The message that this results code is in response to:
0x0 -- registration This optional TLV parameter is included if an error occured during
0x1 -- de-registration the registration process. If the registration was sucessful this
parameter is not included.
Reserved: (24 bits) 2.2.4 DEREGISTRATION_RESPONSE message
Ignored by the receiver and set to 0 by the sender. 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 = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Error (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Operational Error
This optional TLV parameter is included if an error This optional TLV parameter is included if an error occured during
occured during the registration/deregistration process. the deregistration process. If the deregistration was sucessful this
If the registration/deregistration was sucessful this
parameter is not included. parameter is not included.
2.2.4 NAME_RESOLUTION message 2.2.5 NAME_RESOLUTION message
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 = 0xa |0|0|0|0|0|0|0|0| Message Length | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server via an SCTP association to This message is sent to a ENRP server via an SCTP association to
request translation of the Pool Handle to a list of Pool Elements. request translation of the Pool Handle to a list of Pool Elements.
2.2.5 NAME_RESOLUTION_RESPONSE message 2.2.6 NAME_RESOLUTION_RESPONSE message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xb |0|0|0|0|0|0|0|0| Message Length | | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy : : Overall PE Selection Policy :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 : : Pool Element Parameter 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N : : Pool Element Parameter N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Overall PE Selection Policy: Overall PE Selection Policy:
This is a PE selection policy parameter. Indicates the overall selection This is a PE selection policy parameter. Indicates the overall
policy of the pool. If not present, round-robin is assumed. selection policy of the pool. If not present, round-robin is
assumed.
Note, any load policy parameter inside the Pool Element Parameter Note, any load policy parameter inside the Pool Element Parameter (if
(if present) MUST be ignored, and MUST NOT be used to determine present) MUST be ignored, and MUST NOT be used to determine the
the overall pool policy. overall pool policy.
2.2.6 NAME_UNKNOWN message 2.2.7 NAME_UNKNOWN message
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 = 0xc |0|0|0|0|0|0|0|0| Message Length | | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is returned by the ENRP server to indicate that This message is returned by the ENRP server to indicate that the
the requested Pool Handle hold no registered PE's. requested Pool Handle hold no registered PE's.
2.2.7 ENDPOINT_KEEP_ALIVE message 2.2.8 ENDPOINT_KEEP_ALIVE message
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 = 0xd |0|0|0|0|0|0|0|0| Message Length | | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a PE by the ENRP server has a "health" This message is sent to a PE by the ENRP server has a "health" check.
check. If the transport level Heart Beat mechanism is insufficient If the transport level Heart Beat mechanism is insufficient (usually
(usually this means that time outs are set for too long or this means that time outs are set for too long or heartbeats are not
heartbeats are not frequent enough), this adds heartbeat messages frequent enough), this adds heartbeat messages with the goal of
with the goal of determining health status in a more timely fashion. determining health status in a more timely fashion.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 2.2.9 ENDPOINT_KEEP_ALIVE_ACK message
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 = 0xe |0|0|0|0|0|0|0|0| Message Length | | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier | | PE Identifier Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ENDPOINT_KEEP_ALIVE message.
2.2.9 ENDPOINT_UNREACHABLE message 2.2.10 ENDPOINT_UNREACHABLE message
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 = 0xa |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier | | PE Identifier Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_HUNT message 2.2.11 SERVER_HUNT message
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 = 0x10 |0|0|0|0|0|0|0|0| Message Length : | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is used by either a PE or PU to request service. It This message is used by either a PE or PU to request service. It is
is sent on the ENRP client channel. sent on the ENRP client channel.
2.2.11 SERVER_HUNT_RESPONSE message 2.2.12 SERVER_HUNT_RESPONSE message
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 = 0x11 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is used by a ENRP server to respond to a PU or PE. It This message is used by a ENRP server to respond to a PU or PE. It
is sent over a specific SCTP association which is established using is sent over a specific SCTP association which is established using
the IP address and Port number received by the ENRP server in the the IP address and Port number received by the ENRP server in the
respective Server Hunt message that this message is in response to. respective Server Hunt message that this message is in response to.
2.2.13 COOKIE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by a PE to a PU.
2.2.14 COOKIE_ECHO message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
3. Procedures 3. Procedures
This chapter will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. failure detection and management are also discussed.
3.1 Registration 3.1 Registration
When a PE wishes to join its server pool it MUST use the procedures When a PE wishes to join its server pool it MUST use the procedures
outlined in this section to register. Often the registration will outlined in this section to register. Often the registration will be
be triggered by a user request primitive (discussed in Section 4.1). triggered by a user request primitive (discussed in Section 4.1).
The ASAP endpoint MUST register using an SCTP association between The ASAP endpoint MUST register using an SCTP association between the
the ASAP endpoint and the ENRP server. If the ASAP endpoint has not ASAP endpoint and the ENRP server. If the ASAP endpoint has not
established its Home ENRP server it MUST follow the procedures established its Home ENRP server it MUST follow the procedures
specified in Section 3.6 to establish its Home ENRP server. specified in Section 3.6 to establish its Home ENRP server.
Once the ASAP endpoint has established its Home ENRP server the Once the ASAP endpoint has established its Home ENRP server the
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 R1) The SCTP endpoint used to communicate with the ENRP server MUST
MUST be bound to all IP addresses that will be used by be bound to all IP addresses that will be used by the PE
the PE (irregardless of what protocol will be used to (irregardless of what protocol will be used to service user
service user requests to the PE). requests to the PE).
R2) The ASAP endpoint MUST formulate a Registration message R2) The ASAP endpoint MUST formulate a Registration message as
as defined in Section 2.2.1. In formulating the message defined in Section 2.2.1 In formulating the message the ASAP
the ASAP endpoint MUST: endpoint MUST:
R2.1) Fill in the the Pool Handle to specify which server pool the
ASAP endpoint wishes to join.
R2.1) Fill in the the Pool Handle to specify which
server pool the 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] provides some information generated number (RFC1750 [9] provides some information on
on randomness guidelines). randomness guidelines).
R2.3) Fill in the registration life time parameter with
the number of seconds that this registration is R2.3) Fill in the registration life time parameter with the number
good for. Note a PE that wishes to continue service of seconds that this registration is good for. Note a PE that
MUST re-register after the registration expires. wishes to continue service MUST re-register after the
R2.4) Fill in a User Transport Parameter for EACH type registration expires.
of transport the PE is willing to support.
R2.4) Fill in a User Transport Parameter for EACH type of
transport the PE is willing to support.
R2.5) Fill in the preferred Member selection policy. R2.5) Fill in the preferred Member selection policy.
R2.6) Fill in any optional authorization parameter,
if required. 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 a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the Server received from the SCTP layer, the ASAP endpoint shall start the
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 from a different ENRP server. After establishing a new Home ENRP
ENRP server the ASAP endpoint SHOULD restart the registration server the ASAP endpoint SHOULD restart the registration procedure.
procedure.
At the reception of the registration response, the ASAP endpoint At the reception of the registration response, the ASAP endpoint MUST
MUST stop the T2-Registration timer. If the response indicated stop the T2-Registration timer. If the response indicated success,
success, then the PE is now registered and will be considered an then the PE is now registered and will be considered an available
available member of the server pool. If the registration response member of the server pool. If the registration response indicates a
indicates a failure, the ASAP endpoint must either re-attempt failure, the ASAP endpoint must either re-attempt registration after
registration after correcting the error or return a failure correcting the error or return a failure indication to the ASAP
indication to the ASAP endpoints upper layer. The ASAP endpoint MUST endpoints upper layer. The ASAP endpoint MUST NOT re-attempt
NOT re-attempt registration without correcting the error condition. registration without correcting the error condition.
At any time a registered PE MAY wish to re-register to either update At any time a registered PE MAY wish to re-register to either update
its member selection policy value or registration expiration its member selection policy value or registration expiration time.
time. When re-registering the PE MUST use the same PE identifier. When re-registering the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration After successful registration the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting timer. At its expiration a re-registration SHOULD be made starting
at step R1 including (at completion) restarting the T4-reregistration at step R1 including (at completion) restarting the T4-reregistration
timer. timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
registration attempts it makes in a local variable. If repeated registration attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count registration time-outs or failures occurs and the local count exceeds
exceeds the Threshold 'max-reg-attempt' the implementation SHOULD the Threshold 'max-reg-attempt' the implementation SHOULD report the
report the error to its upper layer and stop attempting error to its upper layer and stop attempting registration.
registration.
3.2 Deregistration 3.2 Deregistration
In the event the PE wishes to deregister from its server pool In the event the PE wishes to deregister from its server pool
(normally via an upper layer requests see section 4.2) it SHOULD use (normally via an upper layer requests see Section 4.2) it SHOULD use
the following procedures. Note that an alternate method of the following procedures. Note that an alternate method of
deregistration is to NOT re-register and to allow the registration deregistration is to NOT re-register and to allow the registration
lift time to expire. lift time to expire.
When deregistering the PE SHOULD use the same SCTP association with When deregistering the PE SHOULD use the same SCTP association with
its Home ENRP server that was used for registration. To deregister its Home ENRP server that was used for registration. To deregister
the ASAP endpoint MUST take the following actions: the ASAP endpoint MUST take the following actions:
D1) Fill in the Pool Handle parameter of the Deregistration D1) Fill in the Pool Handle parameter of the Deregistration message (
message (Section 2.2.2) using the same Pool Handle parameter Section 2.2.2) using the same Pool Handle parameter sent during
sent during registration. registration.
D2) Fill in the PE Identifier. The identifier MUST be the same
one used during registration. D2) Fill in the PE Identifier. The identifier MUST be the same one
D3) Fill in any optional authorization parameter, if required. used during registration.
D4) Send the deregistration message to the Home ENRP server
using the SCTP association. D3) Send the deregistration message to the Home ENRP server using the
D5) Start a T3-Deregistration timer. SCTP association.
D4) Start a T3-Deregistration timer.
If the T3-Deregistration timer expires before receiving a If the T3-Deregistration timer expires before receiving a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is 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 server the ASAP endpoint SHOULD restart the deregistration procedure.
procedure.
At the reception of the deregistration response, the ASAP At the reception of the deregistration response, the ASAP endpoint
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 Name resolution
At any time a PE or PU may wish to resolve a name. This usually At any time a PE or PU may wish to resolve a name. This usually will
will occur when a Endpoint sends to a Pool handle (Section 4.5) occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or
or requests a cache population (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 name it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message (section 2.4) with NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool
the Pool Handle to be resolved. Handle to be resolved. z
NR2) Fill in any optional authorization parameter, as required.
NR2.1) If the endpoint does not have a Home ENRP server start NR2) If the endpoint does not have a Home ENRP server start the ENRP
the ENRP Server Hunt procedures specified in section Server Hunt procedures specified in Section 3.6 to obtain one.
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 SCTP. NR3) Send the NAME_RESOLUTION message to the Home ENRP server 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, or a SEND.FAILURE notification is received from the SCTP
layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see
Section 3.6) in an attempt to get service from a different ENRP 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 name resolution procedure.
At the reception of the response message (either a At the reception of the response message (either a
NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its
T1-ENRPrequest timer. After stopping the T1 timer the endpoint T1-ENRPrequest timer. After stopping the T1 timer the endpoint
SHOULD process the name response as appropriate (e.g. populate a SHOULD process the name response as appropriate (e.g. populate a
local cache, give the response to the ASAP user, and/or use the local cache, give the response to the ASAP user, and/or use the
response to send the ASAP users message). response to send the ASAP users message).
Note that some ASAP endpoints MAY use a cache to minimize Note that some ASAP endpoints MAY use a cache to minimize the number
the number of name resolutions made. If such a cache is used of name resolutions made. If such a cache is used it SHOULD:
it SHOULD:
C1) Be consulted before requesting a name resolution. C1) Be consulted before requesting a name resolution.
C2) Have a stale timeout time associated with the cache
so that even in the event of a cache-hit, if the C2) Have a stale timeout time associated with the cache so that even
cache is "stale" it will cause a new name_resolution in the event of a cache-hit, if the cache is "stale" it will cause
to be issued to update the cache. a new name_resolution to be issued to update the cache.
C3) In the case of a "stale" cache the implementation may
in parallel request an update and answer the request or C3) In the case of a "stale" cache the implementation may in parallel
block the user and wait for an updated cache before request an update and answer the request or block the user and
proceeding with the users request. wait for an updated cache before proceeding with the users
C4) If the cache is NOT stale, the endpoint SHOULD NOT request.
make a name_resolution request but instead return
the entry from the cache. C4) If the cache is NOT stale, the endpoint SHOULD NOT make a
name_resolution request but instead return 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 Periodically an ENRP server may choose to "audit" a PE. It does this
does this by sending a ENDPOINT_KEEP_ALIVE message by sending a ENDPOINT_KEEP_ALIVE message ( Section 2.2.8). Upon
(Section 2.2.7). Upon reception of an ENDPOINT_KEEP_ALIVE reception of an ENDPOINT_KEEP_ALIVE message the following actions
message the following actions MUST be taken: MUST be taken:
KA1) The PE must verify that the Pool Handle is correct KA1) The PE must verify that the Pool Handle is correct and matches
and matches the Pool Handle sent in its earlier the Pool Handle sent in its earlier Registration. If the Pool
Registration. If the Pool Handle does not match Handle does not match silently discard the message.
silently discard the message.
KA2) If an authorization parameter is included the KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.9) by:
endpoint SHOULD verify that the message is authentic. If
the verification fails, silently discard the message. KA2.1) Filling in the Pool Handle Parameter with the PE's Pool
KA3) Send a ENDPOINT_KEEP_ALIVE_ACK (section 2.2.8) by: Handle.
KA3.1) Filling in the Pool Handle Parameter with the
PE's Pool Handle. KA2.2) Fill in the PE Identifier that was used with this PE for
KA3.2) Fill in the PE Identifier that was used with this registration.
PE for registration.
KA3.3) Fill in any optional authorization parameter, KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the
as required. appropriate SCTP association for that ENRP server.
KA3.4) Send off the ENDPOINT_KEEP_ALIVE_ACK message via
the appropriate SCTP association for that 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 This may occur by a specific SCTP error realized by the ASAP endpoint
endpoint or via a ASAP user report via the Error.Report primitive or via a ASAP user report via the Transport.Failure Primitive
(section 4.7). In either case the ASAP endpoint SHOULD report the (Section 4.9.2). In either case the ASAP endpoint SHOULD report the
unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to
to its home ENRP server. The Endpoint should fill in the Pool Handle its home ENRP server. The Endpoint should fill in the Pool Handle
and PE identifier of the unreachable endpoint and any authorization and PE identifier of the unreachable endpoint. The message MUST be
parameter that may be required. The message MUST be sent via SCTP to sent via SCTP to the Endpoints Home ENRP server.
the Endpoints Home ENRP server.
3.6 ENRP server hunt procedures 3.6 ENRP server hunt procedures
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
initiate the following home ENRP server hunt procedure to find a initiate the following home ENRP server hunt procedure to find a new
new home server. home server.
SH1) The PE or PU shall send a SERVER_HUNT message (Section SH1) The PE or PU shall send a SERVER_HUNT message (Section 2.2.11)
2.2.10) over the ENRP client channel. If the client channel over the ENRP client channel. If the client channel is a multi-
is a multi-cast destination only one message is needed. If cast destination only one message is needed. If the client
the client channel is a set of uni-cast addresses then a channel is a set of uni-cast addresses then a message SHOULD be
message SHOULD be sent to no more than three ENRP server unicast sent to no more than three ENRP server unicast address. A
address. A Endpoint MUST NOT send to more than three at Endpoint MUST NOT send to more than three at any single time.
any single time.
SH2) The Endpoint shall start a T5-Serverhunt timer. SH2) The Endpoint shall start a T5-Serverhunt timer.
SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message the
the endpoint MUST stop its T5-Serverhunt timer. endpoint MUST stop its T5-Serverhunt timer. The Endpoint SHOULD
The Endpoint SHOULD also reset the T5-Serverhunt value also reset the T5-Serverhunt value to its initial value and then
to its initial value and then proceed to step SH5. proceed to step SH5.
SH4) If the T5-Serverhunt timer expires the following should be SH4) If the T5-Serverhunt timer expires the following should be
performed: performed:
SH4.1) The endpoint MUST double the value of the T5-Serverhunt timer.
SH4.2) The endpoint SHOULD Repeat sending a server hunt SH4.1) The endpoint MUST double the value of the T5-Serverhunt
message by proceeding to step SH1. Note that timer.
if the server hunt procedure are using a unicast channel
the endpoint SHOULD attempt to select a different set SH4.2) The endpoint SHOULD Repeat sending a server hunt message by
of ENRP servers to send the SERVER_HUNT message to. proceeding to step SH1. Note that if the server hunt procedure
are using a unicast channel the endpoint SHOULD attempt to
select a different set of ENRP servers to send the SERVER_HUNT
message to.
SH5) The PE or PU shall pick one of the ENRP servers that have SH5) The PE or PU shall pick one of the ENRP servers that have
responded as its new home ENRP server, and send all responded as its new home ENRP server, and send all its subsequent
its subsequent the namespace service requests to the namespace service requests to this new home ENRP server.
this new home ENRP server.
Upon the reception of the SERVER_HUNT message, an ENRP server shall Upon the reception of the SERVER_HUNT message, an ENRP server shall
always reply to the PE with a SERVER_HUNT_RESPONSE message. always reply to the PE with a SERVER_HUNT_RESPONSE message.
3.7 Handle ASAP to ENRP Communication Failures 3.7 Handle ASAP to ENRP Communication Failures
Three types of failure may occur when the ASAP endpoint at an endpoint Three types of failure may occur when the ASAP endpoint at an
tries to communicate with the ENRP server: endpoint tries to communicate with the ENRP server:
A) SCTP send failure A) SCTP send failure
B) T1-ENRPrequest timer expiration B) T1-ENRPrequest timer expiration
C) Registration failure C) Registration failure
Registration failure is discussed in section 4.1. Registration failure is discussed in Section 3.1
3.7.1 SCTP Send Failure 3.7.1 SCTP Send Failure
This indicates that the SCTP layer failed to deliver a message sent This indicates that the SCTP layer failed to deliver a message sent
to the ENRP server. In other words, the ENRP server is currently to the ENRP server. In other words, the ENRP server is currently
unreachable. unreachable.
In such a case, the ASAP endpoint should not re-send the failed In such a case, the ASAP endpoint should not re-send the failed
message. Instead, it should discard the failed message and start the message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section 3.6. ENRP server hunt procedure as described in Section 3.6
3.7.2 T1-ENRPrequest Timer Expiration 3.7.2 T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the When a T1-ENRPrequest timer expires, the ASAP should re-send the
original request to the ENRP server and re-start the T1-ENRPrequest original request to the ENRP server and re-start the T1-ENRPrequest
timer. In parallel, a SERVER_HUNT message should be issued per timer. In parallel, a SERVER_HUNT message should be issued per
Section 3.6. Section 3.6
This should be repeated up to 'max-request-retransmit' times. After This should be repeated up to 'max-request-retransmit' times. After
that, an Error.Report notification should be generated to inform the that, an Error.Report notification should be generated to inform the
ASAP user and the ENRP request message associated with the timer ASAP user and the ENRP request message associated with the timer
should be discarded. Note that if an alternate ENRP server responds should be discarded. Note that if an alternate ENRP server responds
the ASAP endpoint SHOULD adopt the responding ENRP server as its the ASAP endpoint SHOULD adopt the responding ENRP server as its new
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
Whenever a PE wants and a control channel exists it can send a Cookie
Message to the PU via the control channel. The ASAP layer at the PU
stores the Cookie parameter and discards an older one if it is
present.
If the ASAP layer detects a failure and initiates a failover to a
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
involved in the failover procedure.
This cookie mechanism can be used as a simple method for state
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
out of scope of this document. It is only important that the PU
stores always the last received Cookie Parameter and sends that back
unmodified in case of a PE failure.
4. The ASAP Interfaces 4. The ASAP Interfaces
This chapter will focus primarily on the primitives and This chapter will focus primarily on the primitives and notifications
notifications that form the interface between the ASAP-user and that form the interface between the ASAP-user and ASAP and that
ASAP and that between ASAP and its lower layer transport protocol between ASAP and its lower layer transport protocol (e.g., SCTP).
(e.g., SCTP).
An ASAP User passes primitives to the ASAP sub-layer to An ASAP User passes primitives to the ASAP sub-layer to request
request certain actions. Upon the completion of those actions or certain actions. Upon the completion of those actions or upon the
upon the detection of certain events, the ASAP will notify the detection of certain events, the ASAP will notify the ASAP user.
ASAP user.
4.1 Registration.Request Primitive 4.1 Registration.Request Primitive
Format: registration.request(poolHandle, Format: registration.request(poolHandle,
User Transport parameter(s)) User Transport parameter(s))
The poolHandle parameter contains a NULL terminated ASCII The poolHandle parameter contains a NULL terminated ASCII string of
string of fixed length. The optional User Transport parameter(s) fixed length. The optional User Transport parameter(s) indicate
indicate specific transport parameters and types to register with. specific transport parameters and types to register with. If this
If this optional parameter is left off, then the SCTP endpoint optional parameter is left off, then the SCTP endpoint used to
used to communicate with the ENRP server is used as the default communicate with the ENRP server is used as the default User
User Transport parameter. Note that any IP address contained Transport parameter. Note that any IP address contained within a
within a User Transport parameter MUST be a bound IP address in User Transport parameter MUST be a bound IP address in the SCTP
the SCTP endpoint used to communicate with the ENRP server. endpoint used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the The ASAP user invokes this primitive to add itself to the namespace,
namespace, thus becoming a Pool Element of a pool. The ASAP user thus becoming a Pool Element of a pool. The ASAP user must register
must register itself with the ENRP server by using this primitive itself with the ENRP server by using this primitive before other ASAP
before other ASAP users using the namespace can send message(s) to users using the namespace can send message(s) to this ASAP user by
this ASAP user by Pool Handle or by PE handle (see Sections 4.5.1 Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3).
and 4.5.2).
In response to the registration primitive, the ASAP endpoint will send In response to the registration primitive, the ASAP endpoint will
a REGISTRATION message to the home ENRP server (See Section 2.2.1 and send a REGISTRATION message to the home ENRP server (See Section
Section 3.1), and start a T2-registration timer. 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 The ASAP PE invokes this primitive to remove itself from the Server
Server Pool. This should be used as a part of the graceful shutdown Pool. This should be used as a part of the graceful shutdown process
process by the application. by the application.
A DEREGISTRATION message will be sent by ASAP endpoint to the home ENRP A DEREGISTRATION message will be sent by ASAP endpoint to the home
server (see Section 2.2.2 and Section 3.2). 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 | Pool-Element-Handle]) Format: cache.populate.request([Pool-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 name translation
cache exists, the ASAP endpoint should initiate a mapping cache exists, the ASAP endpoint should initiate a mapping information
information query by sending a NAME.RESOLUTION message on the Pool query by sending a NAME.RESOLUTION message on the Pool handle and
handle and update it local cache when the response comes back from update it local cache when the response comes back from the ENRP
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 NAME.RESOLUTION message is sent
to the ENRP server for resolution. When the response message returns to the ENRP server for resolution. When the response message returns
from the ENRP server the local cache is updated. from the ENRP server the local cache is updated.
Note that if the ASAP service does NOT support a local cache Note that if the ASAP service does NOT support a local cache this
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 name 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-
Pool-Element-Handle then the Pool handle within is used for the Element-Handle then the Pool handle within is used for the
cache.purge.request. cache.purge.request.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.5 Data.Send.Request Primitive 4.5 Data.Send.Request Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data.send.request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified This primitive requests ASAP to send a message to some specified Pool
Pool or Pool Element within the current Operational scope. or Pool Element within the current Operational scope.
Depending on the address type used for the send request, the Depending on the address type used for the send request, the senders
senders ASAP endpoint may perform address translation and Pool ASAP endpoint may perform address translation and Pool Element
Element selection before sending the message out. This also MAY selection before sending the message out. This also MAY dictate the
dictate the creation of a local transport endpoint in order to meet creation of a local transport endpoint in order to meet the required
the required transport type. transport type.
The data.send.request primitive can take different forms of address The data.send.request primitive can take different forms of address
types as described in the following sections. types as described in the following sections.
4.5.1 Sending to a Pool Handle 4.5.1 Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a pool handle. indicates a pool handle.
This is the simplest form of send.data.request primitive. By This is the simplest form of send.data.request primitive. By
default, this directs ASAP to send the message to one of the Pool default, this directs ASAP to send the message to one of the Pool
Elements in the specified pool. Elements in the specified pool.
Before sending the message out to the pool, the senders ASAP Before sending the message out to the pool, the senders ASAP endpoint
endpoint MUST first perform a pool handle to address translation. It MUST first perform a pool handle to address translation. It may also
may also need to perform Pool Element selection if multiple Pool need to perform Pool Element selection if multiple Pool Elements
Elements exist in the pool. exist in the pool.
If the senders ASAP implementation does not support a local cache If the senders ASAP implementation does not support a local cache of
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.4 and Section 3.3) to the NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the
current home ENRP server, and MUST hold the outbound message in current home ENRP server, and MUST hold the outbound message in queue
queue while awaiting the response from the ENRP server (any further while awaiting the response from the ENRP server (any further send
send request to this pool before the ENRP server responds SHOULD request to this pool before the ENRP server responds SHOULD also be
also be queued). queued).
Once the necessary mapping information arrives from the ENRP server, Once the necessary mapping information arrives from the ENRP server,
the senders ASAP will: the 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 B) if multiple PEs exist in the pool, ASAP will choose one of them
one of them and transmit the message to it. In that case, the and transmit the message to it. In that case, the choice of the
choice of the PE is made by ASAP endpoint of the sender based on PE is made by ASAP endpoint of the sender based on the server
the server pooling policy as discussed in section 4.5.2. pooling policy as discussed in Section 4.5.2
C) Optionally create any transport endpoint that may be needed to C) Optionally create any transport endpoint that may be needed to
communicate with the PE selected. communicate with the PE selected.
D) if no transport association or connection exists towards the D) if no transport association or connection exists towards the
destination PE, ASAP will establish any needed transport state, destination PE, ASAP will establish any needed transport state,
E) send out the queued message(s) to the appropriate transport E) send out the queued message(s) to the appropriate transport
connection using the appropriate send mechanism (e.g. for connection using the appropriate send mechanism (e.g. for SCTP
SCTP the SEND primitive in [RFC2960] would be used), and, the SEND primitive in RFC2960 [4] would be used), and,
F) if the local cache is implemented, append/update the local cache F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g. response. Also, record the local transport information (e.g. the
the SCTP association id) if any new transport state was created. SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures see [ENRP]. For more on the ENRP server request procedures see ENRP [6].
Optionally, the ASAP endpoint of the sender may return a Pool Element Optionally, the ASAP endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that same PE (see Section 4.5.3). that same PE (see Section 4.5.3).
Section 4.5.5 defines the fail-over procedures for cases where the Section 3.7 defines the fail-over procedures for cases where the
selected PE is found unreachable. selected PE is found unreachable.
4.5.2 Pool Element Selection 4.5.2 Pool Element Selection
Each time an ASAP user sends a message to a pool that contains more Each time an ASAP user sends a message to a pool that contains more
than one PE, the senders ASAP endpoint must select one of the PEs than one PE, the senders ASAP endpoint must select one of the PEs in
in the pool as the receiver of the current message. The selection is the pool as the receiver of the current message. The selection is
done according to the current server pooling policy of the pool to done according to the current server pooling policy of the pool to
which the message is sent. which the message is sent.
Note, no selection is needed if the ASAP_SEND_TOALL option is set Note, no selection is needed if the ASAP_SEND_TOALL option is set
(see Section 4.5.5). (see Section 4.5.5).
Together with the server pooling policy, each PE can also Together with the server pooling policy, each PE can also specify a
specify a Policy Value for itself at the registration time. The Policy Value for itself at the registration time. The meaning of the
meaning of the policy value depends on the current server pooling policy value depends on the current server pooling policy of the
policy of the group. A PE can also change its policy value whenever group. A PE can also change its policy value whenever it desires, by
it desires, by re-registering itself with the namespace with a new re-registering itself with the namespace with a new policy value.
policy value. Re-registration shall be done by simply sending Re-registration shall be done by simply sending another REGISTRATION
another REGISTRATION to its home ENRP server (See section 3.1). 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 When a ASAP endpoint sends messages by Pool Handle and Round-Robin is
is the current policy of that Pool, the ASAP endpoint of the sender the current policy of that Pool, the ASAP endpoint of the sender will
will select the receiver for each outbound message by round-Robining select the receiver for each outbound message by round-Robining
through all the registered PEs in that Pool, in an attempt to through all the registered PEs in that Pool, in an attempt to achieve
achieve an even distribution of outbound messages. Note that in a an even distribution of outbound messages. Note that in a large
large server pool, the ENRP server MAY NOT send back all PEs to the server pool, the ENRP server MAY NOT send back all PEs to the ASAP
ASAP client. In this case the client or PU will be performing a client. In this case the client or PU will be performing a round
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 that policy, the ASAP endpoint of the message sender will select the PE
has the lowest policy value in the group as the receiver of the that has the lowest policy value in the group as the receiver of the
current message. If more than one PE from the group share the same current message. If more than one PE from the group share the same
lowest policy value, the selection will be done round Robin amongst lowest policy value, the selection will be done round Robin amongst
those PEs. those PEs.
It is important to note that this policy means that the same PE will It is important to note that this policy means that the same PE will
be always selected as the message receiver by the sender until the be always selected as the message receiver by the sender until the
load control information of the pool is updated and changed in the load control information of the pool is updated and changed in the
local cache of the sender (via a cache update see section 3.3). local cache of the sender (via a cache update see Section 3.3).
4.5.2.3 Least Used with Degradation Policy 4.5.2.3 Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception This policy is the same as the Least Used policy with the exception
that, each time the PE with the lowest policy value is selected from that, each time the PE with the lowest policy value is selected from
the Pool as the receiver of the current message, its policy value is the Pool as the receiver of the current message, its policy value is
incremented, and thus it may no longer be the lowest value in the incremented, and thus it may no longer be the lowest value in the
Pool. Pool.
This provides a degradation of the policy towards round Robin policy This provides a degradation of the policy towards round Robin policy
skipping to change at page 20, line 36 skipping to change at page 26, line 40
4.5.3 Sending to a Pool Element Handle 4.5.3 Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate an ASAP Pool Element handle. indicate an ASAP Pool Element handle.
This requests the ASAP endpoint to deliver the message to the PE This requests the ASAP endpoint to deliver the message to the PE
identified by the Pool Element handle. identified by the Pool Element handle.
The Pool Element handle should contain the Pool Handle and a The Pool Element handle should contain the Pool Handle and a
destination transport address of the destination PE or the destination transport address of the destination PE or the Pool
Pool Handle and the transport type. Other implementation Handle and the transport type. Other implementation dependant
dependant elements may also be cached in a Pool Element handle. elements may also be cached in a Pool Element handle.
The ASAP endpoint shall use the transport address and transport type The ASAP endpoint shall use the transport address and transport type
to identify the endpoint to communicate with. If no communication to identify the endpoint to communicate with. If no communication
state exists with the peer endpoint (and is required by the state exists with the peer endpoint (and is required by the transport
transport protocol) the ASAP endpoint MAY setup the needed state and protocol) the ASAP endpoint MAY setup the needed state and then
then invoke the SEND primitive for the particular transport invoke the SEND primitive for the particular transport protocol to
protocol to send the message to the PE. send the message to the PE.
In addition, if a local translation cache is supported the In addition, if a local translation cache is supported the endpoint
endpoint will: will:
A) send out the message to the transport address (or association A) send out the message to the transport address (or association id)
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 i) ask the home ENRP server for name resolution on pool handle by
by sending a NAME.RESOLUTION message (see Section 3.3), and sending a NAME.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 3.3). 'stale.cache.value' (see Section 5.2).
Section 3.5 and 4.9 defines the fail-over procedures for cases where Section 3.5 and Section 4.9 defines the fail-over procedures for
the PE pointed to by the Pool Element handle is found unreachable. cases where the PE pointed to by the Pool Element handle is found
unreachable.
Optionally, the ASAP endpoint may return the actual Pool Element handle Optionally, the ASAP endpoint may return the actual Pool Element
to which the message was sent (this may be different from the Pool handle to which the message was sent (this may be different from the
Element handle specified when the primitive is invoked, due to the Pool Element handle specified when the primitive is invoked, due to
possibility of automatic fail-over). the possibility of automatic fail-over).
4.5.4 Send by Transport Address 4.5.4 Send by Transport Address
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate a transport address and transport type. indicate a transport address and transport type.
This directs the senders ASAP endpoint to send the message out to the This directs the senders ASAP endpoint to send the message out to the
specified transport address. specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint fail-over is support when this form of send request is
skipping to change at page 21, line 43 skipping to change at page 28, line 8
4.5.5 Message Delivery Options 4.5.5 Message Delivery Options
The Options parameter passed in the various forms of the above The Options parameter passed in the various forms of the above
data.send.request primitive gives directions to the senders ASAP data.send.request primitive gives directions to the senders ASAP
endpoint on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise "OR"ing The value of the Options parameter is generated by bit-wise "OR"ing
of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 ASAP_USE_DEFAULT: 0x0000 Use default setting.
Use default setting.
ASAP_SEND_FAILOVER: 0x0001
Enables PE fail-over on this message. In case where the first
selected PE or the PE pointed to by the PE handle is found
unreachable, this option allows the senders ASAP endpoint to
re-select an alternate PE from the same pool if one exists, and
silently re-send the message to this newly selected endpoint.
ASAP_SEND_NO_FAILOVER: 0x0002
This option prohibits the senders ASAP endpoint from re-sending the
message to any alternate PE in case that the first selected PE or
the PE pointed to by the PE handle is found unreachable. Instead,
the senders ASAP endpoint shall notify its upper layer about the
unreachability with an Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004
This option requests the senders ASAP endpoint to send the message to
the same PE in the pool that the previous message destined to this
pool was sent to.
ASAP_SEND_TO_ALL: 0x0008 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In
case where the first selected PE or the PE pointed to by the PE
handle is found unreachable, this option allows the senders ASAP
endpoint to re-select an alternate PE from the same pool if one
exists, and silently re-send the message to this newly selected
endpoint.
When sending by Pool Handle, this option directs the senders ASAP ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP
endpoint to send a copy of the message to all the PEs, except for endpoint from re-sending the message to any alternate PE in case
the sender itself if the sender is a PE, in that pool. that the first selected PE or the PE pointed to by the PE handle
is found unreachable. Instead, the senders ASAP endpoint shall
notify its upper layer about the unreachability with an
Error.Report and return any unsent data.
ASAP_SEND_TO_SELF: 0x0010. ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP
endpoint to send the message to the same PE in the pool that the
previous message destined to this pool was sent to.
This option only applies in combination with ASAP_SEND_TO_ALL option. ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option
It permits the senders ASAP endpoint also deliver a copy of the directs the senders ASAP endpoint to send a copy of the message to
message to itself if the sender is a PE of the pool (i.e., loop-back). all the PEs, except for the sender itself if the sender is a PE,
in that pool.
ASAP_SCTP_UNORDER: 0x1000 ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination
with ASAP_SEND_TO_ALL option. It permits the senders ASAP
endpoint also deliver a copy of the message to itself if the
sender is a PE of the pool (i.e., loop-back).
This option requests the transport layer to send the current ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to
message using un-ordered delivery (note the underlying transport send the current message using un-ordered delivery (note the
must support un-ordered delivery for this option to be effective). underlying transport must support un-ordered delivery for this
option to be effective).
4.6 Data.Received Notification 4.6 Data.Received Notification
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 receiver
uses this notification to pass the message to its upper layer.
Along with the message being passed, the ASAP endpoint of the receiver When a new user message is received, the ASAP endpoint of the
should also indicate to its upper layer the message senders receiver uses this notification to pass the message to its upper
layer.
Along with the message being passed, the ASAP endpoint of the
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 association id, TCP transport address, UDP transport address, or a
a ASAP Pool Element handle. ASAP Pool Element handle.
A) If the name translation local cache is implemented at the A) If the name 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 is address to the pool handle should be performed and if the mapping
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 successful, the SCTP association id or other transport specific
specific identification (if SCTP is not being used) should be identification (if SCTP is not being used) should be passed in the
passed in the senderAddress field. senderAddress field.
4.7 Error.Report Notification 4.7 Error.Report Notification
Format: error.report(destinationAddress, typeOfAddress, Format: error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage) failedMessage, sizeOfMessage)
An error.report should be generated to notify the ASAP user about An error.report should be generated to notify the ASAP user about
failed message delivery as well as other abnormalities. failed message delivery as well as other abnormalities.
The destinationAddress and typeOfAddress together indicates to whom The destinationAddress and typeOfAddress together indicates to whom
the message was originally sent. The address type can be either a the message was originally sent. The address type can be either a
ASAP Pool Element handle, association id, or a transport address. ASAP Pool Element handle, association id, or a transport address.
The original message (or the first portion of it if the message is The original message (or the first portion of it if the message is
too big) and its size should be passed in the failedMessage and too big) and its size should be passed in the failedMessage and
sizeOfMessage fields, respectively. sizeOfMessage fields, respectively.
4.8 Examples 4.8 Examples
These examples assume an underlying SCTP transport between the PE These examples assume an underlying SCTP transport between the PE and
and PU. Other transports are possible but SCTP is utilized in the PU. Other transports are possible but SCTP is utilized in the
examples for illustrative purposes. Note that all communication examples for illustrative purposes. Note that all communication
between PU and ENRP server and PE and ENRP servers would be using between PU and ENRP server and PE and ENRP servers would be using
SCTP. SCTP.
4.8.1 Send to a New Pool 4.8.1 Send to a New Pool
This example shows the event sequence when a Pool User sends the This example shows the event sequence when a Pool User sends the
message "hello" to a pool which is not in the local message "hello" to a pool which is not in the local translation cache
translation cache (assuming local caching is supported). (assuming local caching is supported).
ENRP Server PU new-name:PEx ENRP Server PU new-name:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| 2. NAME_RESOLUTION +---+ | | 2. NAME_RESOLUTION +---+ |
|<-------------------------------| | |<-------------------------------| |
| +---+ | | +---+ |
| | 3 | | | | 3 | |
| 4. NAME_RESOLUTION_REPONSE +---+ | | 4. NAME_RESOLUTION_REPONSE +---+ |
|------------------------------->| | |------------------------------->| |
| +---+ | | +---+ |
| | 5 | | | | 5 | |
| +---+ 6. "hello1" | | +---+ 6. "hello1" |
| |---------------->| | |---------------->|
| | | | | |
skipping to change at page 24, line 7 skipping to change at page 30, line 26
| +---+ | | +---+ |
| | 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-name", name-type, "hello1", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-name" in its The ASAP endpoint, in response, looks up the pool "new-name" in
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 a
NAME_RESOLUTION request to the ENRP server asking for all NAME_RESOLUTION request to the ENRP server asking for all
information about pool "new-name". information about pool "new-name".
3) A T1-ENRPrequest timer is started while the ASAP endpoint is waiting 3) A T1-ENRPrequest timer is started while the ASAP endpoint is
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 a
NAME_RESOLUTION_REPONSE message that contains all the information NAME_RESOLUTION_REPONSE message that contains all the information
about pool "new-name". about pool "new-name".
5) ASAP at PU cancels the T1-ENRPrequest timer and populate its 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local
local cache with information on pool "new-name". cache with information on pool "new-name".
6) Based on the server pooling policy of pool "new-name", ASAP at 6) Based on the server pooling policy of pool "new-name", ASAP at PU
PU selects the destination PE (PEx), sets up, if necessary, an selects the destination PE (PEx), sets up, if necessary, an SCTP
SCTP association towards PEx (explicitly or implicitly), and association towards PEx (explicitly or implicitly), and send out
send out the queued "hello1" user message. 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 This shows the event sequence when the ASAP user PU sends another
another message to the pool "new-name" after what happened in message to the pool "new-name" after what happened in Section 4.8.1.
Section 4.8.1.
ENRP Server PU new-name:PEx ENRP Server PU new-name:PEx
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello2" | | +---+ 2. "hello2" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data.send.request("new-name", name-type, "hello2", 6, 0); pdata.send.request("new-name", name-type, "hello2", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-name" in its The ASAP endpoint, in response, looks up the pool "new-name" in
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-name", 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 "hello2" message (assume the SCTP association is already set up).
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 PE and fails the failed sender will report the event as described in
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 If the address type is a Pool handle and a local name translation
translation cache exists, the ASAP endpoint should look within cache exists, the ASAP endpoint should look within its translation
its translation cache and return the current known transport cache and return the current known transport types, ports and
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 name cache or no name
cache exists, the ASAP endpoint will send a NAME.RESOLUTION request cache exists, the ASAP endpoint will send a NAME.RESOLUTION request
using the Pool-Handle. Upon completion of the name resolution, the using the Pool-Handle. Upon completion of the name resolution, the
ASAP endpoint should populate the local name cache (if a local name ASAP endpoint should populate the local name cache (if a local name
cache is supported) and return the transport types, ports and cache is supported) and return the transport types, ports and
addresses to the caller. 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 NOT using ASAP it can use this primitive to report the failure to the
the ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home"
ENRP server in response to this primitive. Note ASAP SHOULD NOT send ENRP server in response to this primitive. Note ASAP SHOULD NOT send
a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous
request to the translate.request() primitive. request to the translate.request() primitive.
5. Variables, Timers, and Constants 5. Variables, Timers, and Thresholds
The following is a summary of the variables, timers, and pre-set The following is a summary of the variables, timers, 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 the ENRP server (providing application information is queued).
queued). Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending a registration T2-registration - A timer started when sending a registration request
request to the home ENRP server, normally set to 30 seconds. 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 name space and is used to cause a re-
re-registration at a periodic interval. This timer is normally set registration at a periodic interval. This timer is normally set
to 10 minutes or 20 seconds less than the Life Timer parameter used to 10 minutes or 20 seconds less than the Life Timer parameter
in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used nto during the ENRP server hunt T5-Serverhunt - This timer is used nto during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
5.2 Thresholds and Variables 5.2 Thresholds and Variables
max-reg-attempt - The maximum number of registration attempts to be max-reg-attempt - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
max-request-retransmit - The maximum number of attempts to be made max-request-retransmit - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
stale.cache.value - A threshold variable that indicates how long stale.cache.value - A threshold variable that indicates how long a
a cache entry is valid for. cache entry is valid for.
6. Security Considerations 6. Security Considerations
Due to varying requirements and multiple use cases of Rserpool, we Due to varying requirements and multiple use cases of Rserpool, we
point out two basic security protocols, IPsec and TLS. We point out two basic security protocols, IPsec and TLS. We
specifically do not discuss whether one security protocol would be specifically do not discuss whether one security protocol would be
preferred over the other. This choice will be made by designers preferred over the other. This choice will be made by designers and
and network architects based on system requirements. network architects based on system requirements.
For networks that demand IPsec security, implementations MUST For networks that demand IPsec security, implementations MUST support
support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below
layers below RSerPool. Therefore, if IPsec is used for securing RSerPool. Therefore, if IPsec is used for securing Rserpool, no
Rserpool, no changes or special considerations need to be made to changes or special considerations need to be made to Rserpool to
Rserpool to secure the protocol. secure the protocol.
For networks that cannot or do not wish to use IPsec and prefer For networks that cannot or do not wish to use IPsec and prefer
instead TLS, implementations MUST support TLS with SCTP as instead TLS, implementations MUST support TLS with SCTP as described
described in [SCTPTLS] or TLS over TCP as described in [RFC2246]. in SCTPTLSls [8] or TLS over TCP as described in RFC2246 [3] When
When using TLS/SCTP we must ensure that RSerPool does not use any using TLS/SCTP we must ensure that RSerPool does not use any features
features of SCTP that are not available to an TLS/SCTP user. This of SCTP that are not available to an TLS/SCTP user. This is not a
is not a difficult technical problem, but simply a difficult technical problem, but simply a requirement. When
requirement. When describing an API of the RSerPool lower layer we describing an API of the RSerPool lower layer we have also to take
have also to take into account the differences between TLS and into account the differences between TLS and SCTP. This is also not
SCTP. This is also not difficult, but it is in contrast to the difficult, but it is in contrast to the IPsec solution which is
IPsec solution which is transparently layered below Rserpool. transparently layered below Rserpool.
Support for security is required for the ENRP server and the PEs. Support for security is required for the ENRP server and the PEs.
Security support for the Rserpool end user is optional. Note that Security support for the Rserpool end user is optional. Note that
the end user implementation contains a piece of the Rserpool the end user implementation contains a piece of the Rserpool protocol
protocol -- namely ASAP -- whereby the pool handle is passed for -- namely ASAP -- whereby the pool handle is passed for name
name resolution to the ENRP server and IP address(es) are resolution to the ENRP server and IP address(es) are returned.
returned.
The argument for optional end user security is as follows: If the The argument for optional end user security is as follows: If the
user doesn't require security protection for example, against user doesn't require security protection for example, against
eavesdropping for the request for pool handle resolution and eavesdropping for the request for pool handle resolution and
response, then they are free to make that choice. However, if the response, then they are free to make that choice. However, if the
end user does require security, they are guaranteed to get it due end user does require security, they are guaranteed to get it due to
to the requirement for security support for the ENRP server. It is the requirement for security support for the ENRP server. It is also
also possible for the ENRP server to reject an unsecured request possible for the ENRP server to reject an unsecured request from the
from the user due to its security policy in the case that it user due to its security policy in the case that it requires
requires enforcement of strong security. But this will be enforcement of strong security. But this will be determined by the
determined by the security requirements of the individual network security requirements of the individual network design.
design.
7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- 7. Acknowledgments
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate The authors wish to thank John Loughney, Lyndon Ong, and many others
Requirement Levels", BCP 14, RFC 2119, March 1997. for their invaluable comments.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, Normative References
H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
and, V. Paxson, "Stream Control Transmission Protocol," RFC
2960, October 2000.
[ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
draft-ietf-rserpool-enrp-02.txt, work in progress. 9, RFC 2026, October 1996.
[SCTPAPI] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon, [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
K. Fujita "Sockets API Extensions for SCTP", Levels", BCP 14, RFC 2119, March 1997.
draft-ietf-tsvwg-sctpsocket-01.txt, work in progress.
[SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
R.R. Stewart, "On the Use of SCTP with IPsec", H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
draft-ietf-ipsec-sctp-03.txt, work in progress. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
RFC 2246, January 1999. Server Access Protocol and Endpoint Name Resolution Protocol
Common Parameters", draft-ietf-rserpool-common-param-01 (work in
progress), June 2002.
[ENRP-ASAP] - New draft. [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in
progress), May 2002.
17.1 Bibliography [7] Bellovin, S., "On the Use of SCTP with IPsec", draft-ietf-ipsec-
sctp-03 (work in progress), February 2002.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for [8] Rescorla, E., Tuexen, M. and A. Jungmaier, "TLS over SCTP",
Security", RFC 1750, December 1994. draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November
2001.
8. Acknowledgments Informational References (non-normative)
The authors wish to thank John Loughney, Lyndon Ong, and many [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
others for their invaluable comments. Recommendations for Security", RFC 1750, December 1994.
9. Authors' Addresses Authors' Addresses
Randall R. Stewart Tel: +1-815-477-2127 Randall R. Stewart
Cisco Systems, Inc. EMail: rrs@cisco.com Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, Ill 60631 Chicago, IL 60631
USA
Qiaobing Xie Phone: +1-847-632-3028 Phone: +1-815-477-2127
Motorola, Inc. EMail: qxie1@email.mot.com EMail: rrs@cisco.com
1501 W. Shure Drive, 2-F9
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Maureen Stillman Phone: +1 607 273 0724 62 Phone: +1-847-632-3028
Nokia EMail: maureen.stillman@nokia.com EMail: qxie1@email.mot.com
Maureen Stillman
Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com
Michael Tuexen
Siemens AG
ICN WN CC SE 7
D-81359 Munich
Germany
Phone: +49 89 722 47210
EMail: Michael.Tuexen@icn.siemens.de
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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