draft-ietf-rserpool-asap-16.txt   draft-ietf-rserpool-asap-17.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Experimental Q. Xie Intended status: Experimental Q. Xie
Expires: January 10, 2008 Motorola, Inc. Expires: March 25, 2008 Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
July 9, 2007 September 22, 2007
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-16.txt draft-ietf-rserpool-asap-17.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 10, 2008. This Internet-Draft will expire on March 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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) [10] provides a high Endpoint Handlespace Redundancy Protocol (ENRP) [9] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
handle-based addressing model which isolates a logical communication handle-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
pool, providing full transparent support for server-pooling and load pool, providing full transparent support for server-pooling and load
sharing. It also allows dynamic system scalability - members of a sharing. It also allows dynamic system scalability - members of a
server pool can be added or removed at any time without interrupting server pool can be added or removed at any time without interrupting
the service. the service.
ASAP is designed to take full advantage of the network level ASAP is designed to take full advantage of the network level
redundancy provided by the Stream Transmission Control Protocol redundancy provided by the Stream Transmission Control Protocol
(SCTP) RFC2960 [5]. Each transport protocol, other than SCTP, MUST (SCTP) RFC2960 [3]. Each transport protocol, other than SCTP, MUST
have an accompanying transport mapping document. It should be noted have an accompanying transport mapping document. It should be noted
that ASAP messages passed between PE's and ENRP servers MUST use the that ASAP messages passed between PE's and ENRP servers MUST use the
SCTP transport protocol. SCTP transport protocol.
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 pool handle to address translation, load sharing interface for pool handle to address translation, load sharing
management, and fault management while ENRP defines the high management, and fault management while ENRP defines the high
availability pool handle translation service. availability pool handle translation service.
skipping to change at page 3, line 47 skipping to change at page 3, line 47
3.7. Handling ASAP Endpoint to ENRP Server Communication 3.7. Handling ASAP Endpoint to ENRP Server Communication
Failures . . . . . . . . . . . . . . . . . . . . . . . . . 26 Failures . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 26 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 26
3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 26 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 26
3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 27 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 27
3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 27 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 27
3.9. Business Card handling procedures . . . . . . . . . . . . 27 3.9. Business Card handling procedures . . . . . . . . . . . . 27
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 29 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 29
4.1. Registration.Request Primitive . . . . . . . . . . . . . . 29 4.1. Registration.Request Primitive . . . . . . . . . . . . . . 29
4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 29 4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 29
4.3. Cache.Populate.Request Primitive . . . . . . . . . . . . . 30 4.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 30
4.4. Cache.Purge.Request Primitive . . . . . . . . . . . . . . 30 4.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 30
4.5. Data.Send.Request Primitive . . . . . . . . . . . . . . . 30 4.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 30
4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 31 4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 31
4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 32 4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 32
4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 33 4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 33
4.5.4. Send by Transport Address . . . . . . . . . . . . . . 34 4.5.4. Send by Transport Address . . . . . . . . . . . . . . 34
4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 34 4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 34
4.6. Data.Received Notification . . . . . . . . . . . . . . . . 35 4.6. Data.Received Notification . . . . . . . . . . . . . . . . 35
4.7. Error.Report Notification . . . . . . . . . . . . . . . . 36 4.7. Error.Report Notification . . . . . . . . . . . . . . . . 36
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 36 4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 36
4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 38 4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 38
skipping to change at page 4, line 27 skipping to change at page 4, line 27
5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
6.1. A New Table for ASAP Message Types . . . . . . . . . . . . 42 6.1. A New Table for ASAP Message Types . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7.1. Summary of Rserpool Security Threats . . . . . . . . . . . 43 7.1. Summary of Rserpool Security Threats . . . . . . . . . . . 43
7.2. Implementing Security Mechanisms . . . . . . . . . . . . . 44 7.2. Implementing Security Mechanisms . . . . . . . . . . . . . 44
7.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 45 7.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48
9.2. Informational References (non-normative) . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction 1. Introduction
The Aggregate Server Access Protocol (ASAP) when used in conjunction The Aggregate Server Access Protocol (ASAP) when used in conjunction
with Endpoint Name Resolution Protocol [10] provides a high with Endpoint Name Resolution Protocol [9] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
handle-based addressing model which isolates a logical communication handle-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.
When multiple receiver instances exist under the same handle (a.k.a, When multiple receiver instances exist under the same handle (a.k.a,
a server pool),an ASAP endpoint will select one Pool Element (PE), a server pool),an ASAP endpoint will select one Pool Element (PE),
based on the current load sharing policy indicated by the server based on the current load sharing policy indicated by the server
pool, and deliver its message to the selected PE. pool, and deliver its message to the selected PE.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
attempt to deliver the message to that PE. In other words, ASAP is attempt to deliver the message to that PE. In other words, ASAP is
capable of transparent fail-over amongst PE instances within a server capable of transparent fail-over amongst PE instances within a server
pool. pool.
ASAP depends on ENRP which provides a high availability pool handle ASAP depends on ENRP which provides a high availability pool handle
space. ASAP is responsible for the abstraction of the underlying space. ASAP is responsible for the abstraction of the underlying
transport technologies, load distribution management, fault transport technologies, load distribution management, fault
management, as well as presentation to the upper layer (aka an ASAP management, as well as presentation to the upper layer (aka an ASAP
user) via a unified primitive interface. user) via a unified primitive interface.
When SCTP RFC2960 [5] is used as the transport layer protocol, ASAP When SCTP RFC2960 [3] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by can seamlessly incorporate the link-layer redundancy provided by
SCTP. SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high availability
server pool. server pool.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
skipping to change at page 7, line 33 skipping to change at page 7, line 33
administrative domains. For example, suppose the use of ASAP and administrative domains. For example, suppose the use of ASAP and
ENRP is wanted. First, the PU may use DNS to contact an ENRP server. ENRP is wanted. First, the PU may use DNS to contact an ENRP server.
Suppose a PU in North America wishes to contact a server pool in Suppose a PU in North America wishes to contact a server pool in
Japan instead of North America. The PU would use DNS to get the list Japan instead of North America. The PU would use DNS to get the list
of IP addresses of the Japanese server pool, that is, the ENRP client of IP addresses of the Japanese server pool, that is, the ENRP client
channel in Japan. From there the PU would query the Home ENRP server channel in Japan. From there the PU would query the Home ENRP server
it established and then directly contact the PE(s) of interest. it established 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
they appear in this document, are to be interpreted as described in document are to be interpreted as described in RFC2119 [1].
RFC2119 [2].
2. Message Definitions 2. Message Definitions
All messages as well as their fields described below shall be in All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length Network Byte Order during transmission. For fields with a length
bigger than 4 bytes, a number in a pair of parentheses may follow the bigger than 4 bytes, a number in a pair of parentheses may follow the
field name to indicate the length of the field in number of bytes. field name to indicate the length of the field in number of bytes.
2.1. ASAP Parameter Formats 2.1. ASAP Parameter Formats
The basic message format and all parameter formats can be found in The basic message format and all parameter formats can be found in
ENRP-ASAP [9]. Note also that ALL ASAP messages exchanged between an ENRP-ASAP [8]. Note also that ALL ASAP messages exchanged between an
ENRP server and a PE MUST use SCTP as transport, while ASAP messages ENRP server and a PE MUST use SCTP as transport, while ASAP messages
exchanged between an ENRP server and a PU MUST use either SCTP or TCP exchanged between an ENRP server and a PU MUST use either SCTP or TCP
as transport. PE to PU data traffic MAY use any transport protocol as transport. PE to PU data traffic MAY use any transport protocol
specified by the PE during registration. specified by the PE during registration.
2.2. ASAP Messages 2.2. ASAP Messages
This section details the individual messages used by ASAP. These This section details the individual messages used by ASAP. These
messages are composed of a standard message format found in Section 4 messages are composed of a standard message format found in Section 4
of ENRP-ASAP [9]. The parameter descriptions can be found in Section of ENRP-ASAP [8]. The parameter descriptions can be found in Section
3 of ENRP-ASAP [9]. 3 of ENRP-ASAP [8].
The following ASAP message types are defined in this section: The following ASAP message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - ASAP_REGISTRATION 0x01 - ASAP_REGISTRATION
0x02 - ASAP_DEREGISTRATION 0x02 - ASAP_DEREGISTRATION
0x03 - ASAP_REGISTRATION_RESPONSE 0x03 - ASAP_REGISTRATION_RESPONSE
0x04 - ASAP_DEREGISTRATION_RESPONSE 0x04 - ASAP_DEREGISTRATION_RESPONSE
skipping to change at page 9, line 31 skipping to change at page 9, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter: Pool Handle Parameter:
See [9] section 3.7 See [8] section 3.7
Pool Element Parameter: Pool Element Parameter:
See [9] section 3.8 See [8] section 3.8
2.2.2. ASAP_DEREGISTRATION message 2.2.2. ASAP_DEREGISTRATION message
The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP
Server to remove itself from a pool to which it registered. Server to remove itself from a pool to which it registered.
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 = 0x02 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x02 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
Pool Handle Parameter: Pool Handle Parameter:
See [9] section 3.7 See [8] section 3.7
PE Identifier Parameter: PE Identifier Parameter:
See [9] section 3.12 See [8] section 3.12
The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle
and the PE identifier parameter in order to allow the ENRP server to and the PE identifier parameter in order to allow the ENRP server to
verify the identity of the endpoint. Note that deregistration is NOT verify the identity of the endpoint. Note that deregistration is NOT
allowed by proxy, in other words a PE may only deregister itself. allowed by proxy, in other words a PE may only deregister itself.
2.2.3. ASAP_REGISTRATION_RESPONSE message 2.2.3. ASAP_REGISTRATION_RESPONSE message
The ASAP_REGISTRATION_RESPONSE message is sent in response by the The ASAP_REGISTRATION_RESPONSE message is sent in response by the
Home ENRP Server to the PE that sent a ASAP_REGISTRATION message. Home ENRP Server to the PE that sent a ASAP_REGISTRATION message.
skipping to change at page 10, line 41 skipping to change at page 10, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) Flag: R (Reject) Flag:
When set to '1', this flag indicates that the ENRP server sending When set to '1', this flag indicates that the ENRP server sending
this message has rejected the registration. Otherwise when this flag this message has rejected the registration. Otherwise when this flag
is set to '0', this indicates the registration has been granted. is set to '0', this indicates the registration has been granted.
Pool Handle Parameter: Pool Handle Parameter:
See [9] section 3.7. See [8] section 3.7.
PE Identifier Parameter: PE Identifier Parameter:
See [9] section 3.12 See [8] section 3.12
Operational Error Parameter (optional): Operational Error Parameter (optional):
See [9] section 3.10 See [8] section 3.10
This parameter is included if an error or some atypical events This parameter is included if an error or some atypical events
occurred during the registration process. When the R flag is set to occurred during the registration process. When the R flag is set to
'1', this parameter, if present, indicates the cause of the '1', this parameter, if present, indicates the cause of the
rejection. When the R flag is set to '0', this parameter, if rejection. When the R flag is set to '0', this parameter, if
present, serves as a warning to the registering PE, informing it that present, serves as a warning to the registering PE, informing it that
some of its registration values may have been modified by the ENRP some of its registration values may have been modified by the ENRP
server. If the registration was successful and there is no warning, server. If the registration was successful and there is no warning,
this parameter is not included. this parameter is not included.
skipping to change at page 11, line 31 skipping to change at page 11, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) : : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle Parameter: Pool Handle Parameter:
See [9] section 3.7. See [8] section 3.7.
PE Identifier Parameter: PE Identifier Parameter:
See [9] section 3.12. See [8] section 3.12.
Operational Error: Operational Error:
See [9] section 3.10. See [8] section 3.10.
This parameter is included if an error or some atypical events This parameter is included if an error or some atypical events
occurred during the deregistration process. If the deregistration occurred during the deregistration process. If the deregistration
was successful this parameter is not included. was successful this parameter is not included.
2.2.5. ASAP_HANDLE_RESOLUTION message 2.2.5. ASAP_HANDLE_RESOLUTION message
The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to
its Home ENRP Server to resolve a pool handle into a list of pool its Home ENRP Server to resolve a pool handle into a list of pool
elements that are members of the pool indicated by the pool handle. elements that are members of the pool indicated by the pool handle.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
the ENRP servers do NOT share state regarding which of its PU's are the ENRP servers do NOT share state regarding which of its PU's are
requesting automatic update of state. Thus upon change of Home ENRP requesting automatic update of state. Thus upon change of Home ENRP
Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message
with the 'S' bit set to 1. Note also, that the 'S' bit will only with the 'S' bit set to 1. Note also, that the 'S' bit will only
cause dynamic update of a Pool when the Pool exists. If a negative cause dynamic update of a Pool when the Pool exists. If a negative
response is returned, no further updates to the Pool (when it is response is returned, no further updates to the Pool (when it is
created) will occur. created) will occur.
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message
The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by
the Home ENRP server of the PU or PE that sent a the Home ENRP server of the PU or PE that sent a
ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if
the PU as requested Dynamic updates. the PU as requested Dynamic updates.
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
skipping to change at page 13, line 34 skipping to change at page 13, line 34
A bit: A bit:
This bit is set to '1' if the ENRP server accepts the request to send This bit is set to '1' if the ENRP server accepts the request to send
automatic updates (i.e. the S bit was set on the request). If this automatic updates (i.e. the S bit was set on the request). If this
bit is set to '0' either the ENRP server does NOT support automatic bit is set to '0' either the ENRP server does NOT support automatic
update, it has resource issues and cannot supply this feature or the update, it has resource issues and cannot supply this feature or the
user did not request it. user did not request it.
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
Overall PE Selection Policy (optional): Overall PE Selection Policy (optional):
See [9] section 3.6. See [8] section 3.6.
This parameter can be present when the response is positive. If This parameter can be present when the response is positive. If
present, it indicates the overall pool member selection policy of the present, it indicates the overall pool member selection policy of the
pool. If not present, a round robin overall pool member selection pool. If not present, a round robin overall pool member selection
policy is assumed. This parameter is not present when the response policy is assumed. This parameter is not present when the response
is negative. is negative.
Note, any load policy parameter within a Pool Element Parameter (if Note, any load policy parameter within a 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 member selection policy. overall pool member selection policy.
Pool Element Parameters (optional): Pool Element Parameters (optional):
See [9] section 3.10. See [8] section 3.10.
When the response is positive, an array of PE parameters are When the response is positive, an array of PE parameters are
included, indicating the current information about the PEs in the included, indicating the current information about the PEs in the
named pool. At least one PE parameter MUST be present. When the named pool. At least one PE parameter MUST be present. When the
response is negative, no PE parameters are included. response is negative, no PE parameters are included.
Operational Error (optional): Operational Error (optional):
See [9] section 3.10. See [8] section 3.10.
The presence of this parameter indicates that the response is The presence of this parameter indicates that the response is
negative (the handle resolution request was rejected by the ENRP negative (the handle resolution request was rejected by the ENRP
server). The cause code in this parameter (if present) will indicate server). The cause code in this parameter (if present) will indicate
the reason the handle resolution request was rejected (e.g., the the reason the handle resolution request was rejected (e.g., the
requested pool handle was not found). The absence of this parmaeter requested pool handle was not found). The absence of this parmaeter
indicates that the response is positive. indicates that the response is positive.
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message
skipping to change at page 14, line 50 skipping to change at page 14, line 50
H (Home ENRP server) flag H (Home ENRP server) flag
When set to '1', indicate that the ENRP server that sends this 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 want to be the home ENRP server of the receiver of this
message. message.
Server Identifier: 32 bit (unsigned integer) Server Identifier: 32 bit (unsigned integer)
This is the ID of the ENRP server, as discussed in Section 3.2.1 of This is the ID of the ENRP server, as discussed in Section 3.2.1 of
ENRP [10]. ENRP [9].
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message
The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response
to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP Server. to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an ENRP Server.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
PE Identifier parameter: PE Identifier parameter:
See [9] section 3.12. See [8] section 3.12.
2.2.9. ASAP_ENDPOINT_UNREACHABLE message 2.2.9. ASAP_ENDPOINT_UNREACHABLE message
The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to
its Home ENRP Server to report an unreachable PE. its Home ENRP Server to report an unreachable PE.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
PE Identifier parameter: PE Identifier parameter:
See [9] section 3.12. See [8] section 3.12.
2.2.10. ASAP_SERVER_ANNOUNCE message 2.2.10. ASAP_SERVER_ANNOUNCE message
The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that
PUs and PEs know the transport information necessary to connect to PUs and PEs know the transport information necessary to connect to
the ENRP server. the ENRP server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 32 skipping to change at page 16, line 32
: : : :
: ..... : : ..... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n : : Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Identifier: 32 bit (unsigned integer) Server Identifier: 32 bit (unsigned integer)
This is the ID of the ENRP server, as discussed in Section 3.2.1 in This is the ID of the ENRP server, as discussed in Section 3.2.1 in
ENRP [10]. ENRP [9].
Transport parameters (optional): Transport parameters (optional):
See [9] seections 3.3 and 3.4 for the SCTP and TCP Transport See [8] seections 3.3 and 3.4 for the SCTP and TCP Transport
parameters respectively. parameters respectively.
Only SCTP and TCP Transport parameters are allowed for use within the Only SCTP and TCP Transport parameters are allowed for use within the
SERVER_ANNOUNCE message. SERVER_ANNOUNCE message.
2.2.11. ASAP_COOKIE message 2.2.11. ASAP_COOKIE message
The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to
convey information it wishes to share using a control channel. convey information it wishes to share using a control channel.
skipping to change at page 17, line 9 skipping to change at page 17, line 9
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 = 0x0b |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter : Cookie Parameter :
See [9] section 3.11. See [8] section 3.11.
2.2.12. ASAP_COOKIE_ECHO message 2.2.12. ASAP_COOKIE_ECHO message
The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it
detects a failure with the current PE to aid in failover. The Cookie detects a failure with the current PE to aid in failover. The Cookie
Parameter sent by the PE is the latest one received from the failed Parameter sent by the PE is the latest one received from the failed
PE. PE.
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 = 0x0c |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie Parameter: Cookie Parameter:
See [9] section 3.11. See [8] section 3.11.
2.2.13. ASAP_BUSINESS_CARD message 2.2.13. ASAP_BUSINESS_CARD message
The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE
to a PU using a control channel to convey the pool handle and a to a PU using a control channel to convey the pool handle and a
preferred failover ordering. preferred failover ordering.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 5 skipping to change at page 18, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 : : Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. : : .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N : : Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pool Handle parameter: Pool Handle parameter:
See [9] section 3.7. See [8] section 3.7.
Pool Element parameters: Pool Element parameters:
See [9] section 3.8. See [8] section 3.8.
2.2.14. ASAP_ERROR message 2.2.14. ASAP_ERROR message
The ASAP_ERROR message is sent in response by an ASAP endpoint The ASAP_ERROR message is sent in response by an ASAP endpoint
receiving an unknown message or an unknown parameter to the sending receiving an unknown message or an unknown parameter to the sending
ASAP endpoint to report the problem or issue. ASAP endpoint to report the problem or issue.
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 = 0x0e |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0e |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter : : Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operation Error parameter: Operation Error parameter:
See [9] section 3.10 See [8] section 3.10
When an ASAP endpoint receives an ASAP message with an unknown When an ASAP endpoint receives an ASAP message with an unknown
message type or a message of known type that contains an unknown message type or a message of known type that contains an unknown
parameter, it SHOULD handle the unknown message or the unknown parameter, it SHOULD handle the unknown message or the unknown
parameter according to the unrecognized message and parameter parameter according to the unrecognized message and parameter
handling rules defined in Section 3. handling rules defined in Section 3.
According to the rules, if an error report to the message sender is According to the rules, if an error report to the message sender is
needed, the ASAP endpoint that discovered the error SHOULD send back needed, the ASAP endpoint that discovered the error SHOULD send back
an ASAP_ERROR message which includes an Operation Error parameter an ASAP_ERROR message which includes an Operation Error parameter
skipping to change at page 19, line 40 skipping to change at page 19, line 40
service user requests to the PE). service user requests to the PE).
R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION
message as defined in Section 2.2.1. In formulating the message, message as defined in Section 2.2.1. In formulating the message,
the PE MUST: the PE MUST:
R2.1) Fill in the Pool Handle Parameter to specify which server R2.1) Fill in the Pool Handle Parameter to specify which server
pool the ASAP endpoint wishes to join. pool the ASAP endpoint wishes to join.
R2.2) Fill in the PE identifier using a good quality randomly R2.2) Fill in the PE identifier using a good quality randomly
generated number (RFC1750 [12] provides some information on generated number (RFC4086 [11] provides some information on
randomness guidelines). randomness guidelines).
R2.3) Fill in the Registration Life time parameter with the R2.3) Fill in the Registration Life time parameter with the
number of seconds that this registration is valid for. Note a number of seconds that this registration is valid for. Note a
PE that wishes to continue service MUST re-register after the PE that wishes to continue service MUST re-register after the
registration expires. registration expires.
R2.4) Fill in a User Transport Parameter to specify the type of R2.4) Fill in a User Transport Parameter to specify the type of
transport and the data/control channel usage the PE is willing transport and the data/control channel usage the PE is willing
to support. Note, in joining an existing server pool, the PE to support. Note, in joining an existing server pool, the PE
skipping to change at page 30, line 9 skipping to change at page 30, line 9
Format: deregistration.request(poolHandle) Format: deregistration.request(poolHandle)
The ASAP PE invokes this primitive to remove itself from the Server The ASAP PE invokes this primitive to remove itself from the Server
Pool. This should be used as a part of the graceful shutdown process Pool. This should be used as a part of the graceful shutdown process
by the application. by the application.
A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the
home ENRP server (see Section 2.2.2 and Section 3.2). home ENRP server (see Section 2.2.2 and Section 3.2).
4.3. Cache.Populate.Request Primitive 4.3. CachePopulateRequest Primitive
Format: cache.populate.request([Pool-Handle | Format: cache_populate_request([Pool-Handle |
Pool-Element-Handle]) Pool-Element-Handle])
If the address type is a Pool handle and a local handle translation If the address type is a Pool handle and a local handle translation
cache exists, the ASAP endpoint should initiate a mapping information cache exists, the ASAP endpoint should initiate a mapping information
query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle
and update it local cache when the response comes back from the ENRP and update it local cache when the response comes back from the ENRP
server. server.
If a Pool-Element-Handle is passed then the Pool Handle is unpacked If a Pool-Element-Handle is passed then the Pool Handle is unpacked
from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message
is sent to the ENRP server for resolution. When the response message is sent to the ENRP server for resolution. When the response message
returns from the ENRP server the local cache is updated. returns from the ENRP server the local cache is updated.
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. CachePurgeRequest 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 Pool- the Pool handle from its local cache. If the user passes a 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. DataSendRequest Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data_send_request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
This primitive requests ASAP to send a message to some specified Pool This primitive requests ASAP to send a message to some specified Pool
or Pool Element within the current Operational scope. or Pool Element within the current Operational scope.
Depending on the address type used for the send request, the senders Depending on the address type used for the send request, the senders
ASAP endpoint may perform address translation and Pool Element ASAP endpoint may perform address translation and Pool Element
selection before sending the message out. This also MAY dictate the selection before sending the message out. This also MAY dictate the
creation of a local transport endpoint in order to meet the required creation of a local transport endpoint in order to meet the required
transport type. transport type.
The data.send.request primitive can take different forms of address The data_send_request primitive can take different forms of address
types as described in the following sections. types as described in the following sections.
4.5.1. Sending to a Pool Handle 4.5.1. Sending to a Pool Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicates a pool handle. indicates a pool handle.
This is the simplest form of send.data.request primitive. By This is the simplest form of send_data_request primitive. By
default, this directs ASAP to send the message to one of the Pool default, this directs ASAP to send the message to one of the Pool
Elements in the specified pool. Elements in the specified pool.
Before sending the message out to the pool, the 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
skipping to change at page 32, line 6 skipping to change at page 32, line 6
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 the connection using the appropriate send mechanism (e.g. for SCTP the
SEND primitive in RFC2960 [5] would be used), and, SEND primitive in RFC2960 [3] 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 [10]. For more on the ENRP server request procedures see ENRP [9].
Optionally, the ASAP endpoint of the sender may return a Pool Element Optionally, the ASAP endpoint of the sender may return a Pool Element
handle of the selected PE to the application after sending the handle of the selected PE to the application after sending the
message. This PE handle can then be used for future transmissions to message. This PE handle can then be used for future transmissions to
that same PE (see Section 4.5.3). that same PE (see Section 4.5.3).
Section 3.7 defines the fail-over procedures for cases where the Section 3.7 defines the fail-over procedures for cases where the
selected PE is found unreachable. selected PE is found unreachable.
4.5.2. Pool Element Selection 4.5.2. Pool Element Selection
skipping to change at page 32, line 43 skipping to change at page 32, line 43
Together with the server pooling policy, each PE can also specify a Together with the server pooling policy, each PE can also specify a
Policy Value for itself at the registration time. The meaning of the Policy Value for itself at the registration time. The meaning of the
policy value depends on the current server pooling policy of the policy value depends on the current server pooling policy of the
group. A PE can also change its policy value whenever it desires, by group. A PE can also change its policy value whenever it desires, by
re-registering itself with the handlespace with a new policy value. re-registering itself with the handlespace with a new policy value.
Re-registration shall be done by simply sending another Re-registration shall be done by simply sending another
ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1).
One basic policy is defined in this document, others can be found in One basic policy is defined in this document, others can be found in
[8] [7]
4.5.2.1. Round Robin Policy 4.5.2.1. Round Robin Policy
When an ASAP endpoint sends messages by Pool Handle and Round-Robin When an ASAP endpoint sends messages by Pool Handle and Round-Robin
is the current policy of that Pool, the ASAP endpoint of the sender is the current policy of that Pool, the ASAP endpoint of the sender
will select the receiver for each outbound message by round-Robining will select the receiver for each outbound message by round-Robining
through all the registered PEs in that Pool, in an attempt to achieve through all the registered PEs in that Pool, in an attempt to achieve
an even distribution of outbound messages. Note that in a large an even distribution of outbound messages. Note that in a large
server pool, the ENRP server MAY NOT send back all PEs to the ASAP server pool, the ENRP server MAY not send back all PEs to the ASAP
client. In this case the client or PU will be performing a round client. In this case the client or PU will be performing a round
robin policy on a subset of the entire Pool. robin policy on a subset of the entire Pool.
4.5.3. Sending to a Pool Element Handle 4.5.3. Sending to a Pool Element Handle
In this case the destinationAddress and typeOfAddress together In this case the destinationAddress and typeOfAddress together
indicate an ASAP Pool Element handle. indicate an ASAP Pool Element handle.
This requests the ASAP endpoint to deliver the message to the PE This requests the ASAP endpoint to deliver the message to the PE
identified by the Pool Element handle. identified by the Pool Element handle.
skipping to change at page 34, line 26 skipping to change at page 34, line 26
This directs the senders ASAP endpoint to send the message out to the This directs the senders ASAP endpoint to send the message out to the
specified transport address. specified transport address.
No endpoint fail-over is support when this form of send request is No endpoint fail-over is support when this form of send request is
used. This form of send request effectively by-passes the ASAP used. This form of send request effectively by-passes the ASAP
endpoint. endpoint.
4.5.5. Message Delivery Options 4.5.5. Message Delivery Options
The Options parameter passed in the various forms of the above The Options parameter passed in the various forms of the above
data.send.request primitive gives directions to the 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 re- handle is found unreachable, the sender's ASAP endpoint SHOULD re-
skipping to change at page 37, line 24 skipping to change at page 37, line 24
|4. ASAP_HANDLE_RESOLUTION_RSP +---+ | |4. ASAP_HANDLE_RESOLUTION_RSP +---+ |
|------------------------------->| | |------------------------------->| |
| +---+ | | +---+ |
| | 5 | | | | 5 | |
| +---+ 6. "hello1" | | +---+ 6. "hello1" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
data.send.request("new-handle", handle-type, "hello1", 6, 0); data_send_request("new-handle", handle-type, "hello1", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-handle" in The ASAP endpoint, in response, looks up the pool "new-handle" in
its local cache but fails to find it. its local cache but fails to find it.
2) The ASAP endpoint of PU queues the message, and sends an 2) The ASAP endpoint of PU queues the message, and sends an
ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all
information about pool "new-handle". information about pool "new-handle".
3) A T1-ENRPrequest timer is started while the ASAP endpoint is 3) A T1-ENRPrequest timer is started while the ASAP endpoint is
waiting for the response from the ENRP server. waiting for the response from the ENRP server.
skipping to change at page 38, line 22 skipping to change at page 38, line 22
| | | | | |
| +---+ | | +---+ |
| | 1 | | | | 1 | |
| +---+ 2. "hello2" | | +---+ 2. "hello2" |
| |---------------->| | |---------------->|
| | | | | |
1) The user at PU invokes: 1) The user at PU invokes:
pdata.send.request("new-handle", handle-type, "hello2", 6, 0); pdata_send_request("new-handle", handle-type, "hello2", 6, 0);
The ASAP endpoint, in response, looks up the pool "new-handle" in The ASAP endpoint, in response, looks up the pool "new-handle" in
its local cache and find the mapping information. its local cache and find the mapping information.
2) Based on the server pooling policy of "new-handle", ASAP at PU 2) Based on the server pooling policy of "new-handle", ASAP at PU
selects the PE (assume EPx is selected again), and sends out selects the PE (assume EPx is selected again), and sends out
"hello2" message (assume the SCTP association is already set up). "hello2" message (assume the SCTP association is already set up).
4.9. PE send failure 4.9. PE send failure
skipping to change at page 40, line 40 skipping to change at page 40, line 40
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
valid. It is normally set to 5 seconds. valid. It is normally set to 5 seconds.
5.2. Variables 5.2. Variables
stale.cache.value - A threshold variable that indicates how long a stale_cache_value - A threshold variable that indicates how long a
cache entry is valid for. cache entry is valid for.
5.3. Thresholds 5.3. Thresholds
MAX-REG-ATTEMPT - The maximum number of registration attempts to be MAX-REG-ATTEMPT - The maximum number of registration attempts to be
made before a server hunt is issued. The default value of this is made before a server hunt is issued. The default value of this is
set to 2. set to 2.
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
skipping to change at page 42, line 45 skipping to change at page 42, line 45
0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX 0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX
0x0a ASAP_SERVER_ANNOUNCE RFCXXXX 0x0a ASAP_SERVER_ANNOUNCE RFCXXXX
0x0b ASAP_COOKIE RFCXXXX 0x0b ASAP_COOKIE RFCXXXX
0x0c ASAP_COOKIE_ECHO RFCXXXX 0x0c ASAP_COOKIE_ECHO RFCXXXX
0x0d ASAP_BUSINESS_CARD RFCXXXX 0x0d ASAP_BUSINESS_CARD RFCXXXX
0x0e ASAP_ERROR RFCXXXX 0x0e ASAP_ERROR RFCXXXX
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX
For registering at IANA an ASAP Message Type in this table a request For registering at IANA an ASAP Message Type in this table a request
has to be made to assign such a number. This number must be unique. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [4] MUST be applied. The "Specification Required" policy of RFC2434 [2] MUST be applied.
7. Security Considerations 7. Security Considerations
We present a summary of the of the threats to the Rserpool We present a summary of the of the threats to the Rserpool
architecture EE and describe security requirements in response to architecture and describe security requirements in response to
mitigate the threats.E EE Next we present the security mechanisms, mitigate the threats. Next we present the security mechanisms, based
based on TLS, that are implementation EE requirements in response to on TLS, that are implementation requirements in response to the
the threats.E Finally, we present a chain of trust EE argument that threats. Finally, we present a chain of trust argument that examines
examines critical data paths in Rserpool and shows how these paths critical data paths in Rserpool and shows how these paths are
are protected by the TLS implementation. protected by the TLS implementation.
7.1. Summary of Rserpool Security Threats 7.1. Summary of Rserpool Security Threats
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [11] describes the threats to the Rserpool Response to Threats [10] describes the threats to the Rserpool
architecture in detail lists the security requirements in response to architecture in detail lists the security requirements in response to
each threat.E From the threats described in this document, the each threat. From the threats described in this document, the
security services required for the Rserpool protocol are enumerated security services required for the Rserpool protocol are enumerated
below. 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
skipping to change at page 44, line 36 skipping to change at page 44, line 36
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)
7.2. Implementing Security Mechanisms 7.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for EE We do not define any new security mechanisms specifically for
responding to threats 1-7.E Rather we use an existing IETF security responding to threats 1-7. Rather we use an existing IETF security
EE protocol, specifically [6], to provide the security services protocol, specifically [4], to provide the security services
required.ETLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented.EThe TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported at a minimum by implementors of TLS for Rserpool.E For supported at a minimum by implementors of TLS for Rserpool. For
purposes of backwards compatibility, ENRP SHOULD support EE purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA.EImplementers MAY also support any EE TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other IETF approved ciphersuites. other IETF approved ciphersuites.
ENRP servers, PEs, PUs MUST implement TLS.E ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication.E ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves.E PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname.E PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use.E All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that well-known distributors of site certificates comparable to those that
issue root certificates for web browsers). issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in [7] or TLS Implementations MUST support TLS with SCTP as described in [5] or TLS
over TCP as described in [3].EWhen using TLS/SCTP we must ensure that over TCP as described in [6]. When using TLS/SCTP we must ensure
RSerPool does not use any features of SCTP that are not available to that RSerPool does not use any features of SCTP that are not
an TLS/SCTP user.E This is not a difficult technical problem, but available to an TLS/SCTP user. This is not a difficult technical
simply a requirement.E When describing an API of the RSerPool lower problem, but simply a requirement. When describing an API of the
layer we have also to take into account the differences between TLS RSerPool lower layer we have also to take into account the
and SCTP. differences between TLS and SCTP.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document)
to the ENRP server. 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
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
[10]). [9]).
7.3. Chain of trust 7.3. Chain of trust
Security is mandatory to implement in Rserpool and is based on TLS Security is mandatory to implement in Rserpool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
Rserpool -- namely PU, PE and ENRP server. We define an ENRP server Rserpool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
skipping to change at page 48, line 9 skipping to change at page 48, line 9
8. Acknowledgments 8. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
BCP 9, RFC 2026, October 1996.
[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. and C. Allen, "The TLS Protocol Version 1.0", [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
RFC 2246, January 1999.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960, Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000. October 2000.
[6] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [4] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J., and M. Stillman, "Requirements for Reliable Server J., and M. Stillman, "Requirements for Reliable Server
Pooling", RFC 3237, January 2002. Pooling", RFC 3237, January 2002.
[7] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
[8] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Policies", draft-ietf-rserpool-policies-04 (work in progress), Protocol Version 1.1", RFC 4346, April 2006.
March 2007.
[9] Stewart, R., "Aggregate Server Access Protocol (ASAP) and [7] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
Policies", draft-ietf-rserpool-policies-05 (work in progress),
July 2007.
[8] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-11 (work in progress), draft-ietf-rserpool-common-param-12 (work in progress),
October 2006. July 2007.
[10] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", [9] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
draft-ietf-rserpool-enrp-15 (work in progress), January 2007. draft-ietf-rserpool-enrp-16 (work in progress), July 2007.
[11] Stillman, M., "Threats Introduced by Rserpool and Requirements [10] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M.
for Security in response to Threats", Stillman, "Threats Introduced by Rserpool and Requirements for
draft-ietf-rserpool-threats-06 (work in progress), Security in response to Threats",
November 2006. draft-ietf-rserpool-threats-08 (work in progress),
September 2007.
9.2. Informational References (non-normative) 9.2. Informative References
[12] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Recommendations for Security", RFC 1750, December 1994. Requirements for Security", BCP 106, RFC 4086, June 2005.
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
 End of changes. 81 change blocks. 
121 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/