draft-ietf-rserpool-asap-11.txt   draft-ietf-rserpool-asap-12.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 22, 2005 Q. Xie Expires: January 19, 2006 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
February 18, 2005 Muenster Univ. of Applied Sciences
July 18, 2005
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-11.txt draft-ietf-rserpool-asap-12.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she 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 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-
Internet-Drafts. 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 August 22, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Handlespace Redundancy Protocol (ENRP) [7] provides a high Endpoint Handlespace Redundancy 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 2.2.1 ASAP_REGISTRATION message . . . . . . . . . . . . . . 9
2.2.2 ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 2.2.2 ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9
2.2.3 ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 2.2.3 ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10
2.2.4 ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10 2.2.4 ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10
2.2.5 ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 2.2.5 ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11
2.2.6 ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 11 2.2.6 ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 11
2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12 2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12
2.2.8 ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13 2.2.8 ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13
2.2.9 ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13 2.2.9 ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 13
2.2.10 ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . 14 2.2.10 ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . 13
2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . 14
2.2.12 ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . 15 2.2.12 ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . 14
2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 15 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . 14
2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15 2.2.14 ASAP_ERROR message . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Handle resolution . . . . . . . . . . . . . . . . . . . . 19 3.3 Handle resolution . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 20 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 21 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 21 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 23 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 23 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 23 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . 22
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 24 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 24 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
skipping to change at page 4, line 16 skipping to change at page 4, line 16
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . 38
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 39
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1 Normative References . . . . . . . . . . . . . . . . . . . 41 8.1 Normative References . . . . . . . . . . . . . . . . . . . 42
8.2 Informational References (non-normative) . . . . . . . . . 41 8.2 Informational References (non-normative) . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 44
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [7] 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 handle-based addressing model which isolates a networks. ASAP uses a handle-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 7, line 22 skipping to change at page 7, line 24
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 Handlespace 1.3.1 Extent of the Handlespace
The scope of the ASAP/ENRP is NOT Internet wide. The handlespace 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 administrative domains. For example, suppose we want to use ASAP/
ASAP/ENRP. First, the PU may use DNS to contact an ENRP server. ENRP. First, the PU may use DNS to contact an ENRP server. Suppose
Suppose a PU in North America wishes to contact the server pool in a PU in North America wishes to contact the server pool in Japan
Japan instead of North America. The PU would use DNS to get the list instead of North America. The PU would use DNS to get the list of IP
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
RFC2119 [2]. RFC2119 [2].
skipping to change at page 10, line 27 skipping to change at page 10, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 may be included if the registration was
events occurred during the registration process. When the 'R' flag rejected. This TLV, if present, indicates the cause of the
is set to '1', this TLV, if present, indicates the cause of the rejection. If the registration was successful this parameter is not
rejection. When the 'R' flag is set to '0', this TLV, if present, included.
serves as a warning to the registering PE, informing it that some of
its registration values may have been modified or overruled by the
ENRP server (e.g., the selection policy type overruled). If the
registration was successful and there is no warning this parameter is
not included.
2.2.4 ASAP_DEREGISTRATION_RESPONSE message 2.2.4 ASAP_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 = 0x04 |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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 26 skipping to change at page 12, line 22
(i.e., the handle resolution request was rejected by the ENRP (i.e., the handle resolution request was rejected by the ENRP
server). The cause code in this TLV (if present) will indicate the server). The cause code in this TLV (if present) will indicate the
reason the handle resolution request was rejected (e.g., the reason the handle resolution request was rejected (e.g., the
requested pool handle was not found). requested pool handle was not found).
2.2.7 ASAP_ENDPOINT_KEEP_ALIVE message 2.2.7 ASAP_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 = 0x07 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x07 |0|0|0|0|0|0|0|H| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier | | Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H (Home ENRP server) flag
When set to '1', indicate that the ENRP server that sends this
message want to be the home ENRP server of the receiver of this
message.
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,
that the transport level Heart Beat mechanism's coverage is limited that the transport level Heart Beat mechanism's coverage is limited
only to the transport level at the two ends.) only to the transport level at the two ends.)
Using ASAP keepalive also has additional value to the reliability of Using ASAP keepalive also has additional value to the reliability of
skipping to change at page 13, line 17 skipping to change at page 13, line 17
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 = 0x08 |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 as an
acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message. acknowledgment to the ASAP_ENDPOINT_KEEP_ALIVE message.
2.2.9 ASAP_ENDPOINT_UNREACHABLE message 2.2.9 ASAP_ENDPOINT_UNREACHABLE 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 = 0x09 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
skipping to change at page 20, line 19 skipping to change at page 19, line 19
If the T1-ENRPrequest timer expires before receiving a response If the T1-ENRPrequest timer expires before receiving a response
message, the ASAP endpoint SHOULD take the steps described in message, the ASAP endpoint SHOULD take the steps described in
Section 3.7.2. If a SEND.FAILURE notification is received from the Section 3.7.2. If a SEND.FAILURE notification is received from the
SCTP layer, the ASAP endpoint SHOULD start the Server Hunt procedure SCTP layer, the ASAP endpoint SHOULD start the Server Hunt procedure
(see Section 3.6) in an attempt to get service from a different ENRP (see Section 3.6) in an attempt to get service from a different ENRP
server. After establishing a new Home ENRP server the ASAP endpoint server. After establishing a new Home ENRP server the ASAP endpoint
SHOULD restart the handle resolution procedure. SHOULD restart the handle resolution procedure.
At the reception of the response message (i.e., an At the reception of the response message (i.e., an
ASAP_HANDLE_RESOLUTION_RESPONSE) the endpoint MUST stop its ASAP_HANDLE_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-
T1-ENRPrequest timer. After stopping the T1 timer the endpoint ENRPrequest timer. After stopping the T1 timer the endpoint SHOULD
SHOULD process the pool handle response as appropriate (e.g. process the pool handle response as appropriate (e.g. populate a
populate a local cache, give the response to the ASAP user, and/or local cache, give the response to the ASAP user, and/or use the
use the response to send the ASAP users message). response to send the ASAP users message).
Note that some ASAP endpoints MAY use a cache to minimize the number Note that some ASAP endpoints MAY use a cache to minimize the number
of handle resolutions made. If such a cache is used it SHOULD: of handle resolutions made. If such a cache is used it SHOULD:
C1) Be consulted before requesting a handle resolution. C1) Be consulted before requesting a handle resolution.
C2) Have a stale timeout time associated with the cache so that even C2) Have a stale timeout time associated with the cache so that even
in the event of a cache-hit, if the cache is "stale" it will cause in the event of a cache-hit, if the cache is "stale" it will cause
a new handle resolution to be issued to update the cache. a new handle resolution to be issued to update the cache.
skipping to change at page 21, line 20 skipping to change at page 20, line 20
KA2.1) Filling in the Pool Handle Parameter with the PE's Pool KA2.1) Filling in the Pool Handle Parameter with the PE's Pool
Handle. Handle.
KA2.2) Fill in the PE Identifier that was used with this PE for KA2.2) Fill in the PE Identifier that was used with this PE for
registration. registration.
KA2.3) Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the KA2.3) Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the
appropriate SCTP association for that ENRP server. appropriate SCTP association for that ENRP server.
KA2.4) Adopt the sender of the ASAP_ENDPOINT_KEEP_ALIVE message as KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE
the new home ENRP server. message is set, adopt the sender of the
ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server.
3.5 Reporting unreachable endpoints 3.5 Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable. Occasionally an ASAP endpoint may realize that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP endpoint This may occur by a specific SCTP error realized by the ASAP endpoint
or via an ASAP user report via the Transport.Failure Primitive or via an ASAP user report via the Transport.Failure Primitive
(Section 4.9.2). In either case the ASAP endpoint SHOULD report the (Section 4.9.2). In either case the ASAP endpoint SHOULD report the
unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE
message to its home ENRP server. The Endpoint should fill in the message to its home ENRP server. The Endpoint should fill in the
Pool Handle and PE identifier of the unreachable endpoint. If the Pool Handle and PE identifier of the unreachable endpoint. If the
skipping to change at page 23, line 42 skipping to change at page 22, line 42
unreachable. unreachable.
In such a case, the ASAP endpoint should not re-send the failed In such a case, the ASAP endpoint should not re-send the failed
message. Instead, it should discard the failed message and start the message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section 3.6 ENRP server hunt procedure as described in Section 3.6
3.7.2 T1-ENRPrequest Timer Expiration 3.7.2 T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the When a T1-ENRPrequest timer expires, the ASAP should re-send the
original request to the ENRP server and re-start the T1-ENRPrequest original request to the ENRP server and re-start the T1-ENRPrequest
timer. In parallel, a SERVER_HUNT message should be issued per timer. In parallel, the server hunt procedure should be started as
Section 3.6 outlined in Section 3.6.
This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times. After This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times. After
that, an Error.Report notification should be generated to inform the that, an Error.Report notification should be generated to inform the
ASAP user and the ENRP request message associated with the timer ASAP user and the ENRP request message associated with the timer
should be discarded. Note that if an alternate ENRP server responds should be discarded. Note that if an alternate ENRP server responds
the ASAP endpoint SHOULD adopt the responding ENRP server as its new the ASAP endpoint SHOULD adopt the responding ENRP server as its new
"home" server and resend the request to the new "home" server. "home" server and resend the request to the new "home" server.
3.8 Cookie handling procedures 3.8 Cookie handling procedures
skipping to change at page 26, line 33 skipping to change at page 26, line 33
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.4 Cache.Purge.Request Primitive 4.4 Cache.Purge.Request Primitive
Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) Format: cache.purge.request([Pool-Handle | Pool-Element-Handle])
If the user passes a Pool handle and local handle translation cache If the user passes a Pool handle and local handle translation cache
exists, the ASAP endpoint should remove the mapping information on exists, the ASAP endpoint should remove the mapping information on
the Pool handle from its local cache. If the user passes a the Pool handle from its local cache. If the user passes a Pool-
Pool-Element-Handle then the Pool handle within is used for the Element-Handle then the Pool handle within is used for the
cache.purge.request. cache.purge.request.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.5 Data.Send.Request Primitive 4.5 Data.Send.Request Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data.send.request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
skipping to change at page 27, line 49 skipping to change at page 27, line 49
PE is made by ASAP endpoint of the sender based on the server PE is made by ASAP endpoint of the sender based on the server
pooling 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 connection using the appropriate send mechanism (e.g. for SCTP the
the SEND primitive in RFC2960 [4] would be used), and, SEND primitive in RFC2960 [4] would be used), and,
F) if the local cache is implemented, append/update the local cache F) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local transport information (e.g. the response. Also, record the local transport information (e.g. the
SCTP association id) if any new transport state was created. SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures see ENRP [7]. 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
skipping to change at page 31, line 18 skipping to change at page 31, line 18
data.send.request primitive gives directions to the senders ASAP data.send.request primitive gives directions to the senders ASAP
endpoint on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise "OR"ing The value of the Options parameter is generated by bit-wise "OR"ing
of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 Use default setting. ASAP_USE_DEFAULT: 0x0000 Use default setting.
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-
re-select an alternate PE from the same pool if one exists, and select an alternate PE from the same pool if one exists, and
silently re-send the message to this newly selected endpoint. silently re-send the message to this newly selected endpoint.
Note that this is a best-effort service. Applications should be Note that this is a best-effort service. Applications should be
aware that messages can be lost during the failover process, even aware that messages can be lost during the failover process, even
if the underlying transport supports retrieval of unacknowledged if the underlying transport supports retrieval of unacknowledged
data (e.g. SCTP) (Example: messages acknowledged by the SCTP data (e.g. SCTP) (Example: messages acknowledged by the SCTP
layer at a PE, but not yet read by the PE when a PE failure layer at a PE, but not yet read by the PE when a PE failure
occurs.) In the case where the underlying transport does not occurs.) In the case where the underlying transport does not
support such retrieval (e.g. TCP), any data already submitted by support such retrieval (e.g. TCP), any data already submitted by
ASAP to the transport layer MAY be lost upon failover. ASAP to the transport layer MAY be lost upon failover.
skipping to change at page 32, line 12 skipping to change at page 32, line 12
endpoint also deliver a copy of the message to itself if the endpoint also deliver a copy of the message to itself if the
sender is a PE 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,
typeOfAddress) senderAddress, typeOfAddress)
When a new user message is received, the ASAP endpoint of the When a new user message is received, the ASAP endpoint of the
receiver uses this notification to pass the message to its upper receiver uses this notification to pass the message to its upper
layer. layer.
Along with the message being passed, the ASAP endpoint of the Along with the message being passed, the ASAP endpoint of the
receiver should also indicate to its upper layer the message senders receiver should also indicate to its upper layer the message senders
address. The senders address can be in the form of either an SCTP address. The senders address can be in the form of either an SCTP
association id, TCP transport address, UDP transport address, or an association id, TCP transport address, UDP transport address, or an
ASAP Pool Element handle. ASAP Pool Element handle.
skipping to change at page 36, line 23 skipping to change at page 36, line 23
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending an ASAP_REGISTRATION T2-registration - A timer started when sending an ASAP_REGISTRATION
request to the home ENRP server, normally set to 30 seconds. request 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 handle space and is used to cause a registration into the ASAP handle space and is used to cause a re-
re-registration at a periodic interval. This timer is normally registration at a periodic interval. This timer is normally set
set to 10 minutes or 20 seconds less than the Life Timer parameter to 10 minutes or 20 seconds less than the Life Timer parameter
used in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
T6-Serverannounce - This timer gives the time between the sending of T6-Serverannounce - This timer gives the time between the sending of
consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to
1 second. 1 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 40, line 7 skipping to change at page 41, line 7
Implementations MUST support TLS with SCTP as described in RFC3436 Implementations MUST support TLS with SCTP as described in RFC3436
[9] 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 John Loughney, Lyndon Ong, Walter Johnson,
Ong, and many others for their invaluable comments. Thomas Dreibholz, and many others for their invaluable comments and
feedback.
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 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,
1999. January 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 Handlespace Server Access Protocol (ASAP) and Endpoint Handlespace
Redundancy Protocol (ENRP) Parameters", Redundancy Protocol (ENRP) Parameters",
Internet-Draft draft-ietf-rserpool-common-param-08, February draft-ietf-rserpool-common-param-09 (work in progress),
2005. July 2005.
[6] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [6] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and
"Architecture for Reliable Server Pooling", A. Silverton, "Architecture for Reliable Server Pooling",
Internet-Draft draft-ietf-rserpool-arch-09, February 2005. draft-ietf-rserpool-arch-10 (work in progress), July 2005.
[7] Xie, Q., Stewart, R., Stillman, M., Tuexen, M. and A. Silverton, [7] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
"Endpoint Handlespace Redundancy Protocol (ENRP)", Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)",
Internet-Draft draft-ietf-rserpool-enrp-11, February 2005. draft-ietf-rserpool-enrp-12 (work in progress), July 2005.
[8] Stillman, M., "Threats Introduced by Rserpool and Requirements [8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
for Security in Response to Threats", Holdrege, "Threats Introduced by Rserpool and Requirements for
Internet-Draft draft-ietf-rserpool-threats-04, January 2005. Security in Response to Threats", draft-ietf-rserpool-threats-05
(work in progress), July 2005.
[9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", [9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP",
RFC 3436, December 2002. RFC 3436, December 2002.
8.2 Informational References (non-normative) 8.2 Informational References (non-normative)
[10] 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.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
skipping to change at page 42, line 36 skipping to change at page 43, line 36
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: Phone:
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany Germany
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
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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 

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