draft-ietf-rserpool-asap-06.txt   draft-ietf-rserpool-asap-07.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 27, 2003 Q. Xie Expires: November 13, 2003 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
February 26, 2003 May 15, 2003
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-06.txt draft-ietf-rserpool-asap-07.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. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2003. This Internet-Draft will expire on November 13, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Name Resolution Protocol (ENRP) [6] provides a high Endpoint Name Resolution Protocol (ENRP) [6] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
skipping to change at page 3, line 30 skipping to change at page 3, line 30
2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11
2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11
2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 13 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 13
2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13
2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 14 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 14
2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14
2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14
2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 15 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 15
2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15
2.2.15 Data Channel Contact message . . . . . . . . . . . . . . . 15 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 19 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 20 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 21 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 21 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 23 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 23 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 23
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 24 3.9 Business Card handling procedures . . . . . . . . . . . . 23
3.10 Data Channel Contact Message . . . . . . . . . . . . . . . 24 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 24
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 25 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 24
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 24
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 25
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 25
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 25
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 26
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 27 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 27
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 28 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 28
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 29 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 29
4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 30 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 29
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 30 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 31
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 31
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 32
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 33 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 33
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 34 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 33
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 34
4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 35 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 34
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 35 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 35
5. Variables, Timers, and Thresholds . . . . . . . . . . . . 36 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 35
5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . 37 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38 Normative References . . . . . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . 39 Informational References (non-normative) . . . . . . . . . 39
Informational References (non-normative) . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . 41
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a name-based addressing model which isolates a networks. ASAP uses a name-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. single point of failure.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
abstraction of the underlying transport technologies, load abstraction of the underlying transport technologies, load
distribution management, fault management, as well as the distribution management, fault management, as well as the
presentation to the upper layer (i.e., the ASAP user) a unified presentation to the upper layer (i.e., the ASAP user) a unified
primitive interface. primitive interface.
When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by the can seamlessly incorporate the link-layer redundancy provided by the
SCTP. SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high availability
server pool. ASAP depends on the services of a high availability server pool. ASAP depends on the services of a high availability name
name space a.k.a. ENRP [6]. space a.k.a. ENRP [6].
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ASAP User: Either a PE or PU that uses ASAP. ASAP User: Either a PE or PU that uses ASAP.
Operation scope: The part of the network visible to Pool Users by a Operation scope: The part of the network visible to Pool Users by a
specific instance of the reliable server pooling protocols. specific instance of the reliable server pooling protocols.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
Home ENRP server: The ENRP server to which a Pool Element currently Home ENRP server: The ENRP server to which a Pool Element currently
uses. A PU or PE normally chooses the ENRP server on their local uses. A PU or PE normally chooses the ENRP server on their local
host as the home ENRP server (if one exists). A PU or PE should host as the home ENRP server (if one exists). A PU or PE should
only have one home ENRP server at any given time. Having a "home" only have one home ENRP server at any given time. Having a "home"
ENRP server helps provide a mechanism to minimize the number of ENRP server helps provide a mechanism to minimize the number of
associations a given PE will have. associations a given PE will have.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP namespace service. The User (either a PE or PU) requests ENRP namespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well known port number. The channel MAY make home server and a well known port number. The channel MAY make use
use of multi-cast or a named list of ENRP servers. of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address and ENRP server channel: Defined by a well known multicast IP address and
a well known port number, OR a well known list of transport a well known port number, OR a well known list of transport
addresses for a group of ENRP servers spanning an operational addresses for a group of ENRP servers spanning an operational
scope. All ENRP servers in an operation scope can communicate scope. All ENRP servers in an operation scope can communicate with
with one another through this channel via either multicast OR one another through this channel via either multicast OR direct
direct point to point SCTP associations. point to point SCTP associations.
ENRP name domain: Defined by the combination of the ENRP client ENRP name domain: Defined by the combination of the ENRP client
channel and the ENRP server channel in the operation scope. channel and the ENRP server channel in the operation scope.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Transport address: A Transport Address is traditionally defined by Transport address: A Transport Address is traditionally defined by
Network Layer address, Transport Layer protocol and Transport Network Layer address, Transport Layer protocol and Transport
Layer port number. In the case of SCTP running over IP, a Layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the Transport protocol). and an SCTP port number (where SCTP is the Transport protocol).
1.2 Organization of this document 1.2 Organization of this document
Section 2 details ASAP message formats. In Section 3 we give the Section 2 details ASAP message formats. In Section 3 we give the
detailed ASAP procedures for the ASAP implementer. And in Section 4 detailed ASAP procedures for the ASAP implementer. And in Section 4
we give the details of the ASAP interface, focusing on the we give the details of the ASAP interface, focusing on the
communication primitives between the applications above ASAP and ASAP communication primitives between the applications above ASAP and ASAP
itself, and the communications primitives between ASAP and SCTP (or itself, and the communications primitives between ASAP and SCTP (or
other transport layer). Also included in this discussion is relevant other transport layer). Also included in this discussion is relevant
timers and configurable parameters as appropriate. Section 5 timers and configurable parameters as appropriate. Section 5 provides
provides threshold and protocol variables. threshold and protocol variables.
1.3 Scope of ASAP 1.3 Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during transaction failover. If a host or application fails during
processing of a transaction this transaction may be lost. Some processing of a transaction this transaction may be lost. Some
services may provide a way to handle the failure, but this is not services may provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself will NOT share building a mechanism to share state but ASAP in itself will NOT share
any state. any state.
1.3.1 Extent of the 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 ASAP/ administrative domains. For example, suppose we want to use ASAP/
ENRP. First, the PU may use DNS to contact an ENRP server. Suppose ENRP. First, the PU may use DNS to contact an ENRP server. Suppose a
a PU in North America wishes to contact the server pool in Japan PU in North America wishes to contact the server pool in Japan
instead of North America. The PU would use DNS to get the list of IP instead of North America. The PU would use DNS to get the list of IP
addresses of the Japanese server pool domain, that is, the ENRP addresses of the Japanese server pool domain, that is, the ENRP
client channel in Japan. From there the PU would query the ENRP client channel in Japan. From there the PU would query the ENRP
server and then directly contact the PE(s) of interest. server and then directly contact the PE(s) of interest.
1.4 Conventions 1.4 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
skipping to change at page 8, line 16 skipping to change at page 8, line 16
All messages as well as their fields described below shall be in All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length Network Byte Order during transmission. For fields with a length
bigger than 4 octets, a number in a pair of parentheses may follow bigger than 4 octets, a number in a pair of parentheses may follow
the field name to indicate the length of the field in number of the field name to indicate the length of the field in number of
octets. octets.
2.1 ASAP Parameter Formats 2.1 ASAP Parameter Formats
The basic message format and all parameter formats can be found in The basic message format and all parameter formats can be found in
ENRP-ASAP [5]. Note also that ALL ASAP message exchanged between the ENRP-ASAP [5]. Note also that ALL ASAP messages exchanged between an
ENRP server and either a PE or PU MUST user SCTP. PE to PU data ENRP server and a PE MUST use SCTP as transport, while ASAP messages
traffic MAY use any transport protocol specified by the PE during exchanged between an ENRP server and a PU MUST use either SCTP or TCP
registration. as transport. PE to PU data traffic MAY use any transport protocol
specified by the PE during registration.
2.2 ASAP Messages 2.2 ASAP Messages
This section details the individual messages used by ASAP. These This section details the individual messages used by ASAP. These
messages are composed of a standard message format found in Section 4 messages are composed of a standard message format found in Section 4
or ENRP-ASAP [5]. The parameter descriptions may also be found in of ENRP-ASAP [5]. The parameter descriptions may also be found in
Section 3 of ENRP-ASAP [5]. Section 3 of ENRP-ASAP [5].
The following ASAP message types are defined in this section: The following ASAP message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - Registration 0x01 - Registration
0x02 - Deregistration 0x02 - Deregistration
0x03 - Registration Response 0x03 - Registration Response
skipping to change at page 8, line 47 skipping to change at page 9, line 4
0x05 - Name Resolution 0x05 - Name Resolution
0x06 - Name Resolution Response 0x06 - Name Resolution Response
0x07 - Endpoint Keep Alive 0x07 - Endpoint Keep Alive
0x08 - Endpoint Keep Alive Acknowledgement 0x08 - Endpoint Keep Alive Acknowledgement
0x09 - Endpoint Unreachable 0x09 - Endpoint Unreachable
0x0a - Server Announce 0x0a - Server Announce
0x0b - Cookie 0x0b - Cookie
0x0c - Cookie-Echo 0x0c - Cookie-Echo
0x0d - Business Card 0x0d - Business Card
0x0e - Peer Error 0x0e - Peer Error
0x0f - Data Channel Contact
2.2.1 REGISTRATION message 2.2.1 REGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the name to be registered. The pool handle parameter field specifies the name to be registered.
The PE Parameter field MUST be filled in by the registrant endpoint The PE Parameter field MUST be filled in by the registrant endpoint
to declare its transports and addresses, server pooling policy and to declare its transport address, server pooling policy and value,
value, and other operation preferences. Note that the registration and other operation preferences. Note that the registration message
message MUST use SCTP and the IP addresses of the PE registered MUST use SCTP and the IP address(es) of the PE registered within the
within the Pool Element Parameter MUST be a subset of the addresses Pool Element Parameter MUST be a subset of the addresses of the SCTP
of the SCTP association irrespective of the transport protocol association in respective of the transport protocol registered by the
regestered by the PE. PE.
2.2.2 DEREGISTRATION message 2.2.2 DEREGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 10 skipping to change at page 10, line 10
The PE sending the DEREGISTRATION shall fill in the pool handle and The PE sending the DEREGISTRATION shall fill in the pool handle and
the PE identifier parameter in order to allow the ENRP server to the PE identifier parameter in order to allow the ENRP server to
verify the identity of the endpoint. Note that deregistration is NOT verify the identity of the endpoint. Note that deregistration is NOT
allowed by proxy, in other words a PE may only deregister itself. allowed by proxy, in other words a PE may only deregister itself.
2.2.3 REGISTRATION_RESPONSE message 2.2.3 REGISTRATION_RESPONSE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x3 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Member Selection Policy Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error R (Reject) flag
This optional TLV parameter is included if an error or a selection When set to '1', indicate that the ENRP server that sent this message
policy override occured during the registration process. The cause has rejected the registration. Otherwise, the registration is
code carried in this TLV will indicate to the registering PE whether granted.
the registration is rejected or accepted with a warning (e.g., policy
overruled). If the registration was sucessful and there is no
warning this parameter is not included.
Member Selection Policy Operational Error
This optional TLV parameter is included if the ENRP has overridden This optional TLV parameter is included if an error or some atypical
the member selection policy of the registering PE. The new policy is events occurred during the registration process. When the 'R' flag is
indicated in this parameter. See Section 4.3? of [6] for more set to '1', this TLV, if present, indicates the cause of the
details on policy override during registration. rejection. When the 'R' flag is set to '0', this TLV, if present,
serves as a warning to the registering PE, informing it that some of
its registration values may have been modified or overruled by the
ENRP server (e.g., the selection policy type overruled). If the
registration was successful and there is no warning this parameter is
not included.
2.2.4 DEREGISTRATION_RESPONSE message 2.2.4 DEREGISTRATION_RESPONSE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Operational Error
This optional TLV parameter is included if an error occured during This optional TLV parameter is included if an error occurred during
the deregistration process. If the deregistration was sucessful this the deregistration process. If the deregistration was successful this
parameter is not included. parameter is not included.
2.2.5 NAME_RESOLUTION message 2.2.5 NAME_RESOLUTION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Communication Restrictions Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server to request translation of the This message is sent to a ENRP server to request translation of the
Pool Handle to a list of Pool Elements. If sent from a PE the SCTP Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used. association used for registration SHOULD be used.
The Communication Restrictons Parameter is an optional parameter that
MAY be included. Note that if a Communication Restrictions Parameter
is NOT present the ENRP server will treat the request the same as if
the requestor had specified any transport for both Control and Data.
2.2.6 NAME_RESOLUTION_RESPONSE message 2.2.6 NAME_RESOLUTION_RESPONSE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) : : Overall PE Selection Policy (optional) :
skipping to change at page 12, line 7 skipping to change at page 11, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N (optional) : : Pool Element Parameter N (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Overall PE Selection Policy: Overall PE Selection Policy:
This TLV is a PE selection policy parameter and can be present when This TLV is a PE selection policy parameter and can be present when
the response is positive. It indicates the overall selection policy the response is positive. It indicates the overall selection policy
of the pool. If not present, round-robin is assumed. This TLV is of the pool. If not present, round-robin is assumed. This TLV is not
not present when the response is negative (i.e., a rejection). present when the response is negative (i.e., a rejection).
Note, any load policy parameter inside the Pool Element Parameter (if Note, any load policy parameter inside the Pool Element Parameter (if
present) MUST be ignored, and MUST NOT be used to determine the present) MUST be ignored, and MUST NOT be used to determine the
overall pool policy. overall pool policy.
Pool Element Parameters Pool Element Parameters
When the response is positive, an array of PE TLVs are included, When the response is positive, an array of PE TLVs are included,
indicating the current PEs and their information in the named pool. indicating the current PEs and their information in the named pool.
In a positive response, at least one PE TLV MUST be present. When In a positive response, at least one PE TLV MUST be present. When the
the response is negative, no PE TLVs are included. response is negative, no PE TLVs are included.
Operational Error Operational Error
The presence of this TLV indicates that the response is negative The presence of this TLV indicates that the response is negative
(i.e., the name resolution request was rejected by the ENRP server). (i.e., the name resolution request was rejected by the ENRP server).
The cause code in this TLV (if present) will indicate the reason the The cause code in this TLV (if present) will indicate the reason the
name resolution request was rejected (e.g., the requested pool handle name resolution request was rejected (e.g., the requested pool handle
was not found). was not found).
2.2.7 ENDPOINT_KEEP_ALIVE message 2.2.7 ENDPOINT_KEEP_ALIVE message
skipping to change at page 13, line 5 skipping to change at page 12, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a PE by the ENRP server has a "health" check. 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 If the transport level Heart Beat mechanism is insufficient (usually
this means that time outs are set for too long or heartbeats are not this means that time outs are set for too long or heartbeats are not
frequent enough), this adds heartbeat messages with the goal of frequent enough), this adds heartbeat messages with the goal of
determining health status in a more timely fashion. determining health status in a more timely fashion.
Using ASAP keepalive also has additional value to the reliability of
fault detection when SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, ASAP keepalive monitors the end-to-end
liveliness of the ASAP layer above it.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 |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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
skipping to change at page 15, line 26 skipping to change at page 15, line 26
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 : : Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. : : .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N : : Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender of this message lists both the Pool that the sender The sender of this message lists both the Pool that the sender
belongs to and a prefered list of failover candidates. belongs to and a preferred list of failover candidates.
2.2.14 PEER_ERROR message 2.2.14 PEER_ERROR message
This message is used to report an operation error. This message is used to report an operation error.
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 = 0xe |0|0|0|0|0|0|0|0| Message Length | | Type = 0xe |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter : : Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.15 Data Channel Contact message
This message is used in communication between a PE and PU. When the
PE wishes the PU to transfer data on a different transport address
this message is sent to the PU by the PE to inform the PU where data
messages should be sent.
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 = 0xf |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: User Transport Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A single User Transport Parameter is included with this message. The
parameter identifies a transport address (UDP, TCP or SCTP) to send
Data to.
3. Procedures 3. Procedures
This section will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. failure detection and management are also discussed.
3.1 Registration 3.1 Registration
When a PE wishes to join its server pool it MUST use the procedures When a PE wishes to join its server pool it MUST use the procedures
outlined in this section to register. Often the registration will be outlined in this section to register. Often the registration will be
triggered by a user request primitive (discussed in Section 4.1). triggered by a user request primitive (discussed in Section 4.1). The
The ASAP endpoint MUST register using an SCTP association between the ASAP endpoint MUST register using an SCTP association between the
ASAP endpoint and the ENRP server. If the ASAP endpoint has not ASAP endpoint and the ENRP server. If the ASAP endpoint has not
established its Home ENRP server it MUST follow the procedures established its Home ENRP server it MUST follow the procedures
specified in Section 3.6 to establish its Home ENRP server. specified in Section 3.6 to establish its Home ENRP server.
Once the ASAP endpoint has established its Home ENRP server the Once the ASAP endpoint has established its Home ENRP server the
following procedures MUST be followed to register: following procedures MUST be followed to register:
R1) The SCTP endpoint used to communicate with the ENRP server MUST R1) The SCTP endpoint used to communicate with the ENRP server MUST
be bound to all IP addresses that will be used by the PE be bound to all IP addresses that will be used by the PE
(irregardless of what protocol will be used to service user (irregardless of what protocol will be used to service user
requests to the PE). requests to the PE).
R2) The ASAP endpoint MUST formulate a Registration message as R2) The ASAP endpoint MUST formulate a Registration message as
defined in Section 2.2.1 In formulating the message the ASAP defined in Section 2.2.1 In formulating the message the ASAP
endpoint MUST: endpoint MUST:
R2.1) Fill in the the Pool Handle to specify which server pool the R2.1) Fill in the Pool Handle to specify which server pool the
ASAP endpoint wishes to join. ASAP endpoint wishes to join.
R2.2) Fill in a PE identifier using a good quality randomly R2.2) Fill in a PE identifier using a good quality randomly
generated number (RFC1750 [9] provides some information on generated number (RFC1750 [9] provides some information on
randomness guidelines). randomness guidelines).
R2.3) Fill in the registration life time parameter with the number R2.3) Fill in the registration life time parameter with the number
of seconds that this registration is good for. Note a PE that of seconds that this registration is good for. Note a PE that
wishes to continue service MUST re-register after the wishes to continue service MUST re-register after the
registration expires. registration expires.
R2.4) Fill in a User Transport Parameter for EACH type of R2.4) Fill in a User Transport Parameter for the type of transport
transport the PE is willing to support. and the data/control channel usage the PE is willing to
support. Note, to join an existing server pool, the PE MUST
follow the overall transport type and overall data/control
channel usage of the pool. Otherwise, the registration may be
rejected by the ENRP server.
R2.5) Fill in the preferred Member selection policy. R2.5) Fill in the preferred Member selection policy.
R3) Send the Registration request to the Home ENRP server using SCTP. R3) Send the Registration request to the Home ENRP server using SCTP.
R4) Start a T2-registration timer. R4) Start a T2-registration timer.
If the T2-registration timer expires before receiving a If the T2-registration timer expires before receiving a
REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
received from the SCTP layer, the ASAP endpoint shall start the received from the SCTP layer, the ASAP endpoint shall start the
skipping to change at page 18, line 25 skipping to change at page 17, line 27
At the reception of the registration response, the ASAP endpoint MUST At the reception of the registration response, the ASAP endpoint MUST
stop the T2-Registration timer. If the response indicated success, stop the T2-Registration timer. If the response indicated success,
then the PE is now registered and will be considered an available then the PE is now registered and will be considered an available
member of the server pool. If the registration response indicates a member of the server pool. If the registration response indicates a
failure, the ASAP endpoint must either re-attempt registration after failure, the ASAP endpoint must either re-attempt registration after
correcting the error or return a failure indication to the ASAP correcting the error or return a failure indication to the ASAP
endpoints upper layer. The ASAP endpoint MUST NOT re-attempt endpoints upper layer. The ASAP endpoint MUST NOT re-attempt
registration without correcting the error condition. registration without correcting the error condition.
The registration response may also indicate that the registration is
accepted with a warning, often indicating that the ENRP server might
have made modifications to the value of some registration attribute
or attributes (such as policy type, transport usage, etc.). When this
happens, the PE SHOULD immediately notify its upper layer about the
registration modifications. This gives the upper layer a chance, for
example, to withdraw itself from the pool if such modifications are
unacceptable for its operation.
At any time a registered PE MAY wish to re-register to either update At any time a registered PE MAY wish to re-register to either update
its member selection policy value or registration expiration time. its member selection policy value or registration expiration time.
When re-registering the PE MUST use the same PE identifier. When re-registering the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration After successful registration the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting timer. At its expiration a re-registration SHOULD be made starting at
at step R1 including (at completion) restarting the T4-reregistration step R1 including (at completion) restarting the T4-reregistration
timer. timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
registration attempts it makes in a local variable. If repeated registration attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count exceeds registration time-outs or failures occurs and the local count exceeds
the Threshold 'max-reg-attempt' the implementation SHOULD report the the Threshold 'max-reg-attempt' the implementation SHOULD report the
error to its upper layer and stop attempting registration. error to its upper layer and stop attempting registration.
3.2 Deregistration 3.2 Deregistration
In the event the PE wishes to deregister from its server pool In the event the PE wishes to deregister from its server pool
(normally via an upper layer requests see Section 4.2) it SHOULD use (normally via an upper layer requests see Section 4.2) it SHOULD use
the following procedures. Note that an alternate method of the following procedures. Note that an alternate method of
deregistration is to NOT re-register and to allow the registration deregistration is to NOT re-register and to allow the registration
lift time to expire. lift time to expire.
When deregistering the PE SHOULD use the same SCTP association with When deregistering the PE SHOULD use the same SCTP association with
its Home ENRP server that was used for registration. To deregister its Home ENRP server that was used for registration. To deregister
the ASAP endpoint MUST take the following actions: the ASAP endpoint MUST take the following actions:
skipping to change at page 19, line 38 skipping to change at page 18, line 47
requests for some period of time. The PE MAY wish to still remain requests for some period of time. The PE MAY wish to still remain
active and service these requests or may wish to ignore these active and service these requests or may wish to ignore these
requests and exit. requests and exit.
3.3 Name resolution 3.3 Name resolution
At any time a PE or PU may wish to resolve a name. This usually will 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.1) or occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or
requests a cache population (Section 4.3) but may occur for other requests a cache population (Section 4.3) but may occur for other
reasons (e.g. the internal ASAP PE wishes to know its peers for reasons (e.g. the internal ASAP PE wishes to know its peers for
sending a message to all of them). When an Endpoint (PE or PU) sending a message to all of them). When an Endpoint (PE or PU) wishes
wishes to resolve a name it MUST take the following actions: to resolve a name it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool
Handle to be resolved. Handle to be resolved.
NR2) If the endpoint does not have a Home ENRP server start the ENRP NR2) If the endpoint does not have a Home ENRP server start the ENRP
Server Hunt procedures specified in Section 3.6 to obtain one. Server Hunt procedures specified in Section 3.6 to obtain one.
Otherwise proceed to step NR3. Otherwise proceed to step NR3.
NR3) Send the NAME_RESOLUTION message to the Home ENRP server using NR3) Send the NAME_RESOLUTION message to the Home ENRP server using
SCTP. SCTP.
skipping to change at page 21, line 23 skipping to change at page 20, line 31
KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the
new home ENRP server. new home ENRP server.
3.5 Reporting unreachable endpoints 3.5 Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable. Occasionally an ASAP endpoint may realize that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP endpoint This may occur by a specific SCTP error realized by the ASAP endpoint
or via a ASAP user report via the Transport.Failure Primitive or via a ASAP user report via the Transport.Failure Primitive
(Section 4.9.2). In either case the ASAP endpoint SHOULD report the (Section 4.9.2). In either case the ASAP endpoint SHOULD report the
unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to unavailability of the PE by sending a ENDPOINT_UNREACHABLE message to
its home ENRP server. The Endpoint should fill in the Pool Handle its home ENRP server. The Endpoint should fill in the Pool Handle and
and PE identifier of the unreachable endpoint. If the sender is a PE PE identifier of the unreachable endpoint. If the sender is a PE the
the message MUST be sent via SCTP to the Endpoints Home ENRP server. message MUST be sent via SCTP to the Endpoints Home ENRP server.
Note: when processing a Transport.Failure Primitive (Section 4.9.2) Note: when processing a Transport.Failure Primitive (Section 4.9.2)
the ASAP endpoint MUST NOT send a unreachable report unless the ASAP the ASAP endpoint MUST NOT send a unreachable report unless the ASAP
endpoint as sent at least one message to the PE specified by the endpoint as sent at least one message to the PE specified by the
primitive. primitive.
3.6 ENRP server hunt procedures 3.6 ENRP server hunt procedures
Each PU and PE manages a list of transport addresses of ENRP servers. Each PU and PE manages a list of transport addresses of ENRP servers.
skipping to change at page 24, line 17 skipping to change at page 23, line 29
this should be verified by the receiving PE. The details of this are this should be verified by the receiving PE. The details of this are
out of scope of this document. It is only important that the PU out of scope of this document. It is only important that the PU
stores always the last received Cookie Parameter and sends that back stores always the last received Cookie Parameter and sends that back
unmodified in case of a PE failure. unmodified in case of a PE failure.
3.9 Business Card handling procedures 3.9 Business Card handling procedures
When communication begins between a PU and a PE (i.e. the first When communication begins between a PU and a PE (i.e. the first
message is sent from the PU to the PE) the ASAP layer in the PU message is sent from the PU to the PE) the ASAP layer in the PU
SHOULD send a Business card IF the sender is also registered as a PE. SHOULD send a Business card IF the sender is also registered as a PE.
A PE may also send back to a PU a business card as well. A Bussiness A PE may also send back to a PU a business card as well. A Business
card MUST NOT be sent if a control channel does NOT exist between the card MUST NOT be sent if a control channel does NOT exist between the
PU and PE. After communication as been established between a PE and PU and PE. After communication as been established between a PE and
PU at any time either entity may update its failover distribution by PU at any time either entity may update its failover distribution by
sending a new Business Card. sending a new Business Card.
The business card serves two purposes (for both endpoints PU and PE). The business card serves two purposes (for both endpoints PU and PE).
First it lists the endpoints pool handle. For a PU contacting a PE First it lists the endpoints pool handle. For a PU contacting a PE
this is essential so that the PE may also gain the full benefits of this is essential so that the PE may also gain the full benefits of
ASAP if the PU is also a PE. Secondly the business card tells the ASAP if the PU is also a PE. Secondly the business card tells the
receiver a failover order that is recommended to follow. This may receiver a failover order that is recommended to follow. This may
facilitate rendouvous between PE's as well as some control of load facilitate rendezvous between PE's as well as some control of load
redistribution upon the failure of any given PE. redistribution upon the failure of any given PE.
Upon receipt of a Business Card Message (see Section 2.2.13) the Upon receipt of a Business Card Message (see Section 2.2.13) the
receiver SHOULD: receiver SHOULD:
BC1) Unpack the business card, and if no entry exists in the BC1) Unpack the business card, and if no entry exists in the
translation cache and one exists, populate the new Pool Handle translation cache and one exists, populate the new Pool Handle
into the cache and request a NAME.RESOLUTION of the pool handle. into the cache and request a NAME.RESOLUTION of the pool handle.
BC2) Create a list for this PE of prefered failover order so that in BC2) Create a list for this PE of preferred failover order so that in
the event of a failure the prefered list will be used to guide the the event of a failure the preferred list will be used to guide
ASAP endpoint in the selection of an alternate PE. the ASAP endpoint in the selection of an alternate PE.
3.10 Data Channel Contact Message
At the beginning of communication between a PE and a PU, a PE may
send this message to info the PU what transport is to be used for
Data. This message SHOULD only be sent at initial contact between a
PE and a PU.
4. The ASAP Interfaces 4. The ASAP Interfaces
This chapter will focus primarily on the primitives and notifications This chapter will focus primarily on the primitives and notifications
that form the interface between the ASAP-user and ASAP and that that form the interface between the ASAP-user and ASAP and that
between ASAP and its lower layer transport protocol (e.g., SCTP). between ASAP and its lower layer transport protocol (e.g., SCTP).
Note, the following primitive and notification descriptions are shown
for illustrative purposes. We believe that including these
descriptions in this document is important to the understanding of
the operation of many aspects of ASAP. But an ASAP implementation is
not required to use the exact syntax described in this section.
An ASAP User passes primitives to the ASAP sub-layer to request An ASAP User passes primitives to the ASAP sub-layer to request
certain actions. Upon the completion of those actions or upon the certain actions. Upon the completion of those actions or upon the
detection of certain events, the ASAP will notify the ASAP user. detection of certain events, the ASAP will notify the ASAP user.
4.1 Registration.Request Primitive 4.1 Registration.Request Primitive
Format: registration.request(poolHandle, Format: registration.request(poolHandle,
User Transport parameter(s)) User Transport parameter(s))
The poolHandle parameter contains a NULL terminated ASCII string of The poolHandle parameter contains a NULL terminated ASCII string of
fixed length. The optional User Transport parameter(s) indicate fixed length. The optional User Transport parameter(s) indicate
specific transport parameters and types to register with. If this specific transport parameters and types to register with. If this
optional parameter is left off, then the SCTP endpoint used to optional parameter is left off, then the SCTP endpoint used to
communicate with the ENRP server is used as the default User communicate with the ENRP server is used as the default User
Transport parameter. Note that any IP address contained within a Transport parameter. Note that any IP address contained within a User
User Transport parameter MUST be a bound IP address in the SCTP Transport parameter MUST be a bound IP address in the SCTP endpoint
endpoint used to communicate with the ENRP server. used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the namespace, The ASAP user invokes this primitive to add itself to the namespace,
thus becoming a Pool Element of a pool. The ASAP user must register thus becoming a Pool Element of a pool. The ASAP user must register
itself with the ENRP server by using this primitive before other ASAP itself with the ENRP server by using this primitive before other ASAP
users using the namespace can send message(s) to this ASAP user by users using the namespace can send message(s) to this ASAP user by
Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3). Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3).
In response to the registration primitive, the ASAP endpoint will In response to the registration primitive, the ASAP endpoint will
send a REGISTRATION message to the home ENRP server (See Section send a REGISTRATION message to the home ENRP server (See Section
2.2.1 and Section 3.1), and start a T2-registration timer. 2.2.1 and Section 3.1), and start a T2-registration timer.
skipping to change at page 27, line 10 skipping to change at page 26, line 13
transport type. transport type.
The data.send.request primitive can take different forms of address The data.send.request primitive can take different forms of address
types as described in the following sections. types as described in the following sections.
4.5.1 Sending to a Pool Handle 4.5.1 Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a pool handle. indicates a pool handle.
This is the simplest form of send.data.request primitive. By This is the simplest form of send.data.request primitive. By default,
default, this directs ASAP to send the message to one of the Pool this directs ASAP to send the message to one of the Pool Elements in
Elements in the specified pool. the specified pool.
Before sending the message out to the pool, the senders ASAP endpoint Before sending the message out to the pool, the senders ASAP endpoint
MUST first perform a pool handle to address translation. It may also MUST first perform a pool handle to address translation. It may also
need to perform Pool Element selection if multiple Pool Elements need to perform Pool Element selection if multiple Pool Elements
exist in the pool. exist in the pool.
If the senders ASAP implementation does not support a local cache of If the senders ASAP implementation does not support a local cache of
the mapping information or if it does not have the mapping the mapping information or if it does not have the mapping
information on the pool in its local cache, it will transmit a information on the pool in its local cache, it will transmit a
NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the NAME.RESOLUTION message (see Section 2.2.5 and Section 3.3) to the
skipping to change at page 27, line 35 skipping to change at page 26, line 38
request to this pool before the ENRP server responds SHOULD also be request to this pool before the ENRP server responds SHOULD also be
queued). queued).
Once the necessary mapping information arrives from the ENRP server, Once the necessary mapping information arrives from the ENRP server,
the senders ASAP will: the senders ASAP will:
A) map the pool handle into a list of transport addresses of the A) map the pool handle into a list of transport addresses of the
destination PE(s), destination PE(s),
B) if multiple PEs exist in the pool, ASAP will choose one of them B) if multiple PEs exist in the pool, ASAP will choose one of them
and transmit the message to it. In that case, the choice of the and transmit the message to it. In that case, the choice of the PE
PE is made by ASAP endpoint of the sender based on the server is made by ASAP endpoint of the sender based on the server pooling
pooling policy as discussed in Section 4.5.2 policy as discussed in Section 4.5.2
C) Optionally create any transport endpoint that may be needed to C) Optionally create any transport endpoint that may be needed to
communicate with the PE selected. communicate with the PE selected.
D) if no transport association or connection exists towards the D) if no transport association or connection exists towards the
destination PE, ASAP will establish any needed transport state, destination PE, ASAP will establish any needed transport state,
E) send out the queued message(s) to the appropriate transport E) send out the queued message(s) to the appropriate transport
connection using the appropriate send mechanism (e.g. for SCTP connection using the appropriate send mechanism (e.g. for SCTP the
the SEND primitive in RFC2960 [4] would be used), and, SEND primitive in RFC2960 [4] would be used), and,
F) if the local cache is implemented, append/update the local cache F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g. the response. Also, record the local transport information (e.g. the
SCTP association id) if any new transport state was created. SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures see ENRP [6]. For more on the ENRP server request procedures see ENRP [6].
Optionally, the ASAP endpoint of the sender may return a Pool Element Optionally, the ASAP endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
skipping to change at page 29, line 23 skipping to change at page 28, line 28
4.5.2.3 Least Used with Degradation Policy 4.5.2.3 Least Used with Degradation Policy
This policy is the same as the Least Used policy with the exception This policy is the same as the Least Used policy with the exception
that, each time the PE with the lowest policy value is selected from that, each time the PE with the lowest policy value is selected from
the Pool as the receiver of the current message, its policy value is the Pool as the receiver of the current message, its policy value is
incremented, and thus it may no longer be the lowest value in the incremented, and thus it may no longer be the lowest value in the
Pool. Pool.
This provides a degradation of the policy towards round Robin policy This provides a degradation of the policy towards round Robin policy
over time. As with the Least Used policy, every local cache update over time. As with the Least Used policy, every local cache update at
at the sender will bring the policy back to Least Used with the sender will bring the policy back to Least Used with Degradation.
Degradation.
4.5.2.4 Weighted Round Robin Policy 4.5.2.4 Weighted Round Robin Policy
[TBD] [TBD]
4.5.3 Sending to a Pool Element Handle 4.5.3 Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate an ASAP Pool Element handle. indicate an ASAP Pool Element handle.
skipping to change at page 31, line 19 skipping to change at page 30, line 21
ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In
case where the first selected PE or the PE pointed to by the PE case where the first selected PE or the PE pointed to by the PE
handle is found unreachable, the sender's ASAP endpoint SHOULD handle is found unreachable, the sender's ASAP endpoint SHOULD
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.
Note that this is a best-effort service. Applications should be Note that this is a best-effort service. Applications should be
aware that messages can be lost during the failover process, even aware that messages can be lost during the failover process, even
if the underlying transport supports retrieval of unacknowledged if the underlying transport supports retrieval of unacknowledged
data (e.g. SCTP) (Example: messages acknowledged by the SCTP data (e.g. SCTP) (Example: messages acknowledged by the SCTP layer
layer at a PE, but not yet read by the PE when a PE failure at a PE, but not yet read by the PE when a PE failure occurs.) In
occurs.) In the case where the underlying transport does not the case where the underlying transport does not support such
support such retrieval (e.g. TCP), any data already submitted by retrieval (e.g. TCP), any data already submitted by ASAP to the
ASAP to the transport layer MAY be lost upon failover. transport layer MAY be lost upon failover.
ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP
endpoint from re-sending the message to any alternate PE in case endpoint from re-sending the message to any alternate PE in case
that the first selected PE or the PE pointed to by the PE handle that the first selected PE or the PE pointed to by the PE handle
is found unreachable. Instead, the senders ASAP endpoint shall is found unreachable. Instead, the senders ASAP endpoint shall
notify its upper layer about the unreachability with an notify its upper layer about the unreachability with an
Error.Report and return any unsent data. Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP
endpoint to send the message to the same PE in the pool that the endpoint to send the message to the same PE in the pool that the
previous message destined to this pool was sent to. previous message destined to this pool was sent to.
ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option
directs the senders ASAP endpoint to send a copy of the message to directs the senders ASAP endpoint to send a copy of the message to
all the PEs, except for the sender itself if the sender is a PE, all the PEs, except for the sender itself if the sender is a PE,
in that pool. in that pool.
ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination ASAP_SEND_TO_SELF: 0x0010 This option only applies in combination
with ASAP_SEND_TO_ALL option. It permits the senders ASAP with ASAP_SEND_TO_ALL option. It permits the senders ASAP endpoint
endpoint also deliver a copy of the message to itself if the also deliver a copy of the message to itself if the sender is a PE
sender is a PE of the pool (i.e., loop-back). of the pool (i.e., loop-back).
ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to
send the current message using un-ordered delivery (note the send the current message using un-ordered delivery (note the
underlying transport must support un-ordered delivery for this underlying transport must support un-ordered delivery for this
option to be effective). option to be effective).
4.6 Data.Received Notification 4.6 Data.Received Notification
Format: data.received(messageReceived, sizeOfMessage, senderAddress, Format: data.received(messageReceived, sizeOfMessage, senderAddress,
typeOfAddress) typeOfAddress)
skipping to change at page 35, line 27 skipping to change at page 34, line 27
ASAP endpoint should populate the local name cache (if a local name ASAP endpoint should populate the local name cache (if a local name
cache is supported) and return the transport types, ports and cache is supported) and return the transport types, ports and
addresses to the caller. addresses to the caller.
4.9.2 Transport.Failure Primitive 4.9.2 Transport.Failure Primitive
Format: transport.failure(Pool-Handle, Transport-address) Format: transport.failure(Pool-Handle, Transport-address)
If an external user encounters a failure in sending to a PE and is If an external user encounters a failure in sending to a PE and is
NOT using ASAP it can use this primitive to report the failure to the NOT using ASAP it can use this primitive to report the failure to the
ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ENRP
ENRP server in response to this primitive. Note ASAP SHOULD NOT send server in response to this primitive. Note ASAP SHOULD NOT send a
a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous
request to send data to the PE. request to send data to the PE.
5. Variables, Timers, and Thresholds 5. Variables, Timers, and Thresholds
The following is a summary of the variables, timers, and pre-set The following is a summary of the variables, timers, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
5.1 Timers 5.1 Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
skipping to change at page 36, line 24 skipping to change at page 35, line 24
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending a registration request T2-registration - A timer started when sending a registration request
to the home ENRP server, normally set to 30 seconds. to the home ENRP server, normally set to 30 seconds.
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a deregistration
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T4-reregistration - This timer is started after successful T4-reregistration - This timer is started after successful
registration into the ASAP name space and is used to cause a registration into the ASAP name space and is used to cause a
re-registration at a periodic interval. This timer is normally re-registration at a periodic interval. This timer is normally set
set to 10 minutes or 20 seconds less than the Life Timer parameter to 10 minutes or 20 seconds less than the Life Timer parameter
used in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
T6-Serverannounce - This timer gives the time between the sending of T6-Serverannounce - This timer gives the time between the sending of
consequetive SERVER_ANNOUNCE messages. It is normally set to 1 consecutive SERVER_ANNOUNCE messages. It is normally set to 1
second. second.
T7-ENRPoutdate - This timer gives the time a server announcement is T7-ENRPoutdate - This timer gives the time a server announcement is
valid. It is normally set to 5 seconds. valid. It is normally set to 5 seconds.
5.2 Thresholds and Variables 5.2 Thresholds and Variables
max-reg-attempt - The maximum number of registration attempts to be max-reg-attempt - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
skipping to change at page 39, line 31 skipping to change at page 38, line 31
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol and Endpoint Name Resolution Protocol Server Access Protocol and Endpoint Name Resolution Protocol
Common Parameters", draft-ietf-rserpool-common-param-01 (work in Common Parameters", draft-ietf-rserpool-common-param-01 (work in
progress), June 2002. progress), June 2002.
[6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in
progress), May 2002. progress), May 2002.
[7] Bellovin, S., "On the Use of SCTP with IPsec", [7] Bellovin, S., "On the Use of SCTP with IPsec",
draft-ietf-ipsec-sctp-04 (work in progress), October 2002. draft-ietf-ipsec-sctp-06 (work in progress), April 2003.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
Informational References (non-normative) Informational References (non-normative)
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
 End of changes. 

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