draft-ietf-rserpool-asap-00.txt   draft-ietf-rserpool-asap-01.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems Inc.
Q. Xie Q. Xie
Motorola Motorola
expires in six months June 01,2001 expires in six months November 19,2001
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
<draft-ietf-rserpool-asap-00.txt> <draft-ietf-rserpool-asap-01.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]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP Aggregate Server Access Protocol (ASAP) in conjunction with the
[ENRP] provides a high availability data transfer mechanism over IP Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high
networks. ASAP uses a name-based addressing model which isolates a availability data transfer mechanism over IP networks. ASAP uses a
logical communication endpoint from its IP address(es), thus name-based addressing model which isolates a logical communication
effectively eliminating the binding between the communication endpoint from its IP address(es), thus effectively eliminating the
endpoint and its physical IP address(es) which normally constitutes binding between the communication endpoint and its physical IP
a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as In addition, ASAP defines each logical communication destination
a pool, providing full transparent support for as a pool, providing full transparent support for server-pooling
server-pooling and load sharing. It also allows dynamic system and load sharing. It also allows dynamic system scalability -
scalability - members of a server pool can be added or removed at members of a server pool can be added or removed at any time
any time without interrupting the service. without interrupting 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]. (SCTP) [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 the Endpoint Name Resolution Protocol (ENRP). protocols, namely ASAP and ENRP, in which ASAP provides the user
ASAP provides the user interface for name to address translation, interface for name to address translation, load sharing
load sharing management, and fault management. ENRP defines the management, and fault management while ENRP defines the high
high availability name translation service. availability name translation service.
Table Of Contents Table Of Contents
1. Introduction................................................ 3
1.1 Definitions............................................... 3 1. Introduction...............................................3
1.2 Organization of this document............................. 5 1.1 Definitions............................................3
1.3 Scope of ASAP............................................. 5 1.2 Organization of this document..........................5
1.3.1 Extent of the name space............................... 5 1.3 Scope of ASAP..........................................5
2. Conventions................................................. 5 1.3.1 Extent of the Namespace..........................5
3. Message Summary............................................. 5 2. Conventions................................................5
3.1 PE Parameter Definition................................... 6 3. Message Definitions........................................5
3.2 REGISTRATION message...................................... 6 3.1 ASAP Parameter Formats.................................6
3.3 DEREGISTRATION message.................................... 7 3.1.1 IPv4 Address Parameter...........................7
3.4 REGISTRATION_RESPONSE message............................. 7 3.1.2 IPv6 Address Parameter ..........................7
3.5 NAME_RESOLUTION message................................... 8 3.1.3 Pool Element Parameter...........................7
3.6 NAME_RESOLUTION_RESPONSE message.......................... 8 3.1.4 Pool Handle Parameter............................8
3.7 NAME_UNKNOWN message...................................... 9 3.1.5 Authorization Parameter..........................8
3.8 UPDATE_POLICY_VALUE message............................... 9 3.2 ASAP Message Formats...................................9
3.9 ENDPOINT_KEEP_ALIVE message............................... 9 3.2.1 REGISTRATION message.............................10
3.10 ENDPOINT_UNREACHABLE message ............................10 3.2.2 DEREGISTRATION message...........................10
3.11 SERVER_HUNT message .....................................10 3.2.3 REGISTRATION_RESPONSE message....................11
3.12 SERVER_HUNT_RESPONSE message.............................11 3.2.4 NAME_RESOLUTION message..........................11
4. The ASAP Interfaces.........................................11 3.2.5 NAME_RESOLUTION_RESPONSE message.................12
4.1 Registration.Request Primitive............................11 3.2.6 NAME_UNKNOWN message.............................12
4.2 Deregistration.Request Primitive..........................12 3.2.7 ENDPOINT_KEEP_ALIVE message......................12
4.3 Cache.Populate.Request Primitive..........................12 3.2.8 ENDPOINT_UNREACHABLE message ....................12
4.4 Cache.Purge.Request Primitive.............................12 3.2.9 SERVER_HUNT message .............................13
4.5 Data.Send.Request Primitive...............................12 3.2.10 SERVER_HUNT_RESPONSE message....................13
4.5.1 Sending to a Pool.......................................13 4. The ASAP Interfaces........................................13
4.5.2 Pool Element Selection.................................14 4.1 Registration.Request Primitive.........................13
4.5.2.1 Pool selection policy - Round Robin.................14 4.2 Deregistration.Request Primitive.......................14
4.5.2.2 Pool Selection Policy - Least Used Policy...........15 4.3 Cache.Populate.Request Primitive.......................14
4.5.2.3 Pool Selection Policy - Least Used with Degradation 4.4 Cache.Purge.Request Primitive..........................14
Policy..............................................15 4.5 Data.Send.Request Primitive............................14
4.5.2.4 Pool Selection Policy - Weighted round robin........15 4.5.1 Sending to a Pool Handle.........................15
4.5.3 Sending to a Pool Element Handle.......................15 4.5.2 Pool Element Selection...........................16
4.5.4 Send by Transport Address..............................16 4.5.2.1 Round Robin Policy.......................16
4.5.5 Options................................................16 4.5.2.2 Least Used Policy........................17
4.6 Data.Received Notification................................18 4.5.2.3 Least Used with Degradation Policy.......17
4.7 Error.Report Notification.................................18 4.5.2.4 Weighted Round Robin Policy..............17
4.8 SCTP primitives...........................................18 4.5.3 Sending to a Pool Element Handle.................17
4.8.1 SCTP SEND Primitive....................................18 4.5.4 Send by Transport Address........................18
4.8.2 SCTP RECEIVE Primitive.................................19 4.5.5 Message Delivery Options........................18
4.8.3 SCTP SET.PRIMARY Primitive.............................19 4.6 Data.Received Notification.............................19
4.8.4 SCTP DATA.ARRIVE Notification..........................19 4.7 Error.Report Notification..............................20
4.8.5 SCTP SEND.FAILURE Notification.........................19 4.8 Examples...............................................20
4.8.6 SCTP COMMUNICATION.LOST Notification...................20 4.8.1 Send to a New Pool Handle........................20
4.8.7 SCTP NETWORK.STATUS.CHANGE Notification................20 4.8.2 Send to a Cached Pool Handle.....................21
4.9 Examples..................................................20 4.9 Handle ASAP to ENRP Communication Failures.............22
4.9.1 Send to an Unknown Name................................20 4.9.1 SCTP Send Failure................................22
4.9.2 Send to a Cached Name..................................21 4.9.2 T1-ENRPrequest Timer Expiration..................22
4.10 Handle ASAP to ENRP Communication Failures...............22 4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages..............22
4.10.1 SCTP Send Failure.....................................22 4.9.4 Home ENRP Server Hunt............................23
4.10.2 T1-ENRPrequest Timer Expiration.......................22 5. Variables, Timers, and Constants...........................23
4.10.3 Handle ENDPOINT_KEEP_ALIVE Messages...................22 5.1 Timers.................................................23
5. Variables, Timer Values, and Thresholds....................23 5.2 Thresholds.............................................23
5.1 Timer values..............................................23 6. Security Considerations....................................24
5.2 Thresholds................................................23 7. References.................................................24
6. References..................................................23 8. Acknowledgements...........................................24
7. Acknowledgements............................................24 9. Authors' Addresses.........................................24
8. Authors' Addresses.........................................24
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP Aggregate Server Access Protocol (ASAP) in conjunction with ENRP
[ENRP] provides a high availability data transfer mechanism over IP [ENRP] 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 single point of failure. a 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 the message to the selected PE. deliver 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 high
availability name space. ASAP is responsible for the abstraction of availability name space. ASAP is responsible for the abstraction of
the underlying transport technologies, load distribution management, the underlying transport technologies, load distribution management,
fault management, as well as the presentation to the upper layer fault management, as well as the presentation to the upper layer
(i.e., the ASAP user) a unified primitive interface. (i.e., the ASAP user) a unified primitive interface.
When SCTP [RFC2960] is used as the transport layer protocol, ASAP can When SCTP [RFC2960] is used as the transport layer protocol, ASAP can
seamlessly incorporate the link-layer redundancy provided by the seamlessly incorporate the link-layer redundancy provided by the
SCTP. SCTP.
This document defines ASAP portion of the high availability server This document defines the ASAP portion of the high availability server
pool. ASAP depends on the services of a high availiablity name space pool. ASAP depends on the services of a high availiablity name space
a.k.a. ENRP. a.k.a. ENRP.
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ASAP User:
Either a PE or PU that uses ASAP.
Operation scope: Operation scope:
The part of the network visible to pool users by a specific The part of the network visible to Pool Users by a specific
instance of the reliable server pooling protocols. instance of the reliable server pooling protocols.
Server pool (or Pool): Server pool (or Pool):
A collection of servers providing the same application A collection of servers providing the same application
functionality. functionality.
Pool handle (or pool name): Pool handle (or pool name):
A logical pointer to a pool. Each server pool will be A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique identifiable in the operation scope of the system by 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 (or endpoint handle): Pool Element handle (PE handle):
A logical pointer to a particular pool element in a pool, A logical pointer to a particular Pool Element in a pool,
ENRP server: ENRP server:
A server program running on a host that manages the A server program running on a host that manages the
name space collectively with its peer ENRP servers and name space collectively with its peer ENRP servers and
replies to the service requests from any Pool user or replies to the service requests from any Pool User or
Pool Element. 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
belongs. Pool elements normally choose the ENRP server or PE normally chooses the ENRP server on their local host as
on their local host as the home ENRP server (if one exists). the home ENRP server (if one exists). A PU or PE should only
A Pool element shall only have one home ENRP server at have one home ENRP server at any given time.
any given time. Both the PE and the server shall
keep track of this master/slave relationship between them.
ENRP server takeover:
The event that a remote ENRP server takes the ownership
of all the Pool elements on a host and becomes their
home server.
Caretaker ENRP server:
The ENRP server on a remote host which takes ownership
of all PEs on a host because of the absence of an
active local ENRP server.
PU channel: ENRP client channel:
The communication channel through which a ASAP Pool User The communication channel through which an ASAP User (either a
requests for ENRP service. The PU channel is PE or PU) requests ENRP namespace service. The client channel
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. home server and a well known port number.
ENRP server channel: ENRP server channel:
Defined by a well known multicast IP address and a well Defined by a well known multicast IP address and a well
known port number, or a well known list of transport known port number, or a well known list of transport
addresses for a group of ENRP servers spanning an addresses for a group of ENRP servers spanning an
operational scope. All ENRP servers in an operation scope operational scope. All ENRP servers in an operation scope
can communicate with one another through this channel. can communicate with one another through this channel.
ENRP name domain: ENRP name domain:
Defined by the combination of the PU channel and the Defined by the combination of the ENRP client channel and the
ENRP server channel in the operation scope. ENRP server channel in the operation scope.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order:
Most significant byte first, a.k.a Big Endian.
Transport address:
A Transport Address is traditionally defined by Network Layer
address, Transport Layer protocol and Transport Layer port
number. In the case of SCTP running over IP, a transport
address is defined by the combination of an IP address and an
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 Chapter 3 details ASAP message formats. In Chapter 4 we give the
details of the ASAP interface, focusing on the communication details of the ASAP interface, focusing on the communication
primitives between the applications above ASAP and ASAP itself, and primitives between the applications above ASAP and ASAP itself, and
the communications primitives between ASAP and SCTP (or other the communications primitives between ASAP and SCTP (or other
transport layer). Also included in this discussion is relevant transport layer). Also included in this discussion is relevant
timers and configurable parameters as appropriate. Chapter 5 timers and configurable parameters as appropriate. Chapter 5
provides settable protocol values. provides settable protocol values.
skipping to change at page 5, line 28 skipping to change at page 5, line 26
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 any state. share any state.
1.3.1 Extent of the name space 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 I want to use administrative domains. For example, suppose we want to use
ASAP/ENRP. First, the PU will use DNS to contact an ENRP server. ASAP/ENRP. First, the PU may use DNS to contact an ENRP server.
Suppose a PU in North America wish to contact the server pool in Suppose a PU in North America wishes to contact the server pool in
Japan instead of North America. The PU would use DNS to get the IP Japan instead of North America. The PU would use DNS to get the IP
address of the Japanese server pool domain, that is, the address of address of the Japanese server pool domain, that is, the address of
an ENRP server('s) in Japan. From there the PU would query the an ENRP server(s) in Japan. From there the PU would query the
ENRP server and then directly contact the PE's of interest. ENRP server and then directly contact the PE(s) of interest.
2. Conventions 2. 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].
3. Message Summary 3. Message Definitions
All messages as well as their fields described below MUST 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 filed name to indicate the length of the field in number of
octets. octets.
3.1 PE Parameter Definition 3.1 ASAP Parameter Formats
This parameter is used in multiple ASAP message to represent a PEP
or endpoint and the associated information, such as its transport
address(es), load control, and other operational status information
of the PE.
The parameter is defined to support PEs with up to 8 different IPv4 ASAP parameters are defined in a Type-length-value (TLV) format as
transport addresses. shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #0 | | Parameter Type | Parameter Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #1 | : :
+-------------------------------+-------------------------------+ : Parameter Value :
\ \ \ \ : :
/ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
+-------------------------------+-------------------------------+
| IP address #7 |
+-------------------------------+-------------------------------+
| SCTP Port | Padding |
+-------------------------------+-------------------------------+
| Load sharing policy type | Policy Value |
+---------------+---------------+---------------+---------------+
The size of a PE Parameter is 40 octets. Parameter Type: 16 bits (unsigned integer)
3.2 REGISTRATION message The Type field is a 16 bit identifier of the type of parameter.
It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific SCTP chunk description are
reserved for use by IETF.
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Type, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is not included in the parameter
length field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order two bits
specify the action that must be taken if the processing endpoint does
not recognize the Parameter Type.
00 - Stop processing this ASAP message and discard it, do not process
any further parameters within it.
01 - Stop processing this ASAP message and discard it, do not process
any further parameters within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' error.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type'
error.
In the following sections, we define the common parameter formats
used in ASAP.
3.1.1 IPv4 Address Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x1 | Length = 8 |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | | IPv4 Address |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 |
+-------------------------------+-------------------------------+
| |
| pool handle (32) |
| |
+-------------------------------+-------------------------------+
| |
| PE Parameter (40) |
| |
+-------------------------------+-------------------------------+
The pool handle field specifies the name to be registered, that IPv4 Address: 32 bits (unsigned integer)
shall be composed of up to 32 characters. The PE Parameter field
shall be filled in by the registrant endpoint to declare its
transport addresses, server pooling policy and value, and other
operation preferences.
3.3 DEREGISTRATION message Contains an IPv4 address of the sending endpoint. It is binary
encoded.
3.1.2 IPv6 Address Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x2 | Length = 20 |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 |
+-------------------------------+-------------------------------+
| Type = 0x4 |
+-------------------------------+-------------------------------+
| |
| pool handle (32) |
| | | |
+-------------------------------+-------------------------------+ | IPv6 Address |
| | | |
| PE Parameter (40) |
| | | |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The endpoint sending the DEREGISTRATION shall fill in the name and IPv6 Address: 128 bit (unsigned integer)
the PE Parameter in order to allow the ENRP server to verify the
identity of the endpoint.
3.4 REGISTRATION_RESPONSE message Contains an IPv6 address of the sending endpoint. It is binary
encoded.
3.1.3 Pool Element Parameter
This parameter is used in multiple ASAP message to represent an ASAP
endpoint (i.e., a PE in a pool) and the associated information, such
as its transport address(es), load control, and other operational
status information of the PE.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x3 | Length=variable |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | | SCTP Port | Number of IP addrs=k |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 | : IP addr param #0 :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : IP addr param #1 :
| pool handle (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : :
+-------------------------------+-------------------------------+ : ..... :
| Result = (see below) | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested action = (see below) | : IP addr param #k :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Load Policy Type | Policy Value |
| PE Parameter (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Registration Life |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In response to a REGISTRATION, the 'Requested action' field shall be Each of the IP address parameters in a PE parameter can be either
set to 0x0, and the 'Result' field shall take the following values: an IPv4 or IPv6 address parameter.
0x0 -- registration granted
0x1 -- registration rejected
In response to a DEREGISTRATION, the 'Requested action' field shall 3.1.4 Pool Handle Parameter
be set to 0x1, and the 'Result' field shall take the following
values:
0x2 -- de-registration granted 0 1 2 3
0x3 -- de-registration rejected: endpoint not found 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
0x4 -- de-registration rejected: other failures. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Handle :
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PE Parameter shall be filled in for verification purposes. This parameter holds a pool handle that is a NULL terminated ASCII
string.
3.5 NAME_RESOLUTION message 3.1.5 Authorization Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x5 | Length=variable |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : :
+-------------------------------+-------------------------------+ : Authorization Signature :
| Type = 0x1 |
+-------------------------------+-------------------------------+
| |
| requested name (32) |
| |
+-------------------------------+-------------------------------+
3.6 NAME_RESOLUTION_RESPONSE message : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used to hold an authorization signature. The
signature is signed over the entire ASAP message and uses a
preconfigured public/private key pair. The receiver of a message
which includes this parameter can validate the message is
from the sender by comparing the signature to one generated
using the peers public key.
3.2 ASAP Message Formats
The figure below illustrates the common format for all ASAP
messages. Each message is formatted with a Message
Type field, a message-specific Flag field, a Message Length field,
and a Value field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Message Type | Msg Flags | Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : :
+-------------------------------+-------------------------------+ : Message Value :
| Type = 0x2 | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pool handle (32) |
| |
+-------------------------------+-------------------------------+
| number of entries = n (see below) |
+-------------------------------+-------------------------------+
| |
| PE Parameter 1 (40) |
| |
+-------------------------------+-------------------------------+
/ /
\ \
/ /
+-------------------------------+-------------------------------+
| |
| PE Parameter n (40) |
| |
+-------------------------------+-------------------------------+
3.7 NAME_UNKNOWN message Message Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the
Message Value field. It takes a value from 0 to 254. The value
of 255 is reserved for future use as an extension field.
Message Types are encoded such that the highest-order two bits
specify the action that must be taken if the message receiver
does not recognize the Message Type.
00 - Stop processing this message and discard it.
01 - Stop processing this message and discard it, and report the
unrecognized message in an 'Unrecognized Parameter Type'
error.
10 - reserved.
11 - reserved.
Message Flags: 8 bits
The usage of these bits depends on the message type as given by
the Message Type. Unless otherwise specified, they are set to
zero on transmit and are ignored on receipt.
Message Length: 16 bits (unsigned integer)
This value represents the size of the message in bytes including
the Message Type, Message Flags, Message Length, and Message
Value fields. Therefore, if the Message Value field is
zero-length, the Length field will be set to 4. The Message
Length field does not count any padding.
Message Value: variable length
The Message Value field contains the actual information to be
transferred in the message. The usage and format of this field
is dependent on the Message Type.
The total length of a message (including Type, Length and Value
fields) MUST be a multiple of 4 bytes. If the length of the
message is not a multiple of 4 bytes, the sender MUST pad the
message with all zero bytes and this padding is not included in the
message length field. The sender should never pad with more than 3
bytes. The receiver MUST ignore the padding bytes.
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Pool Handle :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0 | : Pool Element Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : Authorization Parameter (optional) :
| requested name (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-------------------------------+-------------------------------+
3.8 UPDATE_POLICY_VALUE message The pool handle parameter field specifies the name to be registered.
The PE Parameter field shall be filled in by the registrant
endpoint to declare its transport addresses, server pooling
policy and value, and other operation preferences.
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Pool Handle Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x11 | : Pool Element Parameter :
+-------------------------------+-------------------------------+
| |
| pool handle (32) |
| |
+-------------------------------+-------------------------------+
| |
| PE Parameter (40) |
| |
+-------------------------------+-------------------------------+
| New policy value |
+-------------------------------+-------------------------------+
3.9 ENDPOINT_KEEP_ALIVE message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PE sending the DEREGISTRATION shall fill in the pool handle
and the PE Parameter in order to allow the ENRP server to verify
the identity of the endpoint.
3.2.3 REGISTRATION_RESPONSE message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Pool Handle Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 | : Pool Element Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Action code | Result code | (reserved) |
| pool handle (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.10 ENDPOINT_UNREACHABLE message Action: (8 bits)
The message that this results code is in response to:
0x0 -- registration
0x1 -- de-registration
Result code: (8 bits)
0x0 -- request granted
0x1 -- request denied, unspecifed
0x2 -- request denied, authorization failure
0x3 -- request denied, invalid values
Reserved: (16 bits)
Ignored by the receiver and set to 0 by the sender.
3.2.4 NAME_RESOLUTION message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Pool Handle Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xa | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pool handle (32) |
| |
+-------------------------------+-------------------------------+
| Endpoint IP address |
+-------------------------------+-------------------------------+
| Endpoint's SCTP port | padding |
+-------------------------------+-------------------------------+
| Type of severity (see below) |
+-------------------------------+-------------------------------+
The 'pool handle' is not required to be filled in for this 3.2.5 NAME_RESOLUTION_RESPONSE message
message, however the IP address and SCTP port number of the endpoint
must be supplied in the message.
'Type of severity' shall take one of the following values: 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 = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0 --- NORMAL_REPORT: warning to the server. 3.2.6 NAME_UNKNOWN message
0x1 --- FINAL_REPORT: the specified endpoint must be removed by the
server immediately.
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.7 ENDPOINT_KEEP_ALIVE message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Pool Handle Parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xb | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pool handle (32) |
| |
+-------------------------------+-------------------------------+
| criticality (see below) |
+-------------------------------+-------------------------------+
The 'criticality' field shall take one of the following values: 3.2.8 ENDPOINT_UNREACHABLE message
0x1 --- LOW_CRITICALITY 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
0x2 --- MED_CRITICALITY +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x3 --- HIGH_CRITICALITY | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
3.12 SERVER_HUNT_RESPONSE message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.9 SERVER_HUNT message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0xa |0|0|0|0|0|0|0|0| Message Length :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xc |
+-------------------------------+-------------------------------+ 3.2.10 SERVER_HUNT_RESPONSE message
| |
| pool handle (32) | 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 = 0xb |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 that form the interface between the ASAP-user and the notifications that form the interface between the ASAP-user and the
ASAP and that between ASAP and its lower layer transport protocol ASAP and that between ASAP and its lower layer transport protocol
(e.g., SCTP). (e.g., SCTP).
Appropriate timers and recovery actions for failure detection and Appropriate timers and recovery actions for failure detection and
management are also discussed. management are also discussed.
An ASAP User (PU OR PE) passes primitives to the ASAP sub-layer to An ASAP User passes primitives to the ASAP sub-layer to
request certain actions. Upon the completion of those actions or request certain actions. Upon the completion of those actions or
upon the detection of certain events, the ASAP will notify the upon 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(endpointName) Format: registration.request(poolHandle)
where the endpointName parameter contains a NULL terminated ASCII where the poolHandle parameter contains a NULL terminated ASCII
string of fixed length. string of fixed length.
The ASAP user invokes this primitive to add itself to the name The ASAP user invokes this primitive to add itself to the
space, thus becoming a Pool Element. The ASAP user must register its namespace, thus becoming a Pool Element of a pool. The ASAP user
name with the ENRP server by using this primitive before other ASAP must register itself with the ENRP server by using this primitive
endpoints using the name space can send message(s) to this ASAP user before other ASAP users using the namespace can send message(s) to
by name or by Pool element handle (see Sections ? and ?). this ASAP user by pool handle or by PE handle (see Sections 4.5.1
and 4.5.2).
In response to the registration primitive, the ASAP layer will send In response to the registration primitive, the ASAP layer will send
a REGISTRATION message to the home ENRP server (See section ?), a REGISTRATION message to the home ENRP server (See section 3.2.1),
and start a T2-registration timer. and 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 layer shall start the Server received from the SCTP layer, the ASAP layer shall start the Server
Hunt procedure (see Section ?) in an attempt to get service Hunt procedure (see Section 4.9.4) in an attempt to get service
from a remote ENRP server. from a different ENRP server.
4.2 Deregistration.Request Primitive 4.2 Deregistration.Request Primitive
Format: deregistration.request() Format: deregistration.request(poolHandle)
The ASAP user invokes this primitive to remove itself from the The ASAP PE invokes this primitive to remove itself from the
Server Pool. This should be used as a part of the graceful shutdown Server Pool. This should be used as a part of the graceful shutdown
process by the application. process by the application.
A DEREGISTRATION message will be sent by ASAP layer to the home ENRP A DEREGISTRATION message will be sent by ASAP layer to the home ENRP
server (see Section ?). server (see Section 3.2.2).
4.3 Cache.Populate.Request Primitive 4.3 Cache.Populate.Request Primitive
Format: cache.populate.request(destinationAddress, typeOfAddress) Format: cache.populate.request(destinationAddress, typeOfAddress)
If the address type is a Pool handle (or name) and a local name If the address type is a Pool handle and a local name
translation cache exists, the ASAP layer should initiate a mapping translation cache exists, the ASAP layer should initiate a mapping
information query on the Pool handle and update it local cache when the information query by sending a NAME.RESOLUTION message on the Pool
response comes back from the ENRP server. handle and update it local cache when the response comes back from
the ENRP server.
The destinationAddress field contains the address for which the
cache needs to be populated. The typeOfAddress indicates the address
type. Allowable types are Pool handle and Pool Element handle. In
the case of a Pool Element handle, the Pool handle is extracted from
the Pool Element handle and used to form a NAME.RESOLUTION
message (see Section 3.5).
4.4 Cache.Purge.Request Primitive 4.4 Cache.Purge.Request Primitive
Format: cache.purge.request(destinationAddress, typeOfAddress) Format: cache.purge.request(destinationAddress, typeOfAddress)
If the address type is a Pool handle (or name) and local name If the address type is a Pool handle and local name
translation cache exists, the ASAP layer should remove the mapping translation cache exists, the ASAP layer should remove the mapping
information on the Pool handle from its local cache. information on the Pool handle from its local cache.
4.5 Data.Send.Request Primitive 4.5 Data.Send.Request Primitive
Format: data.send(destinationAddress, typeOfAddress, message, Format: data.send.request(destinationAddress, typeOfAddress,
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 or Pool element within the current Operational scope. Pool 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
sender's ASAP layer may perform address translation and Pool Element sender's ASAP layer may perform address translation and Pool Element
selection before sending the message out. selection before sending the message out.
The data.send primitive can take the following forms of address The data.send.request primitive can take different forms of
type. address types as described in the following sections.
4.5.1 Sending to a Pool 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 data.request primitive. By default, This is the simplest form of send.data.request primitive. By
this directs ASAP to send the message to one of the pool elements default, this directs ASAP to send the message to one of the Pool
in the server pool. Elements in the specified pool.
Before sending the message out to the Pool, the sender's ASAP layer Before sending the message out to the pool, the sender's ASAP layer
MUST first perform a name to address translation. It may also need MUST first perform a pool handle to address translation. It may
to perform Pool Element selection if multiple Pool Elements exist in also need to perform Pool Element selection if multiple Pool
the Server Pool. Elements exist in the pool.
If the sender's ASAP implementation does not support a local cache of If the sender's ASAP implementation does not support a local cache
the translation information or if it does not have the translation of the mapping information or if it does not have the mapping
information on that Pool in its local cache, it will transmit information on the pool in its local cache, it will transmit a
a request for the name mapping information to the ENRP server, and NAME.RESOLUTION message to the current home ENRP server, and
MUST hold the outbound message in queue while awaiting the response MUST hold the outbound message in queue while awaiting the response
from the ENRP server (any further send request to this Pool from the ENRP server (any further send request to this pool before
before the ENRP server responds SHOULD also be queued). the ENRP server responds SHOULD also be queued).
Once the necessary mapping information arrives from the ENRP server, Once the necessary mapping information arrives from the ENRP server,
the sender's ASAP will: the sender's ASAP will:
A) map the name 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 that Pool, ASAP will choose B) if multiple PEs exist in the pool, ASAP will choose
one of them and transmit the message to it. In that case, the one of them and transmit the message to it. In that case, the
choice of the PE is made by ASAP layer of the sender based on choice of the PE is made by ASAP layer of the sender based on
the server pooling policy as discussed in section ?. the server pooling policy as discussed in section 4.5.2.
C) if no association exists towards the destination, establish a new C) if no transport association exists towards the destination PE,
SCTP association, ASAP will establish a new transport association,
NOTE: if the underlying SCTP implementation supports implicit NOTE: if the underlying SCTP implementation supports implicit
association setup, this step is not needed (see [RFC2960]). association setup, this step is not needed (see [SCTP-API]).
D) send out the queued message to the SCTP association using the D) send out the queued message(s) to the SCTP association using the
SEND primitive (see [RFC2960]), and, SEND primitive (see [RFC2960]), and,
E) if the local cache is implemented, append/update the local cache E) 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 SCTP association id, if a new response. Also, record the local SCTP association id, if a new
association was created. association was created.
For more on the ENRP server request procedures see [ENRP]. For more on the ENRP server request procedures see [ENRP].
Optionally, the ASAP layer of the sender may return a Pool Element Optionally, the ASAP layer 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 handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that PE (see Section ?). that same PE (see Section 4.5.3).
Section ? defines the fail-over procedures for cases where the Section 4.5.5 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 a ASAP user sends a message to a Pool that contains Each time an ASAP user sends a message to a pool that contains
more than one PE, the sender's ASAP layer must select one of more than one PE, the sender's ASAP layer must select one of
the PEs in the Pool as the receiver of the current the PEs in the pool as the receiver of the current
message. The selection is done according to the current server message. The selection is done according to the current server
pooling policy of the Pool to which the message is sent. pooling policy of the pool to 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 ?). (see Section 4.5.5).
When joining a Pool, along with its registration each When joining a pool, along with its registration each
PE specifies its preferred server pooling policy for receiving PE specifies its preferred server pooling policy for receiving
messages sent to this Pool. But only the server pooling messages sent to this pool. But only the server pooling
policy specified by the first PE joining the Pool will policy specified by the first PE joining the pool will
become the current server pooling policy of the group. become the current server pooling policy of the group.
Moreover, together with the server pooling policy, each PE can Moreover, together with the server pooling policy, each PE can
also specify a Policy Value for itself at the registration time. The also specify a Policy Value for itself at the registration time. The
meaning of the policy value depends on the current server pooling meaning of the policy value depends on the current server pooling
policy of the group. A PE can also change its policy value policy of the group. A PE can also change its policy value
whenever it desires, see Section ? for details. whenever it desires, by re-registering itself with the namespace
with a new policy value. Re-registration shall be done by simply
sending another REGISTRATION to its home ENRP server.
Note, if this first PE removes itself from the Pool Note, if this first PE removes itself from the pool
(e.g., by de-registration from the name space) and the remaining (e.g., by de-registration from the name space) and the remaining
PEs have specified conflicting server pooling policies at PEs have specified conflicting server pooling policies at
their corresponding registrations, it is implementation specific to their corresponding registrations, it is implementation specific to
determine the new current server pooling policy. determine the new current server pooling policy.
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 Pool selection policy - Round Robin
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 the current policy of that Pool, the ASAP layer of the sender is the current policy of that Pool, the ASAP layer of the sender
will select the receiver for each outbound message by round-Robining will select the receiver for each outbound message by round-Robining
through all the registered PEs in that Pool, in an attempt to through all the registered PEs in that Pool, in an attempt to
achieve an even distribution of outbound messages. Note that in a achieve an even distribution of outbound messages. Note that in a
large server pool, the ENRP deamon may NOT send back all PEs large server pool, the ENRP server may NOT send back all PEs
to the ASAP client. In this case the client or PU will be to the ASAP client. In this case the client or PU will be
performing a round robin policy on a subset of the entire Pool. performing a round robin policy on a subset of the entire Pool.
4.5.2.2 Pool Selection Policy - 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 layer of the message sender will select the PE that policy, the ASAP layer of the message sender will select the PE that
has the lowest policy value in the group as the receiver of the 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 (see section ?). local cache of the sender (see section ?).
4.5.2.3 Pool Selection Policy - Least Used with Degradation Policy 4.5.2.3 Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception This policy is the same as the Least Used policy with the exception
that, each time the PE with the lowest policy value is selected from that, each time the PE with the lowest policy value is selected from
the Pool as the receiver of the current message, its policy value is the Pool as the receiver of the current message, its policy value is
incremented, and thus it may no longer be the lowest value in the incremented, and thus it may no longer be the lowest value in the
Pool. Pool.
This provides a degradation of the policy towards round Robin policy This provides a degradation of the policy towards round Robin policy
over time. As with the Least Used policy, every local cache update over time. As with the Least Used policy, every local cache update
at the sender will bring the policy back to Least Used with at the sender will bring the policy back to Least Used with
Degradation. Degradation.
4.5.2.4 Pool Selection Policy - Weighted round robin 4.5.2.4 Weighted Round Robin Policy
[TBD] [TBD]
4.5.3 Sending to a Pool Element Handle 4.5.3 Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a ASAP pool element handle. indicate an ASAP Pool Element handle.
This requests the ASAP layer to deliver the message to the PE This requests the ASAP layer to deliver the message to the PE
identified by the pool element handle. identified by the Pool Element handle.
The pool element handle should contains the name and the primary The Pool Element handle should contain the poolHandle and a
destination transport address of the destination PE. destination transport address of the destination PE or the
poolHandle and the SCTP 'association id'.
The ASAP layer shall use the address to identify the SCTP The ASAP layer shall use the transport address to identify the
association (or to setup a new one if necessary) and then invoke the SCTP association (or to setup a new one if necessary) and then
SCTP SEND primitive to send the message to the PE. invoke the SCTP SEND primitive to send the message to the PE.
If local cache is supported and the mapping information for the Pool In addition, if a local translation cache is supported the
found in the pool element handle is not available in the local endpoint will:
cache, the sender's ASAP layer SHOULD, after sending the message,
also transmit a request for the Pool handle mapping information to
the ENRP server. Once the necessary mapping information arrives from
the ENRP server, the sender's ASAP will update its local cache with
the newly received mapping information for that Pool handle.
Section ? defines the fail-over procedures for cases where the PE A) send out the message to the transport address (or association
pointed to by the Pool Element handle is found unreachable. id) designated by the PE handle.
B) determine if the pool handle is in the local cache.
If it is NOT, the endpoint will:
i) ask the home ENRP server for name resolution on pool handle
by sending a NAME.RESOLUTION message, and
ii) use the response to update the local cache.
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
indicated by it being older than the protocol parameter
'stale.cache.value'.
Section 4.5.5? defines the fail-over procedures for cases where
the PE pointed to by the Pool Element handle is found unreachable.
Optionally, the ASAP layer may return the actual Pool Elment handle Optionally, the ASAP layer may return the actual Pool Elment handle
to which the message was sent (this may be different from the Pool to which the message was sent (this may be different from the Pool
Element handle specified when the primitive is invoked, due to the Element handle specified when the primitive is invoked, due to the
possibility of automatic fail-over). 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
indicates an SCTP transport address. indicate an SCTP transport address.
This directs the sender's ASAP layer to send the message out to the This directs the sender's ASAP layer to send the message out to the
specified transport address. specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint fail-over is support when this form of send request is
used. This mode of sending effectively by-passes the ASAP layer. used. This form of send request effectively by-passes the ASAP
layer.
4.5.5 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.request primitive gives directions to the sender's ASAP layer data.send.request primitive gives directions to the sender's ASAP
on special handling of the message delivery. layer on special handling of the message delivery.
Options can be grouped as follows:
- PE fail-over (allowed, or prohibited),
- whether to send to one PE or to the whole Pool,
- whether to send to the same PE last sent to within
the Pool, and
- options passed to the SCTP transport protocol.
The complete list of Options is as follows: The value of the Options parameter is generated by bit-wise
"OR"ing of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 ASAP_USE_DEFAULT: 0x0000
Use default setting. Use default setting.
ASAP_SEND_FAILOVER: 0x0001 ASAP_SEND_FAILOVER: 0x0001
Enables PE fail-over on this message. In case where the first Enables PE fail-over on this message. In case where the first
selected PE or the PE pointed to by the handle is found unreachable, selected PE or the PE pointed to by the PE handle is found
this option allows the sender's ASAP layer to re-select an alternate unreachable, this option allows the sender's ASAP layer to
PE from the same Pool if one exists, and silently re-send the re-select an alternate PE from the same pool if one exists, and
message to this newly selected endpoint. silently re-send the message to this newly selected endpoint.
Endpoint unreachable is normally indicated by the Communication Lost Endpoint unreachable is normally indicated by the SCTP
or Send Failure notification from SCTP. COMMUNICATION.LOST or SEND.FAILURE notification.
ASAP_SEND_NO_FAILOVER: 0x0002 ASAP_SEND_NO_FAILOVER: 0x0002
This option prohibits the sender's ASAP layer from re-sending the This option prohibits the sender's ASAP layer from re-sending the
message to any alternate PE in case that the first selected PE or message to any alternate PE in case that the first selected PE or
the PE to by the handle is found unreachable. Instead, the sender's the PE pointed to by the PE handle is found unreachable. Instead,
ASAP layer shall notify its upper layer about the unreachability the sender's ASAP layer shall notify its upper layer about the
with an Error.Indication and any unsent data. unreachability with an Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004 ASAP_SEND_TO_LAST: 0x0004
This option requests the sender's ASAP layer to send the message to This option requests the sender's ASAP layer to send the message to
the same PE in the Pool that the previous message was the same PE in the pool that the previous message destined to this
sent to. pool was sent to.
ASAP_SEND_TOALL: 0x0008 ASAP_SEND_TO_ALL: 0x0008
When sending by Pool Handle, this option directs the sender's ASAP When sending by Pool Handle, this option directs the sender's ASAP
layer to send a copy of the message to all the PEs, except for the layer to send a copy of the message to all the PEs, except for the
sender itself (if the sender is a PE), in that Pool. sender itself if the sender is a PE, in that pool.
ASAP_SEND_TOSELF: 0x0010. ASAP_SEND_TO_SELF: 0x0010.
This option only applies in combination with ASAP_SEND_TOALL option. This option only applies in combination with ASAP_SEND_TO_ALL option.
It permits the sender's ASAP layer also deliver a copy of the It permits the sender's ASAP layer also deliver a copy of the
message to itself (i.e., loopback). message to itself if the sender is a PE of the pool (i.e., loopback).
ASAP_SCTP_BUNDLE: 0x0100
This option allows the local SCTP transport layer to bundle the
outbound messages whenever possible into bigger datagrams before
transmitting them onto the network.
ASAP_SCTP_NO_BUNDLE: 0x0200
This option disallows the local SCTP transport layer to bundle
outbound messages.
ASAP_SCTP_HB_ON: 0x0400
This option instructs the local SCTP transport layer to turn on
heartbeat on the SCTP association indicated by the
destinationAddress parameter.
ASAP_SCTP_HB_OFF: 0x0800
This option instructs the local SCTP transport layer to turn off
heartbeat on the SCTP association indicated by the
destinationAddress parameter.
ASAP_SCTP_UNORDER: 0x1000 ASAP_SCTP_UNORDER: 0x1000
This option instructs the SCTP transport layer to send the current This option instructs the SCTP transport layer to send the current
message using un-ordered delivery. message using un-ordered delivery.
4.6 Data.Received Notification 4.6 Data.Received Notification
Format: data.received(messageReceived, sizeOfMessage, senderAddress, Format: data.received(messageReceived, sizeOfMessage, senderAddress,
typeOfAddress) typeOfAddress)
skipping to change at page 18, line 9 skipping to change at page 20, line 4
ASAP_SCTP_UNORDER: 0x1000 ASAP_SCTP_UNORDER: 0x1000
This option instructs the SCTP transport layer to send the current This option instructs the SCTP transport layer to send the current
message using un-ordered delivery. message using un-ordered delivery.
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 layer of the receiver When a new user message is received, the ASAP layer of the receiver
uses this notification to pass the message to its upper layer. uses this notification to pass the message to its upper layer.
Along with the message being passed, the ASAP layer of the receiver Along with the message being passed, the ASAP layer of the receiver
should also indicate to its upper layer the message sender's should also indicate to its upper layer the message sender's
address. The sender's address can be in the form of either an SCTP address. The sender's address can be in the form of either an SCTP
association id, or a ASAP pool element handle. association id, or a 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 layer, a reverse mapping from the sender's IP receiver's ASAP layer, a reverse mapping from the sender's 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 is
successful, the sender's ASAP pool element handle should be successful, the sender's ASAP Pool Element handle should be
constructed and passed in the senderAddress field. constructed and passed in the senderAddress field.
B) If there is no local cache or the reverse mapping is not B) If there is no local cache or the reverse mapping is not
successful, the SCTP association id should be passed in the successful, the SCTP association id should be passed in the
senderAddress field. senderAddress field.
4.7 Error.Report Notification 4.7 Error.Report Notification
Format: error.report(destinationAddress, typeOfAddress, Format: error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage) failedMessage, sizeOfMessage)
An error.report should be generated to notify the ASAP user about An error.report should be generated to notify the ASAP user about
failed message delivery as well as other abnormalities (see Section failed message delivery as well as other abnormalities (see Section
? for details). ? for details).
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 SCTP primitives 4.8 Examples
4.8.1 SCTP SEND Primitive
Basic Format:
SEND(association id, buffer address, byte count, options)
-> result
The outbound message will be held in the buffer when this primitive
is invoked. The ASAP layer shall identify the SCTP association which
connects to the intended destination and fill in the 'association
id'.
The options field will hold the options destined to the SCTP
transport layer (see ?).
The returned 'result' can indicate whether there is any local error
executing the primitive.
4.8.2 SCTP RECEIVE Primitive
Basic Format:
RECEIVE(association id, buffer address, buffer size) -> byte count
This primitive reads the first user message out from the SCTP
stack (if there is one available) and put it into the specified
buffer. The size of the message read, in octets, will also be
returned.
4.8.3 SCTP SET.PRIMARY Primitive
Basic Format:
SET.PRIMARY(association id, destination transport address) -> result
This can be used to instructs SCTP to use the specified
destination transport address as the new primary destination address
for sending messages.
4.8.4 SCTP DATA.ARRIVE Notification
SCTP layer invokes this notification when a user message is
successfully received and ready for retrieval. This shall prompt the
ASAP layer to invoke the RECEIVE primitive to get the data (see ?).
4.8.5 SCTP SEND.FAILURE Notification
If a message can not be delivered to the specified association id,
for any reason, SCTP will invoke this notification to notify ASAP.
In response, the ASAP shall take the following steps:
A) If the message was originally sent by Pool handle or Pool Element
handle and with option ASAP_SEND_FAILOVER set, retransmit the
message to an alternate PE of the same Pool if one exists in
the Server Pool. The proper server pooling policy shall be followed
if more than one alternates exist in the group.
B) If no alternate exists or option ASAP_SEND_FAILOVER is not set
when the message was originally sent, generate an Error.report to
report the failure to the ASAP user.
4.8.6 SCTP COMMUNICATION.LOST Notification
When SCTP loses communication to an PE completely or detects that
the PE has performed an abort or graceful shutdown operation, it
invokes this notification to notify ASAP layer.
When handling this notification ASAP shall report this event to its
ENRP server via an ENDPOINT_UNREACHABLE message with the severity
level set to NORMAL_REPORT (see ?).
If local mapping cache is implemented, the ASAP layer should also
mark the PE as unreachable in its local cache. And if all the PEs in
that Pool are marked as unreachable, the ASAP layer should remove
the Pool from its local cache.
4.8.7 SCTP NETWORK.STATUS.CHANGE Notification
The SCTP sends this notification to the ASAP layer when the
reachability status of a transport address of a specific SCTP
association has changed.
If the local mapping cache is supported, the ASAP layer, upon
reception of this notification, should look up the information of
this PE in its local cache and record the reachability change.
If the address in question becomes unreachable and is the primary
address of the association, the ASAP layer MAY also elect a new
primary for this association by invoking the SET.PRIMARY primitive
(Section ?).
If the local cache is not support or the reverse look up does not
succeed, ASAP takes no action.
4.9 Examples
4.9.1 Send to an Unknown Name 4.8.1 Send to a New Pool
This example shows the event sequence when the Pool user, This example shows the event sequence when a Pool User sends the
Endpoint 1 (EP1) sends the message "hello world" to a name message "hello" to a pool which is not in the local
which is not in the local mapping cache (assuming local translation cache (assuming local caching is supported).
caching is supported).
ENRP Server EP1 new-name:EP2 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. "hello" | | +---+ 6. "hello1" |
| |----------------->| | |---------------->|
| | | | | |
1) The user at EP1 invokes: 1) The user at PU invokes:
data.send("new-name", name-type, "hello", 5 0); data.send.request("new-name", name-type, "hello1", 6, 0);
The ASAP layer, in response, looks up the name "new-name" in its The ASAP layer, in response, looks up the pool "new-name" in its
local cache but fails to find it. local cache but fails to find it.
2) The ASAP layer of EP1 queues the message, and sends a 2) The ASAP layer 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 "new-name". information about pool "new-name".
3) A T1-ENRPrequest timer is started while the ASAP layer is waiting 3) A T1-ENRPrequest timer is started while the ASAP layer is waiting
for the response from the ENRP server. 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 "new-name". about pool "new-name".
5) ASAP at EP1 cancels the T1-ENRPrequest timer and populate its 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its
local cache with information on "new-name". local cache with information on pool "new-name".
6) Based on the server pooling policy of "new-name", ASAP at EP1 6) Based on the server pooling policy of pool "new-name", ASAP at
selects the PE (EP2), sets up, if necessary, an SCTP PU selects the destination PE (PEx), sets up, if necessary, an
association towards EP2 (explicitly or implicitly), and send out SCTP association towards PEx (explicitly or implicitly), and
"hello" message. send out the queued "hello1" user message.
4.9.2 Send to a Cached Name 4.8.2 Send to a Cached Pool Handle
This shows the event sequence when the ASAP user at EP1 sends This shows the event sequence when the ASAP user PU sends
another message to the "new-name". another message to the pool "new-name" after what happened in
Section 4.8.1.
ENRP Server PU new-name:PEx
ENRP Server EP1 new-name:EP2
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello world 2" | | +---+ 2. "hello2" |
| |------------------------->| | |---------------->|
| | | | | |
1) The user at EP1 invokes:
data.request("new-name", name-type, "hello world 2", 13, 0); 1) The user at PU invokes:
The ASAP layer, in response, looks up the name "new-name" in its data.send.request("new-name", name-type, "hello2", 6, 0);
The ASAP layer, in response, looks up the pool "new-name" in its
local cache and find the mapping information. local cache and find the mapping information.
2) Based on the server pooling policy of "new-name", ASAP at EP1 2) Based on the server pooling policy of "new-name", ASAP at PU
selects the PE (assume EP2 is selected again), and sends out selects the PE (assume EPx is selected again), and sends out
"hello world 2" message (assume the SCTP association is already set "hello2" message (assume the SCTP association is already set
up). up).
4.10 Handle ASAP to ENRP Communication Failures 4.9 Handle ASAP to ENRP Communication Failures
Three types of failure may occur when the ASAP layer at an endpoint Three types of failure may occur when the ASAP layer at an endpoint
tries to communicate with the ENRP server: 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 ?. Registration failure is discussed in section ?.
4.10.1 SCTP Send Failure 4.9.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 layer should not re-send the failed In such a case, the ASAP layer 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 ?. ENRP server hunt procedure as described in Section ?.
4.10.2 T1-ENRPrequest Timer Expiration 4.9.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 ?. Section ?.
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. should be discarded.
4.10.3 Handle ENDPOINT_KEEP_ALIVE Messages 4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages
At times, a ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages At times, an ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages
(see section 3.1.2.1?) from the ENRP server. This message requires (see Section 3.2.7?) from the ENRP server. This message requires
no response and should be silently discarded by the ASAP no response and should be silently discarded by the ASAP layer.
layer. However, each time when an ENDPOINT_KEEP_ALIVE is received,
the receiver should update its home ENRP server to the sender of the
latest Keep Alive message.
5. Variables, Timer Values, and Thresholds 4.9.4 Home ENRP Server Hunt
The following is a summary of the variables, time values, and At its startup, or when it fails to send to (i.e., timed-out on a
pre-set thresholds used in ASAP and ENRP protocol. service request) with its current home ENRP server, a PE or PU shall
initiate the following home ENRP server hunt procedure to find a
new home server.
5.1 Timer values The PE or PU shall multicast a SERVER_HUNT message over the ENRP
client channel, and shall repeat sending this message every
<TIMEOUT-SERVER-HUNT> seconds until a SERVER_HUNT_RESPONSE message
is received from an ENRP server.
Then the PE or PU shall pick one of the ENRP servers that have
responded as its new home ENRP server, and send all its subsequent
the namespace service requests to this new home ENRP server.
Upon the reception of the SERVER_HUNT message, an ENRP server shall
always reply to the PE with a SERVER_HUNT_RESPONSE message.
5. Variables, Timers, and Constants
The following is a summary of the variables, timers, and pre-set
protocol constants used in ASAP.
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). Normally set to 15 seconds. queued). Normally set to 15 seconds.
T2-registration - A timer started when sending a registration T2-registration - A timer started when sending a registration
request to the local ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T3-registration-reattempt - If the registration cycle does not T3-registration-reattempt - If the registration cycle does not
complete this timer is begun to restart the registration complete, this timer is begun to restart the registration
process. Normal value for this timer is 10 minutes. process. Normal value for this timer is 10 minutes.
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-registration at a periodic interval. This timer is normally set re-registration at a periodic interval. This timer is normally set
to 10 minutes. to 10 minutes.
5.2 Thresholds 5.2 Thresholds
Timeout-registration --- pre-set threshold; how long an PE Timeout-registration - pre-set threshold; how long an PE
will wait for the REGISTRATION_RESPONSE from its home ENRP server. will wait for the REGISTRATION_RESPONSE from its home ENRP server.
Timeout-server-hunt --- pre-set threshold; how long an endpoint will Timeout-server-hunt - pre-set threshold; how long a PE will
wait for the REGISTRATION_RESPONSE from its home ENRP server. wait for the REGISTRATION_RESPONSE from its home ENRP server.
num-of-serverhunts - The current count of server hunt messages that num-of-serverhunts - The current count of server hunt messages that
have been transmitted. have been transmitted.
registration-count - The current count of attempted registrations. registration-count - The current count of attempted registrations.
max-reg-attempt - The maximum number of registration attempts to be max-reg-attempt - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
max-request-retransmit - The maximum number of attempts to be made max-request-retransmit - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
6. References 6. Security Considerations
To be determined.
7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson,
"Stream Control Transmission Protocol," <RFC 2960>, "Stream Control Transmission Protocol," <RFC 2960>,
October 2000. October 2000.
[ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol",
draft-ietf-rserpool-enrp-00.txt, work in progress. draft-ietf-rserpool-enrp-01.txt, work in progress.
7. Acknowledgements [SCTP-API] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon,
K. Fujita "Sockets API Extensions for SCTP",
draft-ietf-tsvwg-sctpsocket-01.txt, work in progress.
The authors wish to thank John Loughney, Lyndon Ong, and 8. Acknowledgements
Maureen Stillman and many others for their invaluable comments.
8. Authors' Addresses The authors wish to thank John Loughney, Lyndon Ong, and Maureen
Stillman and many others for their invaluable comments.
9. Authors' Addresses
Randall R. Stewart Randall R. Stewart
24 Burning Bush Trail. 24 Burning Bush Trail.
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA USA
Phone: +1-815-477-2127 Phone: +1-815-477-2127
EMail: rrs@cisco.com EMail: rrs@cisco.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
 End of changes. 

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