draft-ietf-rserpool-asap-09.txt   draft-ietf-rserpool-asap-10.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: December 8, 2004 Q. Xie Expires: April 14, 2005 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
June 9, 2004 October 14, 2004
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-09.txt draft-ietf-rserpool-asap-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 8, 2004. This Internet-Draft will expire on April 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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) [7] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
name-based addressing model which isolates a logical communication name-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
pool, providing full transparent support for server-pooling and load pool, providing full transparent support for server-pooling and load
sharing. It also allows dynamic system scalability - members of a sharing. It also allows dynamic system scalability - members of a
server pool can be added or removed at any time without interrupting server pool can be added or removed at any time without interrupting
skipping to change at page 3, line 9 skipping to change at page 3, line 9
The high availability server pooling is gained by combining two The high availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for name to address translation, load sharing management, interface for name to address translation, load sharing management,
and fault management while ENRP defines the high availability name and fault management while ENRP defines the high availability name
translation service. translation service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Organization of this document . . . . . . . . . . . . . . 7 1.2 Organization of this document . . . . . . . . . . . . . . 6
1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Extent of the Namespace . . . . . . . . . . . . . . . 7 1.3.1 Extent of the Handlespace . . . . . . . . . . . . . . 7
1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Message Definitions . . . . . . . . . . . . . . . . . . . . 8 2. Message Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8
2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . 9 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . 9
2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . 9 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . 9
2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . 10 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . 10
2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . 10 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 14 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 15
2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . 15 2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22
skipping to change at page 5, line 7 skipping to change at page 5, line 7
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 41 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 41
8.2 Informational References (non-normative) . . . . . . . . . . 41 8.2 Informational References (non-normative) . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 43
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a name-based addressing model which isolates a networks. ASAP uses a 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.
When multiple receiver instances exist under the same name, a.k.a, a When multiple receiver instances exist under the same name, a.k.a, a
server pool, ASAP will select one Pool Element (PE), based on the server pool, ASAP will select one Pool Element (PE), based on the
current load sharing policy indicated by the server pool, and deliver current load sharing policy indicated by the server pool, and deliver
skipping to change at page 5, line 40 skipping to change at page 5, line 40
distribution management, fault management, as well as the distribution management, fault management, as well as the
presentation to the upper layer (i.e., the ASAP user) a unified presentation to the upper layer (i.e., the ASAP user) a unified
primitive interface. primitive interface.
When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by the can seamlessly incorporate the link-layer redundancy provided by the
SCTP. SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high availability
server pool. ASAP depends on the services of a high availability server pool. ASAP depends on the services of a high availability
name space a.k.a. ENRP [6]. name space a.k.a. ENRP [7].
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ASAP User: Either a PE or PU that uses ASAP. ASAP User: Either a PE or PU that uses ASAP.
Operation scope: The part of the network visible to Pool Users by a Operation scope: See [6];
specific instance of the reliable server pooling protocols.
Server pool (or Pool): A collection of servers providing the same Operation scope: See [6];
application functionality. Pool (or server pool): See [6];
Pool handle (or pool name): A logical pointer to a pool. Each server Pool handle: See [6];
pool will be identifiable in the operation scope of the system by
a unique pool handle or "name".
Pool Element (PE): A server entity having registered to a pool. Pool element (PE): See [6];
Pool User (PU): A server Pool User. Pool user (PU): See [6];
Pool Element handle (PE handle): A logical pointer to a particular Pool element handle: See [6];
Pool Element in a pool,
ENRP server: A server program running on a host that manages the name ENRP handlespace (or handlespace): See [6];
space collectively with its peer ENRP servers and replies to the
service requests from any Pool User or Pool Element.
Home ENRP server: The ENRP server to which a Pool Element currently pool registrar: A server program running on a host that manages the
uses. A PU or PE normally chooses the ENRP server on their local name space collectively with its peer ENRP servers and replies to
host as the home ENRP server (if one exists). A PU or PE should the service requests from any Pool User or Pool Element.
only have one home ENRP server at any given time. Having a "home"
ENRP server helps provide a mechanism to minimize the number of Home ENRP server: The ENRP server to which a PE or PU currently
associations a given PE will have. belongs. A PE MUST only have one home ENRP server at any given
time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track
of this relationship.
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 handlespace 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 of multi-cast or a named list of ENRP servers. use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address and
a well known port number, OR a well known list of transport
addresses for a group of ENRP servers spanning an operational
scope. All ENRP servers in an operation scope can communicate
with one another through this channel via either multicast OR
direct point to point SCTP associations.
ENRP name domain: Defined by the combination of the ENRP client
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
skipping to change at page 7, line 27 skipping to change at page 7, line 17
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 Handlespace
The scope of the ASAP/ENRP is NOT Internet wide. The namespace is The scope of the ASAP/ENRP is NOT Internet wide. The handlespace 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
ENRP. First, the PU may use DNS to contact an ENRP server. Suppose ASAP/ENRP. First, the PU may use DNS to contact an ENRP server.
a PU in North America wishes to contact the server pool in Japan Suppose a PU in North America wishes to contact the server pool in
instead of North America. The PU would use DNS to get the list of IP Japan instead of North America. The PU would use DNS to get the list
addresses of the Japanese server pool domain, that is, the ENRP of IP 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
RFC2119 [2]. RFC2119 [2].
skipping to change at page 8, line 47 skipping to change at page 8, line 47
0x04 - Deregistration Response 0x04 - Deregistration Response
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 - ASAP Error
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 = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the name to be registered. The pool handle parameter field specifies the 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 transport address, server pooling policy and value, to declare its transport address, server pooling policy and value,
and other operation preferences. Note that the registration message and other operation preferences. Note that the registration message
MUST use SCTP and the IP address(es) of the PE registered within the MUST use SCTP and the IP address(es) of the PE registered within the
Pool Element Parameter MUST be a subset of the addresses of the SCTP Pool Element Parameter MUST be a subset of the addresses of the SCTP
association in respective of the transport protocol registered by the association in respective of the transport protocol registered 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 = 0x02 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
The PE sending the DEREGISTRATION shall fill in the pool handle and The PE sending the 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|R| Message Length | | Type = 0x03 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) flag R (Reject) flag
skipping to change at page 10, line 42 skipping to change at page 10, line 42
its registration values may have been modified or overruled by the its registration values may have been modified or overruled by the
ENRP server (e.g., the selection policy type overruled). If the ENRP server (e.g., the selection policy type overruled). If the
registration was successful and there is no warning this parameter is registration was successful and there is no warning this parameter is
not included. not included.
2.2.4 DEREGISTRATION_RESPONSE message 2.2.4 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 = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Operational Error
This optional TLV parameter is included if an error occurred during This optional TLV parameter is included if an error occurred during
the deregistration process. If the deregistration was successful the deregistration process. If the deregistration was successful
this parameter is not included. this parameter is not included.
2.2.5 NAME_RESOLUTION message 2.2.5 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 = 0x05 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server to request translation of the This message is sent to a ENRP server to request translation of the
Pool Handle to a list of Pool Elements. If sent from a PE the SCTP Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used. association used for registration SHOULD be used.
2.2.6 NAME_RESOLUTION_RESPONSE message 2.2.6 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 = 0x06 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) : : Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 (optional) : : Pool Element Parameter 1 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 26 skipping to change at page 12, line 26
(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
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a PE by the ENRP server as a "health" check. This message is sent to a PE by the ENRP server as a "health" check.
If the transport level Heart Beat mechanism is insufficient, this If the transport level Heart Beat mechanism is insufficient, this
adds heartbeat messages with the goal of determining health status at adds heartbeat messages with the goal of determining health status at
ASAP level in a possibly more timely fashion. (The transport level ASAP level in a possibly more timely fashion. (The transport level
Heart Beat may sometimes be considered insufficient due to that time Heart Beat may sometimes be considered insufficient due to that time
outs are set for too long or heartbeats are not frequent enough, or, outs are set for too long or heartbeats are not frequent enough, or,
skipping to change at page 13, line 10 skipping to change at page 13, line 10
fault detection when SCTP stack is in the kernel. In such a case, fault detection when SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity while SCTP level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, ASAP keepalive monitors the end-to-end between the two SCTP stacks, ASAP keepalive monitors the end-to-end
liveliness of the ASAP layer above it. liveliness of the ASAP layer above it.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 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 = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by the PE to the ENRP server has an This message is sent by the PE to the ENRP server has an
acknowledgment to the ENDPOINT_KEEP_ALIVE message. acknowledgment to the ENDPOINT_KEEP_ALIVE message.
2.2.9 ENDPOINT_UNREACHABLE message 2.2.9 ENDPOINT_UNREACHABLE message
skipping to change at page 13, line 42 skipping to change at page 14, line 12
A PE or PU will send this message to an ENRP server to report the A PE or PU will send this message to an ENRP server to report the
unreachability of the specified PE. unreachability of the specified PE.
2.2.10 SERVER_ANNOUNCE message 2.2.10 SERVER_ANNOUNCE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #1 : : Transport param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #2 : : Transport param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ..... : : ..... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n : : Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 8 skipping to change at page 15, line 16
2.2.13 BUSINESS_CARD message 2.2.13 BUSINESS_CARD message
This message is sent by a PU to a PE or from a PE to a PU. This This message is sent by a PU to a PE or from a PE to a PU. This
parameter MUST NOT be sent if a control channel does NOT exists parameter MUST NOT be sent if a control channel does NOT exists
between the PE and PU. between the PE and PU.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xd |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 preferred list of failover candidates. belongs to and a preferred list of failover candidates.
2.2.14 PEER_ERROR message 2.2.14 ASAP_ERROR message
This message is used to report an operation error. This message is used to report an operation error. Currently the use
of this message is undefined, it is reserved for future use [Editors
Note: we need to come up with concrete uses or get rid of the
message].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xe |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter : : Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. Procedures 3. Procedures
This section will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. failure detection and management are also discussed.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
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 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 [10] 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 the type of transport R2.4) Fill in a User Transport Parameter for the type of transport
and the data/control channel usage the PE is willing to and the data/control channel usage the PE is willing to
support. Note, to join an existing server pool, the PE MUST support. Note, to join an existing server pool, the PE MUST
skipping to change at page 22, line 15 skipping to change at page 22, line 15
SH5.2) The endpoint SHOULD stop the establishment of associations SH5.2) The endpoint SHOULD stop the establishment of associations
and connections. and connections.
SH5.2) The endpoint SHOULD repeat trying to establish an SH5.2) The endpoint SHOULD repeat trying to establish an
association or connection by proceeding to step SH1. It SHOULD association or connection by proceeding to step SH1. It SHOULD
attempt to select a different set of transport addresses to attempt to select a different set of transport addresses to
connect to. connect to.
SH6) The PE or PU shall pick one of the ENRP servers that it was able SH6) The PE or PU shall pick one of the ENRP servers that it was able
to establish an association or connection with, and send all its to establish an association or connection with, and send all its
subsequent the namespace service requests to this new home ENRP subsequent the handlespace service requests to this new home ENRP
server. server.
3.7 Handle ASAP to ENRP Communication Failures 3.7 Handle ASAP to ENRP Communication Failures
Three types of failure may occur when the ASAP endpoint at an Three types of failure may occur when the ASAP endpoint at an
endpoint tries to communicate with the ENRP server: endpoint tries to communicate with the ENRP server:
A) SCTP send failure A) SCTP send failure
B) T1-ENRPrequest timer expiration B) T1-ENRPrequest timer expiration
skipping to change at page 25, line 35 skipping to change at page 25, line 35
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 Transport parameter MUST be a bound IP address in the SCTP User Transport parameter MUST be a bound IP address in the SCTP
endpoint used to communicate with the ENRP server. endpoint used to communicate with the ENRP server.
The ASAP user invokes this primitive to add itself to the namespace, The ASAP user invokes this primitive to add itself to the
thus becoming a Pool Element of a pool. The ASAP user must register handlespace, thus becoming a Pool Element of a pool. The ASAP user
itself with the ENRP server by using this primitive before other ASAP must register itself with the ENRP server by using this primitive
users using the namespace can send message(s) to this ASAP user by before other ASAP users using the handlespace can send message(s) to
Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3). this ASAP user by 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.
4.2 Deregistration.Request Primitive 4.2 Deregistration.Request Primitive
Format: deregistration.request(poolHandle) Format: deregistration.request(poolHandle)
The ASAP PE invokes this primitive to remove itself from the Server The ASAP PE invokes this primitive to remove itself from the Server
skipping to change at page 28, line 9 skipping to change at page 28, line 9
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 SEND primitive in RFC2960 [4] would be used), and, the SEND primitive in RFC2960 [4] would be used), and,
F) if the local cache is implemented, append/update the local cache F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g. 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 [7].
Optionally, the ASAP endpoint of the sender may return a Pool Element Optionally, the ASAP endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that same PE (see Section 4.5.3). that same PE (see Section 4.5.3).
Section 3.7 defines the fail-over procedures for cases where the Section 3.7 defines the fail-over procedures for cases where the
selected PE is found unreachable. selected PE is found unreachable.
4.5.2 Pool Element Selection 4.5.2 Pool Element Selection
skipping to change at page 28, line 34 skipping to change at page 28, line 34
done according to the current server pooling policy of the pool to done according to the current server pooling policy of the pool to
which the message is sent. which the message is sent.
Note, no selection is needed if the ASAP_SEND_TOALL option is set Note, no selection is needed if the ASAP_SEND_TOALL option is set
(see Section 4.5.5). (see Section 4.5.5).
Together with the server pooling policy, each PE can also specify a Together with the server pooling policy, each PE can also specify a
Policy Value for itself at the registration time. The meaning of the Policy Value for itself at the registration time. The meaning of the
policy value depends on the current server pooling policy of the policy value depends on the current server pooling policy of the
group. A PE can also change its policy value whenever it desires, by group. A PE can also change its policy value whenever it desires, by
re-registering itself with the namespace with a new policy value. re-registering itself with the handlespace with a new policy value.
Re-registration shall be done by simply sending another REGISTRATION Re-registration shall be done by simply sending another REGISTRATION
to its home ENRP server (See Section 2.2.1). to its home ENRP server (See Section 2.2.1).
Four basic server pooling policies are defined in ASAP, namely the Four basic server pooling policies are defined in ASAP, namely the
Round Robin, Least Used, Least Used Degrading and Weighted Round Round Robin, Least Used, Least Used Degrading and Weighted Round
Robin. The following sections describes each of these policies. Robin. The following sections describes each of these policies.
4.5.2.1 Round Robin Policy 4.5.2.1 Round Robin Policy
When a ASAP endpoint sends messages by Pool Handle and Round-Robin is When a ASAP endpoint sends messages by Pool Handle and Round-Robin is
skipping to change at page 37, line 8 skipping to change at page 37, line 8
MAX-REG-ATTEMPT - The maximum number of registration attempts to be MAX-REG-ATTEMPT - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
6. Security Considerations 6. Security Considerations
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [7] describes the threats to the Rserpool Response to Threats [8] describes the threats to the Rserpool
architecture in detail and lists the security requirements in architecture in detail and lists the security requirements in
response to each threat. From the threats described in this response to each threat. From the threats described in this
document, the security services required for the Rserpool protocol document, the security services required for the Rserpool protocol
are enumerated below. are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration flooding or spoofing
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server
skipping to change at page 37, line 45 skipping to change at page 37, line 45
----------- -----------
Security mechanism in response: Security protocol which has Security mechanism in response: Security protocol which has
protection from replay attacks protection from replay attacks
Threat 6) Corrupted data which causes a PU to have misinformation Threat 6) Corrupted data which causes a PU to have misinformation
concerning a pool handle resolution concerning a pool handle resolution
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol which supports
integrity protection integrity protection
Threat 7) Eavesdropper snooping on namespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
server server
----------- -----------
Security mechanism in response: ASAP must control the number of Security mechanism in response: ASAP must control the number of
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
skipping to change at page 38, line 38 skipping to change at page 38, line 38
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5) to the ENRP server. Endpoint_Unreachable messages (see Section 3.5) to the ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
Endpoint_KeepAlive messages to the PE (see section x.y??? in [6]). Endpoint_KeepAlive messages to the PE (see section x.y??? in [7]).
6.1 Implementing Security Mechanisms 6.1 Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that well-known distributors of site certificates comparable to those that
issue root certificates for web browsers). issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436 Implementations MUST support TLS with SCTP as described in RFC3436
[8] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP [9] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that we must ensure that RSerPool does not use any features of SCTP that
are not available to an TLS/SCTP user. This is not a difficult are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon
Ong, and many others for their invaluable comments. Ong, and many others for their invaluable comments.
skipping to change at page 41, line 15 skipping to change at page 41, line 15
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2246, January 1999.
1999.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Name Resolution Server Access Protocol (ASAP) and Endpoint Name Resolution
Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-06 Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-07
(work in progress), June 2004. (work in progress), October 2004.
[6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [6] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
Protocol (ENRP)", draft-ietf-rserpool-enrp-08 (work in "Architecture for Reliable Server Pooling",
progress), June 2004. draft-ietf-rserpool-arch-07 (work in progress), October 2003.
[7] Stillman, M., "Threats Introduced by Rserpool and Requirements [7] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-10 (work in
progress), October 2004.
[8] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. draft-ietf-rserpool-threats-03 (work in progress), July 2004.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
8.2 Informational References (non-normative) 8.2 Informational References (non-normative)
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [10] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 4875 Forest Drive
Suite 300 Suite 200
Chicago, IL 60631 Columbia, SC 29206
USA USA
Phone: +1-815-477-2127 Phone:
EMail: rrs@cisco.com EMail: rrs@cisco.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone:
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: +1-607-273-0724 Phone:
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Germany Germany
Phone: Phone:
EMail: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
 End of changes. 

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