draft-ietf-rserpool-asap-08.txt   draft-ietf-rserpool-asap-09.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: April 20, 2004 Q. Xie Expires: December 8, 2004 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
October 21, 2003 June 9, 2004
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-08.txt draft-ietf-rserpool-asap-09.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
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
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 April 20, 2004. This Internet-Draft will expire on December 8, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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
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.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
PE's and ENRP servers MUST use SCTP. PE's and ENRP servers MUST use SCTP.
The high availability server pooling is gained by combining two The high availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for name to address translation, load sharing 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 . . . . . . . . . . . . . . 7
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 Namespace . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 14 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 14
2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 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
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 23 3.9 Business Card handling procedures . . . . . . . . . . . . 23
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 25 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . 25
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 27 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . 27
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 28 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . 28
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 29 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . 29
4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 30 4.5.4 Send by Transport Address . . . . . . . . . . . . . . 30
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 30 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . 31
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 33 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . 33
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 34 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . 34
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34
4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 35 4.9.1 Translation.Request Primitive . . . . . . . . . . . . 35
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 35 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . 35
5. Timers, Variables, and Thresholds . . . . . . . . . . . . 36 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . 36
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . 37
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
Informational References (non-normative) . . . . . . . . . 42 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 42 8.2 Informational References (non-normative) . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
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 [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 name server pool. ASAP depends on the services of a high availability
space a.k.a. ENRP [6]. name space a.k.a. ENRP [6].
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ASAP User: 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 use home server and a well known port number. The channel MAY make
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 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 with scope. All ENRP servers in an operation scope can communicate
one another through this channel via either multicast OR direct with one another through this channel via either multicast OR
point to point SCTP associations. direct 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 provides timers and configurable parameters as appropriate. Section 5
threshold and protocol variables. provides threshold and protocol variables.
1.3 Scope of ASAP 1.3 Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during transaction failover. If a host or application fails during
processing of a transaction this transaction may be lost. Some processing of a transaction this transaction may be lost. Some
services may provide a way to handle the failure, but this is not services may provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself will NOT 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 a ENRP. First, the PU may use DNS to contact an ENRP server. Suppose
PU in North America wishes to contact the server pool in Japan a PU in North America wishes to contact the server pool in Japan
instead of North America. The PU would use DNS to get the 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 10, line 28 skipping to change at page 10, line 28
R (Reject) flag R (Reject) flag
When set to '1', indicate that the ENRP server that sent this message When set to '1', indicate that the ENRP server that sent this message
has rejected the registration. Otherwise, the registration is has rejected the registration. Otherwise, the registration is
granted. granted.
Operational Error Operational Error
This optional TLV parameter is included if an error or some atypical This optional TLV parameter is included if an error or some atypical
events occurred during the registration process. When the 'R' flag is events occurred during the registration process. When the 'R' flag
set to '1', this TLV, if present, indicates the cause of the is set to '1', this TLV, if present, indicates the cause of the
rejection. When the 'R' flag is set to '0', this TLV, if present, 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 serves as a warning to the registering PE, informing it that some of
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 this the deregistration process. If the deregistration was successful
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 = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 47 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 not of the pool. If not present, round-robin is assumed. This TLV is
present when the response is negative (i.e., a rejection). not 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 the In a positive response, at least one PE TLV MUST be present. When
response is negative, no PE TLVs are included. the 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 16, line 15 skipping to change at page 16, line 15
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). The triggered by a user request primitive (discussed in Section 4.1).
ASAP endpoint MUST register using an SCTP association between the 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
skipping to change at page 17, line 30 skipping to change at page 17, line 30
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 The registration response may also indicate that the registration is
accepted with a warning, often indicating that the ENRP server might accepted with a warning, often indicating that the ENRP server might
have made modifications to the value of some registration attribute have made modifications to the value of some registration attribute
or attributes (such as policy type, transport usage, etc.). When this or attributes (such as policy type, transport usage, etc.). When
happens, the PE SHOULD immediately notify its upper layer about the this happens, the PE SHOULD immediately notify its upper layer about
registration modifications. This gives the upper layer a chance, for the registration modifications. This gives the upper layer a chance,
example, to withdraw itself from the pool if such modifications are for example, to withdraw itself from the pool if such modifications
unacceptable for its operation. 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 at timer. At its expiration a re-registration SHOULD be made starting
step R1 including (at completion) restarting the T4-reregistration at step R1 including (at completion) restarting the T4-reregistration
timer. timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
registration attempts it makes in a local variable. If repeated registration attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count 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 18, line 47 skipping to change at page 18, line 50
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) wishes sending a message to all of them). When an Endpoint (PE or PU)
to resolve a name it MUST take the following actions: wishes to resolve a name it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message ( Section 2.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 25, line 31 skipping to change at page 25, line 31
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 User Transport parameter. Note that any IP address contained within a
Transport parameter MUST be a bound IP address in the SCTP endpoint User Transport parameter MUST be a bound IP address in the SCTP
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 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 13 skipping to change at page 27, 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 default, This is the simplest form of send.data.request primitive. By
this directs ASAP to send the message to one of the Pool Elements in default, this directs ASAP to send the message to one of the Pool
the specified pool. Elements in 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 38 skipping to change at page 27, 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 PE and transmit the message to it. In that case, the choice of the
is made by ASAP endpoint of the sender based on the server pooling PE is made by ASAP endpoint of the sender based on the server
policy as discussed in Section 4.5.2 pooling policy as discussed in Section 4.5.2
C) Optionally create any transport endpoint that may be needed to C) Optionally create any transport endpoint that may be needed to
communicate with the PE selected. communicate with the PE selected.
D) if no transport association or connection exists towards the D) if no transport association or connection exists towards the
destination PE, ASAP will establish any needed transport state, destination PE, ASAP will establish any needed transport state,
E) send out the queued message(s) to the appropriate transport E) send out the queued message(s) to the appropriate transport
connection using the appropriate send mechanism (e.g. for SCTP the connection using the appropriate send mechanism (e.g. for SCTP
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 [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 28 skipping to change at page 29, 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 at over time. As with the Least Used policy, every local cache update
the sender will bring the policy back to Least Used with Degradation. at the sender will bring the policy back to Least Used with
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 21 skipping to change at page 31, line 25
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 layer data (e.g. SCTP) (Example: messages acknowledged by the SCTP
at a PE, but not yet read by the PE when a PE failure occurs.) In layer at a PE, but not yet read by the PE when a PE failure
the case where the underlying transport does not support such occurs.) In the case where the underlying transport does not
retrieval (e.g. TCP), any data already submitted by ASAP to the support such retrieval (e.g. TCP), any data already submitted by
transport layer MAY be lost upon failover. ASAP to the 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 endpoint with ASAP_SEND_TO_ALL option. It permits the senders ASAP
also deliver a copy of the message to itself if the sender is a PE endpoint also deliver a copy of the message to itself if the
of the pool (i.e., loop-back). sender is a PE 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 35, line 32
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" ENRP ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home"
server in response to this primitive. Note ASAP SHOULD NOT send a ENRP server in response to this primitive. Note ASAP SHOULD NOT send
ENDPOINT_UNREACHABLE UNLESS the user has actually made a previous a ENDPOINT_UNREACHABLE UNLESS the user has actually made a previous
request to send data to the PE. request to send data to the PE.
5. Timers, Variables, and Thresholds 5. Timers, Variables, and Thresholds
The following is a summary of the timers, variables, and pre-set The following is a summary of the timers, variables, 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 36, 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 set re-registration at a periodic interval. This timer is normally
to 10 minutes or 20 seconds less than the Life Timer parameter set 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
consecutive 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
skipping to change at page 37, line 10 skipping to change at page 37, line 10
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 [7] 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 document, response to each threat. From the threats described in this
the security services required for the Rserpool protocol are document, the security services required for the Rserpool protocol
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
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
Threat 1 and 2 taken together results in mutual authentication of the Threat 1 and 2 taken together results in mutual authentication of the
skipping to change at page 38, line 26 skipping to change at page 38, line 26
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports all protocols to provide the security services required. TLS supports
these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
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
skipping to change at page 41, line 5 skipping to change at page 41, line 5
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.
Normative References 8. 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., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 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-04 Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-06
(work in progress), May 2003. (work in progress), June 2004.
[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-07 (work in Protocol (ENRP)", draft-ietf-rserpool-enrp-08 (work in
progress), October 2003. progress), June 2004.
[7] Stillman, M., "Threats Introduced by Rserpool and Requirements [7] 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-02 (work in progress), Sept 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) 8.2 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
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
skipping to change at page 43, line 8 skipping to change at page 43, line 8
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 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
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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