draft-ietf-rserpool-asap-02.txt   draft-ietf-rserpool-asap-03.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
INTERNET-DRAFT Cisco Systems Inc. INTERNET-DRAFT Cisco Systems Inc.
Q. Xie Q. Xie
Motorola Motorola
M. Stillman M. Stillman
Nokia Nokia
expires in six months March 1, 2002 expires in six months May 3, 2002
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
<draft-ietf-rserpool-asap-02.txt> <draft-ietf-rserpool-asap-03.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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination In addition, ASAP defines each logical communication destination
as a pool, providing full transparent support for server-pooling as a pool, providing full transparent support for server-pooling
and load sharing. It also allows dynamic system scalability - and load sharing. It also allows dynamic system scalability -
members of a server pool can be added or removed at any time members of a server pool can be added or removed at 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]. Each transport protocol to be used by Pool
Elements (PE) and Pool Users (PU) MUST have an accompanying
transports mapping document. Note that ASAP messages passed
between PE's and ENRP servers MUST use SCTP.
The high availability server pooling is gained by combining two The high availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for name to address translation, load sharing interface for name to address translation, load sharing
management, and fault management while ENRP defines the high management, and fault management while ENRP defines the high
availability name translation service. availability name translation service.
Table Of Contents Table Of Contents
1. Introduction...............................................3 1. Introduction...............................................3
1.1 Definitions............................................3 1.1 Definitions............................................3
1.2 Organization of this document..........................5 1.2 Organization of this document..........................5
1.3 Scope of ASAP..........................................5 1.3 Scope of ASAP..........................................5
1.3.1 Extent of the Namespace..........................5 1.3.1 Extent of the Namespace..........................5
2. Conventions................................................5 1.4 Conventions........................................... 5
3. Message Definitions........................................5 2. Message Definitions........................................ 6
3.1 ASAP Parameter Formats.................................6 2.1 ASAP Parameter Formats................................. 6
3.1.1 IPv4 Address Parameter...........................7 2.2 ASAP Message Formats................................... 6
3.1.2 IPv6 Address Parameter ..........................7 2.2.1 REGISTRATION message............................. 6
3.1.3 Pool Element Parameter...........................7 2.2.2 DEREGISTRATION message........................... 7
3.1.4 Pool Handle Parameter............................8 2.2.3 REGISTRATION_RESPONSE message.................... 7
3.1.5 Authorization Parameter..........................8 2.2.4 NAME_RESOLUTION message.......................... 8
3.2 ASAP Message Formats...................................9 2.2.5 NAME_RESOLUTION_RESPONSE message................. 8
3.2.1 REGISTRATION message.............................10 2.2.6 NAME_UNKNOWN message............................. 9
3.2.2 DEREGISTRATION message...........................10 2.2.7 ENDPOINT_KEEP_ALIVE message...................... 9
3.2.3 REGISTRATION_RESPONSE message....................11 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message.................. 9
3.2.4 NAME_RESOLUTION message..........................11 2.2.9 ENDPOINT_UNREACHABLE message ....................10
3.2.5 NAME_RESOLUTION_RESPONSE message.................12 2.2.10 SERVER_HUNT message ............................10
3.2.6 NAME_UNKNOWN message.............................12 2.2.11 SERVER_HUNT_RESPONSE message....................10
3.2.7 ENDPOINT_KEEP_ALIVE message......................12 3. Procedures.................................................11
3.2.8 ENDPOINT_UNREACHABLE message ....................12 3.1 Registration............................................11
3.2.9 SERVER_HUNT message .............................13 3.2 Deregistration..........................................12
3.2.10 SERVER_HUNT_RESPONSE message....................13 3.3 Name resolution.........................................13
4. The ASAP Interfaces........................................13 3.4 Endpoint keep alive.....................................14
4.1 Registration.Request Primitive.........................13 3.5 Reporting unreachable endpoints.........................14
4.2 Deregistration.Request Primitive.......................14 3.6 ENRP server hunt procedures.............................14
4.3 Cache.Populate.Request Primitive.......................14 3.7 Handle ASAP to ENRP Communication Failures..............15
4.4 Cache.Purge.Request Primitive..........................14 3.7.1 SCTP Send Failure................................15
4.5 Data.Send.Request Primitive............................14 3.7.2 T1-ENRPrequest Timer Expiration..................15
4.5.1 Sending to a Pool Handle.........................15 4. The ASAP Interfaces........................................16
4.5.2 Pool Element Selection...........................16 4.1 Registration.Request Primitive.........................16
4.5.2.1 Round Robin Policy.......................16 4.2 Deregistration.Request Primitive.......................16
4.5.2.2 Least Used Policy........................17 4.3 Cache.Populate.Request Primitive.......................17
4.5.2.3 Least Used with Degradation Policy.......17 4.4 Cache.Purge.Request Primitive..........................17
4.5.2.4 Weighted Round Robin Policy..............17 4.5 Data.Send.Request Primitive............................17
4.5.3 Sending to a Pool Element Handle.................17 4.5.1 Sending to a Pool Handle.........................18
4.5.4 Send by Transport Address........................18 4.5.2 Pool Element Selection...........................19
4.5.5 Message Delivery Options........................18 4.5.2.1 Round Robin Policy.......................19
4.6 Data.Received Notification.............................19 4.5.2.2 Least Used Policy........................19
4.7 Error.Report Notification..............................20 4.5.2.3 Least Used with Degradation Policy.......20
4.8 Examples...............................................20 4.5.2.4 Weighted Round Robin Policy..............20
4.8.1 Send to a New Pool Handle........................20 4.5.3 Sending to a Pool Element Handle.................20
4.8.2 Send to a Cached Pool Handle.....................21 4.5.4 Send by Transport Address........................21
4.9 Handle ASAP to ENRP Communication Failures.............22 4.5.5 Message Delivery Options........................21
4.9.1 SCTP Send Failure................................22 4.6 Data.Received Notification.............................22
4.9.2 T1-ENRPrequest Timer Expiration..................22 4.7 Error.Report Notification..............................23
4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages..............22 4.8 Examples...............................................23
4.9.4 Home ENRP Server Hunt............................23 4.8.1 Send to a New Pool Handle........................23
5. Variables, Timers, and Constants...........................23 4.8.2 Send to a Cached Pool Handle.....................24
5.1 Timers.................................................23 4.9 PE send failure........................................25
5.2 Thresholds.............................................23 4.9.1 Translation.Request Primitive....................25
6. Security Considerations....................................24 4.9.2 Transport.Failure Primitive......................25
7. References.................................................24 5. Variables, Timers, and Constants...........................25
8. Acknowledgements...........................................24 5.1 Timers.................................................25
9. Authors' Addresses.........................................24 5.2 Thresholds.............................................26
6. Security Considerations....................................26
7. References.................................................27
8. Acknowledgments............................................27
9. Authors' Addresses.........................................28
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.
skipping to change at page 3, line 40 skipping to change at page 3, line 49
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 the 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 availability 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: ASAP User:
Either a PE or PU that uses ASAP. Either a PE or PU that uses ASAP.
Operation scope: Operation scope:
skipping to change at page 4, line 29 skipping to change at page 4, line 36
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 uses. A PU The ENRP server to which a Pool Element currently uses. A PU
or PE normally chooses the ENRP server on their local host as or PE normally chooses the ENRP server on their local host as
the home ENRP server (if one exists). A PU or PE should only the home ENRP server (if one exists). A PU or PE should only
have one home ENRP server at any given time. have one home ENRP server at any given time. Note that the
"home" ENRP server concept exists only within ASAP. ENRP
servers provide no special handling of PE's or PU's. Having
a "home" ENRP server only provides a mechanism to minimize
the number of associations a given PE will have.
ENRP client channel: ENRP client channel:
The communication channel through which an ASAP User (either a The communication channel through which an ASAP User (either a
PE or PU) requests ENRP namespace service. The client channel PE or PU) requests ENRP namespace service. The client channel
is usually defined by the transport address of the is usually defined by the transport address of the
home server and a well known port number. home server and a well known port number. The channel MAY
make use of multi-cast or a named list of ENRP servers.
ENRP server channel: ENRP server channel:
Defined by a well known multicast IP address and a well Defined by a well known multicast IP address and a well known port
known port number, or a well known list of transport number, OR a well known list of transport addresses for a group of
addresses for a group of ENRP servers spanning an ENRP servers spanning an operational scope. All ENRP servers in an
operational scope. All ENRP servers in an operation scope operation scope can communicate with one another through this
can communicate with one another through this channel. channel via either multicast OR direct point to point SCTP
associations.
ENRP name domain: ENRP name domain:
Defined by the combination of the ENRP client 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: Network Byte Order:
Most significant byte first, a.k.a Big Endian. Most significant byte first, a.k.a Big Endian.
Transport address: Transport address:
A Transport Address is traditionally defined by Network Layer A Transport Address is traditionally defined by Network Layer
skipping to change at page 5, line 34 skipping to change at page 5, line 45
share any state. share any state.
1.3.1 Extent of the Namespace 1.3.1 Extent of the Namespace
The scope of the ASAP/ENRP is NOT Internet wide. The namespace is The scope of the ASAP/ENRP is NOT Internet wide. The namespace is
neither hierarchical nor arbitrarily large like DNS. We propose a neither hierarchical nor arbitrarily large like DNS. We propose a
flat peer-to-peer model. Pools of servers will exist in different flat peer-to-peer model. Pools of servers will exist in different
administrative domains. For example, suppose we want to use administrative domains. For example, suppose we want to use
ASAP/ENRP. First, the PU may 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 wishes 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 list of
address of the Japanese server pool domain, that is, the address of IP addresses of the Japanese server pool domain, that is,
an ENRP server(s) in Japan. From there the PU would query the the ENRP client channel 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 1.4 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Message Definitions 2. Message Definitions
All messages as well as their fields described below shall be in All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length Network Byte Order during transmission. For fields with a length
bigger than 4 octets, a number in a pair of parentheses may follow bigger than 4 octets, a number in a pair of parentheses may follow
the filed name to indicate the length of the field in number of the filed name to indicate the length of the field in number of
octets. octets.
3.1 ASAP Parameter Formats 2.1 ASAP Parameter Formats
ASAP parameters are defined in a Type-length-value (TLV) format as
shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Parameter Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 16 bits (unsigned integer)
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 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 = 0x1 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer)
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 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 = 0x2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer)
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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Port | Number of IP addrs=k |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #0 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ..... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #k :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Policy Type | Policy Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Life |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the IP address parameters in a PE parameter can be either
an IPv4 or IPv6 address parameter.
3.1.4 Pool Handle Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Handle :
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter holds a pool handle that is a NULL terminated ASCII
string.
3.1.5 Authorization Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Authorization Signature :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Msg Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Message Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) The basic message format and all parameter formats can be found
in [ENRP-ASAP]. Note also that ALL ASAP message exchanged between
the ENRP server and either a PE or PU MUST user SCTP. PE to PU
data traffic MAY use any transport protocol specified by the PE
during registration.
This value represents the size of the message in bytes including 2.2 ASAP Messages
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 This section details the individual messages used by ASAP. These
messages are composed of a standard message format found in
Section 4 or [ENRP-ASAP], elements and parameters. The parameter
descriptions may also be found in Section 3 of [ENRP-ASAP].
The Message Value field contains the actual information to be The following ASAP message types are defined in this section:
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 Type Message Name
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 0x00 - (reserved by IETF)
message with all zero bytes and this padding is not included in the 0x01-0x06 - defined by [ENRP]
message length field. The sender should never pad with more than 3 0x07 - Registration
bytes. The receiver MUST ignore the padding bytes. 0x08 - Deregistration
0x09 - Registration Response
0x0a - Name Resolution
0x0b - Name Resolution Response
0x0c - Name Unknown
0x0d - Endpoint Keep Alive
0x0e - Endpoint Keep Alive Acknowledgement
0x0f - Endpoint Unreachable
0x10 - Server Hunt
0x11 - Server Hunt Response
3.2.1 REGISTRATION message 2.2.1 REGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle : : Pool Handle :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the name to be registered. The pool handle parameter field specifies the name to be registered.
The PE Parameter field shall be filled in by the registrant The PE Parameter field shall be filled in by the registrant endpoint
endpoint to declare its transport addresses, server pooling to declare its transports and addresses, server pooling policy and
policy and value, and other operation preferences. value, and other operation preferences. Note that the registration
message MUST use SCTP and the IP addresses of the PE registered
within the Pool Element Parameter MUST be a subset of the addresses
of the SCTP association irrespective of the transport protocol
regestered by the PE.
3.2.2 DEREGISTRATION message 2.2.2 DEREGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : | PE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PE sending the DEREGISTRATION shall fill in the pool handle The PE sending the DEREGISTRATION shall fill in the pool handle
and the PE Parameter in order to allow the ENRP server to verify and the PE identifier in order to allow the ENRP server to verify
the identity of the endpoint. the identity of the endpoint. Note that deregistration is NOT
allowed by proxy, in other words only a PE may only deregister
itself.
3.2.3 REGISTRATION_RESPONSE message 2.2.3 REGISTRATION_RESPONSE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action code | Result code | (reserved) | | Action code | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Error (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: (8 bits) Action: (8 bits)
The message that this results code is in response to: The message that this results code is in response to:
0x0 -- registration 0x0 -- registration
0x1 -- de-registration 0x1 -- de-registration
Result code: (8 bits) Reserved: (24 bits)
0x0 -- request granted Ignored by the receiver and set to 0 by the sender.
0x1 -- request denied, unspecifed
0x2 -- request denied, authorization failure
0x3 -- request denied, invalid values
Reserved: (16 bits) Operational Error
Ignored by the receiver and set to 0 by the sender. This optional TLV parameter is included if an error
occured during the registration/deregistration process.
If the registration/deregistration was sucessful this
parameter is not included.
3.2.4 NAME_RESOLUTION message 2.2.4 NAME_RESOLUTION message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | | Type = 0xa |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5 NAME_RESOLUTION_RESPONSE message This message is sent to a ENRP server via an SCTP association to
request translation of the Pool Handle to a list of Pool Elements.
2.2.5 NAME_RESOLUTION_RESPONSE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | | Type = 0xb |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 : : Pool Element Parameter 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N : : Pool Element Parameter N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.6 NAME_UNKNOWN message Overall PE Selection Policy:
This is a PE selection policy parameter. Indicates the overall selection
policy of the pool. If not present, round-robin is assumed.
Note, any load policy parameter inside the Pool Element Parameter
(if present) MUST be ignored, and MUST NOT be used to determine
the overall pool policy.
2.2.6 NAME_UNKNOWN message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | | Type = 0xc |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.7 ENDPOINT_KEEP_ALIVE message This message is returned by the ENRP server to indicate that
the requested Pool Handle hold no registered PE's.
2.2.7 ENDPOINT_KEEP_ALIVE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | | Type = 0xd |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8 ENDPOINT_UNREACHABLE message This message is sent to a PE by the ENRP server has a "health"
check. If the transport level Heart Beat mechanism is insufficient
(usually this means that time outs are set for too long or
heartbeats are not frequent enough), this adds heartbeat messages
with the goal of determining health status in a more timely fashion.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | | Type = 0xe |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : | PE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by the PE to the ENRP server has an
acknowledgment to the ENDPOINT_KEEP_ALIVE message.
2.2.9 ENDPOINT_UNREACHABLE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xa |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.9 SERVER_HUNT message A PE or PU will send this message to an ENRP server to report the
unreachability of the specified PE.
2.2.10 SERVER_HUNT message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xa |0|0|0|0|0|0|0|0| Message Length : | Type = 0x10 |0|0|0|0|0|0|0|0| Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10 SERVER_HUNT_RESPONSE message This message is used by either a PE or PU to request service. It
is sent on the ENRP client channel.
2.2.11 SERVER_HUNT_RESPONSE message
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xb |0|0|0|0|0|0|0|0| Message Length | | Type = 0x11 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : : Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is used by a ENRP server to respond to a PU or PE. It
is sent over a specific SCTP association which is established using
the IP address and Port number received by the ENRP server in the
respective Server Hunt message that this message is in response to.
3. Procedures
This chapter will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed.
3.1 Registration
When a PE wishes to join its server pool it MUST use the procedures
outlined in this section to register. Often the registration will
be triggered by a user request primitive (discussed in Section 4.1).
The ASAP endpoint MUST register using an SCTP association between
the ASAP endpoint and the ENRP server. If the ASAP endpoint has not
established its Home ENRP server it MUST follow the procedures
specified in Section 3.6 to establish its Home ENRP server.
Once the ASAP endpoint has established its Home ENRP server the
following procedures MUST be followed to register:
R1) The SCTP endpoint used to communicate with the ENRP server
MUST be bound to all IP addresses that will be used by
the PE (irregardless of what protocol will be used to
service user requests to the PE).
R2) The ASAP endpoint MUST formulate a Registration message
as defined in Section 2.2.1. In formulating the message
the ASAP endpoint MUST:
R2.1) Fill in the the Pool Handle to specify which
server pool the ASAP endpoint wishes to join.
R2.2) Fill in a PE identifier using a good quality randomly
generated number ([RFC1750] provides some information
on randomness guidelines).
R2.3) Fill in the registration life time parameter with
the number of seconds that this registration is
good for. Note a PE that wishes to continue service
MUST re-register after the registration expires.
R2.4) Fill in a User Transport Parameter for EACH type
of transport the PE is willing to support.
R2.5) Fill in the preferred Member selection policy.
R2.6) Fill in any optional authorization parameter,
if required.
R3) Send the Registration request to the Home ENRP server
using SCTP.
R4) Start a T2-registration timer.
If the T2-registration timer expires before receiving a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the Server
Hunt procedure (see Section 3.6) in an attempt to get service
from a different ENRP server. After establishing a new Home
ENRP server the ASAP endpoint SHOULD restart the registration
procedure.
At the reception of the registration response, the ASAP endpoint
MUST stop the T2-Registration timer. If the response indicated
success, then the PE is now registered and will be considered an
available member of the server pool. If the registration response
indicates a failure, the ASAP endpoint must either re-attempt
registration after correcting the error or return a failure
indication to the ASAP endpoints upper layer. The ASAP endpoint MUST
NOT re-attempt registration without correcting the error condition.
At any time a registered PE MAY wish to re-register to either update
its member selection policy value or registration expiration
time. When re-registering the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting
at step R1 including (at completion) restarting the T4-reregistration
timer.
Note that an implementation SHOULD keep a record of the number of
registration attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count
exceeds the Threshold 'max-reg-attempt' the implementation SHOULD
report the error to its upper layer and stop attempting
registration.
3.2 Deregistration
In the event the PE wishes to deregister from its server pool
(normally via an upper layer requests see section 4.2) it SHOULD use
the following procedures. Note that an alternate method of
deregistration is to NOT re-register and to allow the registration
lift time to expire.
When deregistering the PE SHOULD use the same SCTP association with
its Home ENRP server that was used for registration. To deregister
the ASAP endpoint MUST take the following actions:
D1) Fill in the Pool Handle parameter of the Deregistration
message (Section 2.2.2) using the same Pool Handle parameter
sent during registration.
D2) Fill in the PE Identifier. The identifier MUST be the same
one used during registration.
D3) Fill in any optional authorization parameter, if required.
D4) Send the deregistration message to the Home ENRP server
using the SCTP association.
D5) Start a T3-Deregistration timer.
If the T3-Deregistration timer expires before receiving a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the
Server Hunt procedure (see Section 3.6) in an attempt to get service
from a different ENRP server. After establishing a new Home ENRP
server the ASAP endpoint SHOULD restart the deregistration
procedure.
At the reception of the deregistration response, the ASAP
endpoint MUST stop the T3-deregistration timer.
Note that after a successful deregistration the PE MAY still receive
requests for some period of time. The PE MAY wish to still remain
active and service these requests or may wish to ignore these
requests and exit.
3.3 Name resolution
At any time a PE or PU may wish to resolve a name. This usually
will occur when a Endpoint sends to a Pool handle (Section 4.5)
or requests a cache population (4.3) but may occur for other
reasons (e.g. the internal ASAP PE wishes to know its peers for
sending a message to all of them). When an Endpoint (PE or PU)
wishes to resolve a name it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message (section 2.4) with
the Pool Handle to be resolved.
NR2) Fill in any optional authorization parameter, as required.
NR2.1) If the endpoint does not have a Home ENRP server start
the ENRP Server Hunt procedures specified in section
3.6 to obtain one. Otherwise proceed to step NR3.
NR3) Send the NAME_RESOLUTION message to the Home ENRP server
using SCTP.
NR4) Start a T1-ENRPrequest timer.
If the T1-ENRPrequest timer expires before receiving a response
message, or a SEND.FAILURE notification is received from the SCTP
layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see
Section 3.6) in an attempt to get service from a different ENRP
server. After establishing a new Home ENRP server the ASAP endpoint
SHOULD restart the name resolution procedure.
At the reception of the response message (either a
NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its
T1-ENRPrequest timer. After stopping the T1 timer the endpoint
SHOULD process the name response as appropriate (e.g. populate a
local cache, give the response to the ASAP user, and/or use the
response to send the ASAP users message).
Note that some ASAP endpoints MAY use a cache to minimize
the number of name resolutions made. If such a cache is used
it SHOULD:
C1) Be consulted before requesting a name resolution.
C2) Have a stale timeout time associated with the cache
so that even in the event of a cache-hit, if the
cache is "stale" it will cause a new name_resolution
to be issued to update the cache.
C3) In the case of a "stale" cache the implementation may
in parallel request an update and answer the request or
block the user and wait for an updated cache before
proceeding with the users request.
C4) If the cache is NOT stale, the endpoint SHOULD NOT
make a name_resolution request but instead return
the entry from the cache.
3.4 Endpoint keep alive
Periodically an ENRP server may choose to "audit" a PE. It
does this by sending a ENDPOINT_KEEP_ALIVE message
(Section 2.2.7). Upon reception of an ENDPOINT_KEEP_ALIVE
message the following actions MUST be taken:
KA1) The PE must verify that the Pool Handle is correct
and matches the Pool Handle sent in its earlier
Registration. If the Pool Handle does not match
silently discard the message.
KA2) If an authorization parameter is included the
endpoint SHOULD verify that the message is authentic. If
the verification fails, silently discard the message.
KA3) Send a ENDPOINT_KEEP_ALIVE_ACK (section 2.2.8) by:
KA3.1) Filling in the Pool Handle Parameter with the
PE's Pool Handle.
KA3.2) Fill in the PE Identifier that was used with this
PE for registration.
KA3.3) Fill in any optional authorization parameter,
as required.
KA3.4) Send off the ENDPOINT_KEEP_ALIVE_ACK message via
the appropriate SCTP association for that ENRP server.
3.5 Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP
endpoint or via a ASAP user report via the Error.Report primitive
(section 4.7). In either case the ASAP endpoint SHOULD report the
unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message
to its home ENRP server. The Endpoint should fill in the Pool Handle
and PE identifier of the unreachable endpoint and any authorization
parameter that may be required. The message MUST be sent via SCTP to
the Endpoints Home ENRP server.
3.6 ENRP server hunt procedures
At its startup, or when it fails to send to (i.e., timed-out on a
service request) with its current home ENRP server, a PE or PU shall
initiate the following home ENRP server hunt procedure to find a
new home server.
SH1) The PE or PU shall send a SERVER_HUNT message (Section
2.2.10) over the ENRP client channel. If the client channel
is a multi-cast destination only one message is needed. If
the client channel is a set of uni-cast addresses then a
message SHOULD be sent to no more than three ENRP server unicast
address. A Endpoint MUST NOT send to more than three at
any single time.
SH2) The Endpoint shall start a T5-Serverhunt timer.
SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message
the endpoint MUST stop its T5-Serverhunt timer.
The Endpoint SHOULD also reset the T5-Serverhunt value
to its initial value and then proceed to step SH5.
SH4) If the T5-Serverhunt timer expires the following should be
performed:
SH4.1) The endpoint MUST double the value of the T5-Serverhunt timer.
SH4.2) The endpoint SHOULD Repeat sending a server hunt
message by proceeding to step SH1. Note that
if the server hunt procedure are using a unicast channel
the endpoint SHOULD attempt to select a different set
of ENRP servers to send the SERVER_HUNT message to.
SH5) The PE or PU shall pick one of the ENRP servers that have
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.
3.7 Handle ASAP to ENRP Communication Failures
Three types of failure may occur when the ASAP endpoint at an endpoint
tries to communicate with the ENRP server:
A) SCTP send failure
B) T1-ENRPrequest timer expiration
C) Registration failure
Registration failure is discussed in section 4.1.
3.7.1 SCTP Send Failure
This indicates that the SCTP layer failed to deliver a message sent
to the ENRP server. In other words, the ENRP server is currently
unreachable.
In such a case, the ASAP endpoint should not re-send the failed
message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section 3.6.
3.7.2 T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the
original request to the ENRP server and re-start the T1-ENRPrequest
timer. In parallel, a SERVER_HUNT message should be issued per
Section 3.6.
This should be repeated up to 'max-request-retransmit' times. After
that, an Error.Report notification should be generated to inform the
ASAP user and the ENRP request message associated with the timer
should be discarded. Note that if an alternate ENRP server responds
the ASAP endpoint SHOULD adopt the responding ENRP server as its
new "home" server and resend the request to the new "home" server.
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
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
management are also discussed.
An ASAP User 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(poolHandle) Format: registration.request(poolHandle,
User Transport parameter(s))
where the poolHandle parameter contains a NULL terminated ASCII The poolHandle parameter contains a NULL terminated ASCII
string of fixed length. string of fixed length. The optional User Transport parameter(s)
indicate specific transport parameters and types to register with.
If this optional parameter is left off, then the SCTP endpoint
used to communicate with the ENRP server is used as the default
User Transport parameter. Note that any IP address contained
within a User Transport parameter MUST be a bound IP address in
the SCTP endpoint used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the The ASAP user invokes this primitive to add itself to the
namespace, thus becoming a Pool Element of a pool. The ASAP user namespace, thus becoming a Pool Element of a pool. The ASAP user
must register itself with the ENRP server by using this primitive must register itself with the ENRP server by using this primitive
before other ASAP users using the namespace can send message(s) to before other ASAP users using the namespace can send message(s) to
this ASAP user by pool handle or by PE handle (see Sections 4.5.1 this ASAP user by Pool Handle or by PE handle (see Sections 4.5.1
and 4.5.2). and 4.5.2).
In response to the registration primitive, the ASAP layer will send In response to the registration primitive, the ASAP endpoint will send
a REGISTRATION message to the home ENRP server (See section 3.2.1), a REGISTRATION message to the home ENRP server (See Section 2.2.1 and
and start a T2-registration timer. Section 3.1), and start a T2-registration timer.
If the T2-registration timer expires before receiving a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP layer shall start the Server
Hunt procedure (see Section 4.9.4) in an attempt to get service
from a different ENRP server.
4.2 Deregistration.Request Primitive 4.2 Deregistration.Request Primitive
Format: deregistration.request(poolHandle) Format: deregistration.request(poolHandle)
The ASAP PE invokes this primitive to remove itself from the The ASAP PE invokes this primitive to remove itself from the
Server 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 endpoint to the home ENRP
server (see Section 3.2.2). server (see Section 2.2.2 and Section 3.2).
4.3 Cache.Populate.Request Primitive 4.3 Cache.Populate.Request Primitive
Format: cache.populate.request(destinationAddress, typeOfAddress) Format: cache.populate.request([Pool-Handle | Pool-Element-Handle])
If the address type is a Pool handle and a local name If the address type is a Pool handle and a local name translation
translation cache exists, the ASAP layer should initiate a mapping cache exists, the ASAP endpoint should initiate a mapping
information query by sending a NAME.RESOLUTION message on the Pool information query by sending a NAME.RESOLUTION message on the Pool
handle and update it local cache when the response comes back from handle and update it local cache when the response comes back from
the ENRP server. the ENRP server.
The destinationAddress field contains the address for which the If a Pool-Element-Handle is passed then the Pool Handle is unpacked
cache needs to be populated. The typeOfAddress indicates the address from the Pool-Element-Handle and the NAME.RESOLUTION message is sent
type. Allowable types are Pool handle and Pool Element handle. In to the ENRP server for resolution. When the response message returns
the case of a Pool Element handle, the Pool handle is extracted from from the ENRP server the local cache is updated.
the Pool Element handle and used to form a NAME.RESOLUTION
message (see Section 3.5). Note that if the ASAP service does NOT support a local cache
this primitive performs NO action.
4.4 Cache.Purge.Request Primitive 4.4 Cache.Purge.Request Primitive
Format: cache.purge.request(destinationAddress, typeOfAddress) Format: cache.purge.request([Pool-Handle | Pool-Element-Handle])
If the address type is a Pool handle and local name If the user passes a Pool handle and local name translation cache
translation cache exists, the ASAP layer should remove the mapping exists, the ASAP endpoint should remove the mapping information on
information on the Pool handle from its local cache. the Pool handle from its local cache. If the user passes a
Pool-Element-Handle then the Pool handle within is used for the
cache.purge.request.
Note that if the ASAP service does NOT support a local cache this
primitive performs NO action.
4.5 Data.Send.Request Primitive 4.5 Data.Send.Request Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data.send.request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified This primitive requests ASAP to send a message to some specified
Pool 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 senders ASAP endpoint may perform address translation and Pool
selection before sending the message out. Element selection before sending the message out. This also MAY
dictate the creation of a local transport endpoint in order to meet
the required transport type.
The data.send.request primitive can take different forms of The data.send.request primitive can take different forms of address
address types as described in the following sections. types as described in the following sections.
4.5.1 Sending to a Pool Handle 4.5.1 Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a pool handle. indicates a pool handle.
This is the simplest form of send.data.request primitive. By This is the simplest form of send.data.request primitive. By
default, this directs ASAP to send the message to one of the Pool default, this directs ASAP to send the message to one of the Pool
Elements in the specified pool. Elements in the specified pool.
Before sending the message out to the pool, the sender's ASAP layer Before sending the message out to the pool, the senders ASAP
MUST first perform a pool handle to address translation. It may endpoint MUST first perform a pool handle to address translation. It
also need to perform Pool Element selection if multiple Pool may also need to perform Pool Element selection if multiple Pool
Elements exist in the pool. Elements exist in the pool.
If the sender's ASAP implementation does not support a local cache If the senders ASAP implementation does not support a local cache
of the mapping information or if it does not have the mapping of the mapping information or if it does not have the mapping
information on the pool in its local cache, it will transmit a information on the pool in its local cache, it will transmit a
NAME.RESOLUTION message to the current home ENRP server, and NAME.RESOLUTION message (see Section 2.2.4 and Section 3.3) to the
MUST hold the outbound message in queue while awaiting the response current home ENRP server, and MUST hold the outbound message in
from the ENRP server (any further send request to this pool before queue while awaiting the response from the ENRP server (any further
the ENRP server responds SHOULD also be queued). send request to this pool before 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 senders ASAP will:
A) map the pool handle into a list of transport addresses of the A) map the pool handle into a list of transport addresses of the
destination PE(s), destination PE(s),
B) if multiple PEs exist in the pool, ASAP will choose B) if multiple PEs exist in the pool, ASAP will choose
one of them 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 endpoint of the sender based on
the server pooling policy as discussed in section 4.5.2. the server pooling policy as discussed in section 4.5.2.
C) if no transport association exists towards the destination PE, C) Optionally create any transport endpoint that may be needed to
ASAP will establish a new transport association, communicate with the PE selected.
NOTE: if the underlying SCTP implementation supports implicit D) if no transport association or connection exists towards the
association setup, this step is not needed (see [SCTPAPI]). destination PE, ASAP will establish any needed transport state,
D) send out the queued message(s) to the SCTP association using the E) send out the queued message(s) to the appropriate transport
SEND primitive (see [RFC2960]), and, connection using the appropriate send mechanism (e.g. for
E) if the local cache is implemented, append/update the local cache SCTP the SEND primitive in [RFC2960] would be used), and,
F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local SCTP association id, if a new response. Also, record the local transport information (e.g.
association was created. the SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures see [ENRP]. For more on the ENRP server request procedures see [ENRP].
Optionally, the ASAP layer of the sender may return a Pool Element Optionally, the ASAP endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that same PE (see Section 4.5.3). that same PE (see Section 4.5.3).
Section 4.5.5 defines the fail-over procedures for cases where the Section 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 an ASAP user sends a message to a pool that contains Each time an ASAP user sends a message to a pool that contains more
more than one PE, the sender's ASAP layer must select one of than one PE, the senders ASAP endpoint must select one of the PEs
the PEs in the pool as the receiver of the current in the pool as the receiver of the current message. The selection is
message. The selection is done according to the current server done according to the current server pooling policy of the pool to
pooling policy of the pool to which the message is sent. which the message is sent.
Note, no selection is needed if the ASAP_SEND_TOALL option is set Note, no selection is needed if the ASAP_SEND_TOALL option is set
(see Section 4.5.5). (see Section 4.5.5).
When joining a pool, along with its registration each Together with the server pooling policy, each PE can also
PE specifies its preferred server pooling policy for receiving specify a Policy Value for itself at the registration time. The
messages sent to this pool. But only the server pooling
policy specified by the first PE joining the pool will
become the current server pooling policy of the group.
Moreover, together with the server pooling policy, each PE can
also specify a Policy Value for itself at the registration time. The
meaning of the policy value 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
whenever it desires, by re-registering itself with the namespace it desires, by re-registering itself with the namespace with a new
with a new policy value. Re-registration shall be done by simply policy value. Re-registration shall be done by simply sending
sending another REGISTRATION to its home ENRP server. another REGISTRATION to its home ENRP server (See section 3.1).
Note, if this first PE removes itself from the pool
(e.g., by de-registration from the name space) and the remaining
PEs have specified conflicting server pooling policies at
their corresponding registrations, it is implementation specific to
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 Round Robin Policy 4.5.2.1 Round Robin Policy
When a ASAP endpoint sends messages by Pool Handle and Round-Robin When a ASAP endpoint sends messages by Pool Handle and Round-Robin
is the current policy of that Pool, the ASAP layer of the sender is the current policy of that Pool, the ASAP endpoint of the sender
will select the receiver for each outbound message by round-Robining will select the receiver for each outbound message by round-Robining
through all the registered PEs in that Pool, in an attempt to 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 server may NOT send back all PEs large server pool, the ENRP server MAY NOT send back all PEs to the
to the ASAP client. In this case the client or PU will be ASAP client. In this case the client or PU will be performing a
performing a round robin policy on a subset of the entire Pool. round robin policy on a subset of the entire Pool.
4.5.2.2 Least Used Policy 4.5.2.2 Least Used Policy
When the destination Pool is under the Least Used server pooling When the destination Pool is under the Least Used server pooling
policy, the ASAP layer of the message sender will select the PE that policy, the ASAP endpoint of the message sender will select the PE that
has the lowest policy value in the group as the receiver of the 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 (via a cache update see section 3.3).
4.5.2.3 Least Used with Degradation Policy 4.5.2.3 Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception This policy is the same as the Least Used policy with the exception
that, each time the PE with the lowest policy value is selected from that, each time the PE with the lowest policy value is selected from
the Pool as the receiver of the current message, its policy value is the Pool as the receiver of the current message, its policy value is
incremented, and thus it may no longer be the lowest value in the incremented, and thus it may no longer be the lowest value in the
Pool. Pool.
This provides a degradation of the policy towards round Robin policy This provides a degradation of the policy towards round Robin policy
skipping to change at page 17, line 49 skipping to change at page 20, line 32
4.5.2.4 Weighted Round Robin Policy 4.5.2.4 Weighted Round Robin Policy
[TBD] [TBD]
4.5.3 Sending to a Pool Element Handle 4.5.3 Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate an ASAP Pool Element handle. indicate an ASAP Pool Element handle.
This requests the ASAP layer to deliver the message to the PE This requests the ASAP endpoint to deliver the message to the PE
identified by the Pool Element handle. identified by the Pool Element handle.
The Pool Element handle should contain the poolHandle and a The Pool Element handle should contain the Pool Handle and a
destination transport address of the destination PE or the destination transport address of the destination PE or the
poolHandle and the SCTP 'association id'. Pool Handle and the transport type. Other implementation
dependant elements may also be cached in a Pool Element handle.
The ASAP layer shall use the transport address to identify the The ASAP endpoint shall use the transport address and transport type
SCTP association (or to setup a new one if necessary) and then to identify the endpoint to communicate with. If no communication
invoke the SCTP SEND primitive to send the message to the PE. state exists with the peer endpoint (and is required by the
transport protocol) the ASAP endpoint MAY setup the needed state and
then invoke the SEND primitive for the particular transport
protocol to send the message to the PE.
In addition, if a local translation cache is supported the In addition, if a local translation cache is supported the
endpoint will: endpoint will:
A) send out the message to the transport address (or association A) send out the message to the transport address (or association
id) designated by the PE handle. id) designated by the PE handle.
B) determine if the pool handle is in the local cache. B) determine if the Pool Handle is in the local cache.
If it is NOT, the endpoint will: If it is NOT, the endpoint will:
i) ask the home ENRP server for name resolution on pool handle i) ask the home ENRP server for name resolution on pool handle
by sending a NAME.RESOLUTION message, and by sending a NAME.RESOLUTION message (see Section 3.3), and
ii) use the response to update the local cache. ii) use the response to update the local cache.
If the pool handle is in the cache, the endpoint will only If the pool handle is in the cache, the endpoint will only
update the pool handle if the cache is stale. A stale cache is update the pool handle if the cache is stale. A stale cache is
indicated by it being older than the protocol parameter indicated by it being older than the protocol parameter
'stale.cache.value'. 'stale.cache.value' (see section 3.3).
Section 4.5.5? defines the fail-over procedures for cases where Section 3.5 and 4.9 defines the fail-over procedures for cases where
the PE pointed to by the Pool Element handle is found unreachable. 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 endpoint may return the actual Pool Element 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
indicate an SCTP transport address. indicate a transport address and transport type.
This directs the sender's ASAP layer to send the message out to the This directs the senders ASAP endpoint to send the message out to the
specified transport address. specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint fail-over is support when this form of send request is
used. This form of send request effectively by-passes the ASAP used. This form of send request effectively by-passes the ASAP
layer. endpoint.
4.5.5 Message Delivery Options 4.5.5 Message Delivery Options
The Options parameter passed in the various forms of the above The Options parameter passed in the various forms of the above
data.send.request primitive gives directions to the sender's ASAP data.send.request primitive gives directions to the senders ASAP
layer on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise The value of the Options parameter is generated by bit-wise "OR"ing
"OR"ing of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 ASAP_USE_DEFAULT: 0x0000
Use default setting. Use default setting.
ASAP_SEND_FAILOVER: 0x0001 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 PE handle is found selected PE or the PE pointed to by the PE handle is found
unreachable, this option allows the sender's ASAP layer to unreachable, this option allows the senders ASAP endpoint to
re-select an alternate PE from the same pool if one exists, and re-select an alternate PE from the same pool if one exists, and
silently re-send the message to this newly selected endpoint. silently re-send the message to this newly selected endpoint.
Endpoint unreachable is normally indicated by the SCTP
COMMUNICATION.LOST or SEND.FAILURE notification.
ASAP_SEND_NO_FAILOVER: 0x0002 ASAP_SEND_NO_FAILOVER: 0x0002
This option prohibits the senders ASAP endpoint 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 pointed to by the PE handle is found unreachable. Instead, the PE pointed to by the PE handle is found unreachable. Instead,
the sender's ASAP layer shall notify its upper layer about the the senders ASAP endpoint shall notify its upper layer about the
unreachability with an Error.Report and return 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 senders ASAP endpoint to send the message to
the same PE in the pool that the previous message destined to this the same PE in the pool that the previous message destined to this
pool was sent to. pool was sent to.
ASAP_SEND_TO_ALL: 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 senders ASAP
layer to send a copy of the message to all the PEs, except for the endpoint to send a copy of the message to all the PEs, except for
sender itself if the sender is a PE, in that pool. the sender itself if the sender is a PE, in that pool.
ASAP_SEND_TO_SELF: 0x0010. ASAP_SEND_TO_SELF: 0x0010.
This option only applies in combination with ASAP_SEND_TO_ALL 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 senders ASAP endpoint also deliver a copy of the
message to itself if the sender is a PE of the pool (i.e., loopback). message to itself if the sender is a PE of the pool (i.e., loop-back).
ASAP_SCTP_UNORDER: 0x1000 ASAP_SCTP_UNORDER: 0x1000
This option instructs the SCTP transport layer to send the current This option requests the transport layer to send the current
message using un-ordered delivery. message using un-ordered delivery (note the underlying transport
must support un-ordered delivery for this option to be effective).
4.6 Data.Received Notification 4.6 Data.Received Notification
Format: data.received(messageReceived, sizeOfMessage, senderAddress, Format: data.received(messageReceived, sizeOfMessage, senderAddress,
typeOfAddress) typeOfAddress)
When a new user message is received, the ASAP layer of the receiver When a new user message is received, the ASAP endpoint 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 endpoint of the receiver
should also indicate to its upper layer the message sender's should also indicate to its upper layer the message senders
address. The sender's address can be in the form of either an SCTP address. The senders address can be in the form of either an SCTP
association id, or a ASAP Pool Element handle. association id, TCP transport address, UDP transport address, 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 endpoint, a reverse mapping from the senders IP
address to the pool handle should be performed and if the mapping is address to the pool handle should be performed and if the mapping is
successful, the sender's ASAP Pool Element handle should be successful, the senders ASAP Pool Element handle should be
constructed and passed in the senderAddress field. constructed and passed in the senderAddress field.
B) If there is no local cache or the reverse mapping is not B) If there is no local cache or the reverse mapping is not
successful, the SCTP association id should be passed in the successful, the SCTP association id or other transport
senderAddress field. specific identification (if SCTP is not being used) should be
passed in the 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.
? 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 Examples 4.8 Examples
These examples assume an underlying SCTP transport between the PE
and PU. Other transports are possible but SCTP is utilized in the
examples for illustrative purposes. Note that all communication
between PU and ENRP server and PE and ENRP servers would be using
SCTP.
4.8.1 Send to a New Pool 4.8.1 Send to a New Pool
This example shows the event sequence when a Pool User sends the This example shows the event sequence when a Pool User sends the
message "hello" to a pool which is not in the local message "hello" to a pool which is not in the local
translation cache (assuming local caching is supported). translation cache (assuming local caching is supported).
ENRP Server PU new-name:PEx ENRP Server PU new-name:PEx
| | | | | |
| +---+ | | +---+ |
skipping to change at page 21, line 18 skipping to change at page 24, line 7
| +---+ | | +---+ |
| | 5 | | | | 5 | |
| +---+ 6. "hello1" | | +---+ 6. "hello1" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data.send.request("new-name", name-type, "hello1", 6, 0); data.send.request("new-name", name-type, "hello1", 6, 0);
The ASAP layer, in response, looks up the pool "new-name" in its The ASAP endpoint, 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 PU queues the message, and sends a 2) The ASAP endpoint of PU queues the message, and sends a
NAME_RESOLUTION request to the ENRP server asking for all NAME_RESOLUTION request to the ENRP server asking for all
information about pool "new-name". information about pool "new-name".
3) A T1-ENRPrequest timer is started while the ASAP layer is waiting 3) A T1-ENRPrequest timer is started while the ASAP endpoint 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 pool "new-name". about pool "new-name".
5) ASAP at PU cancels the T1-ENRPrequest timer and populate its 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its
local cache with information on pool "new-name". local cache with information on pool "new-name".
6) Based on the server pooling policy of pool "new-name", ASAP at 6) Based on the server pooling policy of pool "new-name", ASAP at
skipping to change at page 22, line 7 skipping to change at page 24, line 48
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello2" | | +---+ 2. "hello2" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data.send.request("new-name", name-type, "hello2", 6, 0); data.send.request("new-name", name-type, "hello2", 6, 0);
The ASAP layer, in response, looks up the pool "new-name" in its The ASAP endpoint, 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 PU 2) Based on the server pooling policy of "new-name", ASAP at PU
selects the PE (assume EPx is selected again), and sends out selects the PE (assume EPx is selected again), and sends out
"hello2" message (assume the SCTP association is already set "hello2" message (assume the SCTP association is already set
up). up).
4.9 Handle ASAP to ENRP Communication Failures 4.9 PE send failure
Three types of failure may occur when the ASAP layer at an endpoint
tries to communicate with the ENRP server:
A) SCTP send failure
B) T1-ENRPrequest timer expiration
C) Registration failure
Registration failure is discussed in section ?.
4.9.1 SCTP Send Failure
This indicates that the SCTP layer failed to deliver a message sent
to the ENRP server. In other words, the ENRP server is currently
unreachable.
In such a case, the ASAP layer should not re-send the failed
message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section ?.
4.9.2 T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the When the ASAP endpoint in a PE or PU attempts to send a message to a
original request to the ENRP server and re-start the T1-ENRPrequest PE and fails the failed sender will report the event as described
timer. In parallel, a SERVER_HUNT message should be issued per in section 3.5
Section ?.
This should be repeated up to 'max-request-retransmit' times. After Additional primitive are also defined in this section to support
that, an Error.Report notification should be generated to inform the those user applications that do not wish to use ASAP as the actual
ASAP user and the ENRP request message associated with the timer transport.
should be discarded.
4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages 4.9.1 Translation.Request Primitive
At times, an ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages Format: translation.request(Pool-Handle)
(see Section 3.2.7?) from the ENRP server. This message requires
no response and should be silently discarded by the ASAP layer.
4.9.4 Home ENRP Server Hunt If the address type is a Pool handle and a local name
translation cache exists, the ASAP endpoint should look within
its translation cache and return the current known transport
types, ports and addresses to the caller.
At its startup, or when it fails to send to (i.e., timed-out on a If the Pool handle does not exist in the local name cache or no name
service request) with its current home ENRP server, a PE or PU shall cache exists, the ASAP endpoint will send a NAME.RESOLUTION request
initiate the following home ENRP server hunt procedure to find a using the Pool-Handle. Upon completion of the name resolution, the
new home server. ASAP endpoint should populate the local name cache (if a local name
cache is supported) and return the transport types, ports and
addresses to the caller.
The PE or PU shall multicast a SERVER_HUNT message over the ENRP 4.9.2 Transport.Failure Primitive
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 Format: transport.failure(Pool-Handle, Transport-address)
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 If an external user encounters a failure in sending to a PE and is
always reply to the PE with a SERVER_HUNT_RESPONSE message. NOT using ASAP it can use this primitive to report the failure to
the ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home"
ENRP server in response to this primitive. Note ASAP SHOULD NOT send
a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous
request to the translate.request() primitive.
5. Variables, Timers, and Constants 5. Variables, Timers, and Constants
The following is a summary of the variables, timers, and pre-set The following is a summary of the variables, timers, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
5.1 Timers 5.1 Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is the ENRP server (providing application information is
queued). 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 home 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-deregistration- A timer started when sending a deregistration
complete, this timer is begun to restart the registration request to the home ENRP server, normally set to 30 seconds.
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 or 20 seconds less than the Life Timer parameter used
in the registration request (whichever is less).
5.2 Thresholds
Timeout-registration - pre-set threshold; how long an PE
will wait for the REGISTRATION_RESPONSE from its home ENRP server.
Timeout-server-hunt - pre-set threshold; how long a PE will
wait for the REGISTRATION_RESPONSE from its home ENRP server.
num-of-serverhunts - The current count of server hunt messages that T5-Serverhunt - This timer is used nto during the ENRP server hunt
have been transmitted. procedure and is normally set to 120 seconds.
registration-count - The current count of attempted registrations. 5.2 Thresholds and Variables
max-reg-attempt - The maximum number of registration attempts to be max-reg-attempt - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
max-request-retransmit - The maximum number of attempts to be made max-request-retransmit - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
stale.cache.value - A threshold variable that indicates how long
a cache entry is valid for.
6. Security Considerations 6. Security Considerations
Due to varying requirements and multiple use cases of Rserpool, we Due to varying requirements and multiple use cases of Rserpool, we
point out two basic security protocols, IPsec and TLS. We point out two basic security protocols, IPsec and TLS. We
specifically do not discuss whether one security protocol would be specifically do not discuss whether one security protocol would be
preferred over the other. This choice will be made by designers preferred over the other. This choice will be made by designers
and network architects based on system requirements. and network architects based on system requirements.
For networks that demand IPsec security, implementations MUST For networks that demand IPsec security, implementations MUST
support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two
skipping to change at page 24, line 91 skipping to change at page 25, line 154
[SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", [SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP",
draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress.
[SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis, [SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis,
R.R. Stewart, "On the Use of SCTP with IPsec", R.R. Stewart, "On the Use of SCTP with IPsec",
draft-ietf-ipsec-sctp-03.txt, work in progress. draft-ietf-ipsec-sctp-03.txt, work in progress.
[RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
8. Acknowledgements [ENRP-ASAP] - New draft.
17.1 Bibliography
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
8. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, and many The authors wish to thank John Loughney, Lyndon Ong, and many
others for their invaluable comments. others for their invaluable comments.
9. Authors' Addresses 9. Authors' Addresses
Randall R. Stewart Phone: +1-815-477-2127 Randall R. Stewart Tel: +1-815-477-2127
24 Burning Bush Trail. EMail: rrs@cisco.com Cisco Systems, Inc. EMail: rrs@cisco.com
Crystal Lake, IL 60012 8725 West Higgins Road
USA Suite 300
Chicago, Ill 60631
Qiaobing Xie Phone: +1-847-632-3028 Qiaobing Xie Phone: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Maureen Stillman Phone: +1 607 273 0724 62 Maureen Stillman Phone: +1 607 273 0724 62
Nokia EMail: maureen.stillman@nokia.com Nokia EMail: maureen.stillman@nokia.com
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Expires in six months from Mar. 2002
 End of changes. 

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