draft-ietf-rserpool-asap-19.txt   draft-ietf-rserpool-asap-20.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Q. Xie
Intended status: Experimental Q. Xie Intended status: Experimental
Expires: September 29, 2008 Motorola, Inc. Expires: November 30, 2008 M. Stillman
M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
March 28, 2008 May 29, 2008
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-19.txt draft-ietf-rserpool-asap-20.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 38
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 September 29, 2008. This Internet-Draft will expire on November 30, 2008.
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) Endpoint Handlespace Redundancy Protocol (ENRP)
[I-D.ietf-rserpool-enrp] provides a high availability data transfer [I-D.ietf-rserpool-enrp] provides a high availability data transfer
mechanism over IP networks. ASAP uses a handle-based addressing mechanism over IP networks. ASAP uses a handle-based addressing
model which isolates a logical communication endpoint from its IP model which isolates a logical communication endpoint from its IP
address(es), thus effectively eliminating the binding between the address(es), thus effectively eliminating the binding between the
communication endpoint and its physical IP address(es) which normally communication endpoint and its physical IP address(es) which normally
skipping to change at page 3, line 45 skipping to change at page 3, line 45
3.5. Unreachable endpoints . . . . . . . . . . . . . . . . . . 26 3.5. Unreachable endpoints . . . . . . . . . . . . . . . . . . 26
3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 27 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 27
3.7. Handling ASAP Endpoint to ENRP Server Communication 3.7. Handling ASAP Endpoint to ENRP Server Communication
Failures . . . . . . . . . . . . . . . . . . . . . . . . . 29 Failures . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 29 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 29
3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 29 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 29
3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 30 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 30
3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 30 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 30
3.9. Business Card handling procedures . . . . . . . . . . . . 30 3.9. Business Card handling procedures . . . . . . . . . . . . 30
4. Roles of Endpoints . . . . . . . . . . . . . . . . . . . . . . 32 4. Roles of Endpoints . . . . . . . . . . . . . . . . . . . . . . 32
5. SCTP considerations . . . . . . . . . . . . . . . . . . . . . 33 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 33
6. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 34 6. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 34
6.1. Registration.Request Primitive . . . . . . . . . . . . . . 34 6.1. Registration.Request Primitive . . . . . . . . . . . . . . 34
6.2. Deregistration.Request Primitive . . . . . . . . . . . . . 34 6.2. Deregistration.Request Primitive . . . . . . . . . . . . . 34
6.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 35 6.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 35
6.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 35 6.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 35
6.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 35 6.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 35
6.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 36 6.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 36
6.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 37 6.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 37
6.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 38 6.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 38
6.5.4. Send by Transport Address . . . . . . . . . . . . . . 39 6.5.4. Send by Transport Address . . . . . . . . . . . . . . 39
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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:
ASAP user: Either a PE or PU that uses ASAP. ASAP user: Either a PE or PU that uses ASAP.
Business Card: When presented by a PU or PE it specifies the pool
the sender belongs to and provides a list of alternate PEs in case
of fail-overs.
Operational scope: The part of the network visible to pool users by Operational scope: The part of the network visible to pool users by
a specific instance of the reliable server pooling protocols. a specific instance of the reliable server pooling protocols.
Pool (or server pool): A collection of servers providing the same Pool (or server pool): A collection of servers providing the same
application functionality. application functionality.
Pool handle: A logical pointer to a pool. Each server pool will be Pool handle: A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a unique identifiable in the operational scope of the system by a unique
pool handle. pool handle.
skipping to change at page 6, line 24 skipping to change at page 6, line 27
Pool user: A server pool user. Pool user: A server pool user.
Pool element handle (or endpoint handle): A logical pointer to a Pool element handle (or endpoint handle): A logical pointer to a
particular pool element in a pool, consisting of the pool handle particular pool element in a pool, consisting of the pool handle
and a destination transport address of the pool element. and a destination transport address of the pool element.
Handle space: A cohesive structure of pool handles and relations Handle space: A cohesive structure of pool handles and relations
that may be queried by an internal or external agent. that may be queried by an internal or external agent.
Home ENRP server: The ENRP server to which a PE or PU currently Home ENRP server: The ENRP server to which a PE or PU currently
sends all namespace service requests. A PE MUST only have one sends all namespace service requests. A PE must only have one
home ENRP server at any given time and both the PE and its home home ENRP server at any given time and both the PE and its home
ENRP server MUST know and keep track of this relationship. A PU ENRP server MUST know and keep track of this relationship. A PU
SHOULD select one of the available ENRP servers as its Home ENRP should select one of the available ENRP servers as its Home ENRP
server but the collective ENRP servers may change this by the server but the collective ENRP servers may change this by the
sending or a ASAP_ENDPOINT_KEEP_ALIVE message. sending or a ASAP_ENDPOINT_KEEP_ALIVE message.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User sends all namespace service requests. The client channel is User sends all namespace service requests. The client channel is
usually defined by the transport address of the Home ENRP server usually defined by the transport address of the Home ENRP server
and a well known port number. The channel MAY make use of and a well known port number. The channel MAY make use of
multicast or a named list of ENRP servers. multicast or a named list of ENRP servers.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Transport address: A Transport Address is traditionally defined by Transport address: A Transport Address is traditionally defined by
Network Layer address, Transport Layer protocol and Transport Network Layer address, Transport Layer protocol and Transport
Layer port number. In the case of SCTP running over IP, a Layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the Transport protocol). and an SCTP port number (where SCTP is the Transport protocol).
1.2. Organization of this document 1.2. Organization of this document
Section 2 details the ASAP message formats. In Section 3 we provide Section 2 details the ASAP message formats. In Section 3 we provide
detailed ASAP procedures for for the ASAP implementer. In Section 6 detailed ASAP procedures for the ASAP implementer. Section 4
we give details of the ASAP interface, focusing on the communication summarizes which messages needs to be supported by which nodes and
primitives between ASAP the applications above ASAP and ASAP itself, Section 5 describes the usage of SCTP. In Section 6 details of the
and the communications primitives between ASAP and SCTP (or other ASAP interface are given, focusing on the communication primitives
transport layers). Also included in this discussion are relevant between ASAP the applications above ASAP and ASAP itself, and the
timers and configurable parameters as appropriate. Section 7 communications primitives between ASAP and SCTP (or other transport
provides threshold and protocol variables. layers). Also included in this discussion are relevant timers and
configurable parameters as appropriate. Section 7 provides threshold
and protocol variables.
Variables, timers and constants are used in the text when necessary. It should be noted that variables, timers and constants are used in
A complete list can be found in Section 7 the text when necessary. The complete list can be found in
Section 7.
1.3. Scope of ASAP 1.3. Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during the transaction failover. If a host or application fails during the
processing of a transaction, this transaction may be lost. Some processing of a transaction, this transaction may be lost. Some
services MAY provide a way to handle the failure, but this is not services MAY provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself does NOT share building a mechanism to share state but ASAP in itself does NOT share
skipping to change at page 27, line 33 skipping to change at page 27, line 33
Optionally, an ENRP server may also periodically send point-to-point Optionally, an ENRP server may also periodically send point-to-point
ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
of the PEs owned by the ENRP server in order to check their of the PEs owned by the ENRP server in order to check their
reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
fails, the ENRP server MUST consider the PE as unreachable and MUST fails, the ENRP server MUST consider the PE as unreachable and MUST
remove the PE from its handlespace . Note, if an ENRP server owns a remove the PE from its handlespace . Note, if an ENRP server owns a
large number of PEs, the implementation should pay attention not to large number of PEs, the implementation should pay attention not to
flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages.
Instead, the implementation MUST distribute the Instead, the implementation MUST distribute the
ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. This
can be achieved by varying the time between two
ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/
minus 50 percent.
3.6. ENRP server hunt procedures 3.6. ENRP server hunt procedures
Each PU and PE manages a list of transport addresses of ENRP servers Each PU and PE manages a list of transport addresses of ENRP servers
it knows about. it knows about.
If multicast capabilities are used within the operational scope an If multicast capabilities are used within the operational scope an
ENRP server MUST send periodically every (N+1)*T6-Serverannounce an ENRP server MUST send periodically every (N+1)*T6-Serverannounce an
ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the
transport addresses available for ASAP communication on the multicast transport addresses available for ASAP communication on the multicast
skipping to change at page 29, line 31 skipping to change at page 29, line 34
B) T1-ENRPrequest timer expiration B) T1-ENRPrequest timer expiration
C) Registration failure C) Registration failure
3.7.1. SCTP Send Failure 3.7.1. SCTP Send Failure
This communication failure indicates that the SCTP layer was unable This communication failure indicates that the SCTP layer was unable
to deliver a message sent to an ENRP server. In other words, the to deliver a message sent to an ENRP server. In other words, the
ENRP server is unreachable. ENRP server is unreachable.
In such a case, the ASAP endpoint should not re-send the In such a case, the ASAP endpoint MUST NOT re-send the undeliverable
undeliverable message. Instead, it should discard the message and message. Instead, it SHOULD discard the message and start the ENRP
start the ENRP server hunt procedure as described in Section 3.6 . server hunt procedure as described in Section 3.6 . After finding a
After finding a new Home ENRP server, the ASAP endpoint should new Home ENRP server, the ASAP endpoint should re-send the request.
reconstruct and retransmit the request.
Note that an ASAP endpoint MAY also choose to NOT discard the Note that an ASAP endpoint MAY also choose to NOT discard the
message, but to queue it for retransmission after a new Home ENRP message, but to queue it for retransmission after a new Home ENRP
server is found. If an ASAP endpoint does choose to discard the server is found. If an ASAP endpoint does choose to discard the
message, after a new Home ENRP server is found, the ASAP endpoint message, after a new Home ENRP server is found, the ASAP endpoint
MUST be capable of reconstructing the original request. MUST be capable of reconstructing the original request.
3.7.2. T1-ENRPrequest Timer Expiration 3.7.2. T1-ENRPrequest Timer Expiration
When the T1-ENRPrequest timer expires, the ASAP endpoint should When the T1-ENRPrequest timer expires, the ASAP endpoint should
skipping to change at page 30, line 21 skipping to change at page 30, line 25
Registration failure is discussed in Section 3.1. Registration failure is discussed in Section 3.1.
3.8. Cookie handling procedures 3.8. Cookie handling procedures
Whenever a PE wants, and a control channel exists, it can send an Whenever a PE wants, and a control channel exists, it can send an
ASAP_COOKIE message to a PU via the control channel. The PU's ASAP ASAP_COOKIE message to a PU via the control channel. The PU's ASAP
endpoint stores the Cookie parameter and discards an older cookie if endpoint stores the Cookie parameter and discards an older cookie if
it is previously stored. it is previously stored.
Note: a control channel is a communication channel between a PU and Note: a control channel is a communication channel between a PU and
PE that does not end in data passed to the user. This is PE that does not carry data passed to the user. This is accomplished
accomplished with SCTP by using a PPID to separate the ASAP messages with SCTP by using a PPID to separate the ASAP messages (Cookie and
(Cookie and Business Card) from normal data messages. Business Card) from normal data messages.
If the PU's ASAP endpoint detects a failure and initiates a failover If the PU's ASAP endpoint detects a failure and initiates a failover
to a different PE, it SHOULD send the lastest received cookie to a different PE, it SHOULD send the lastest received cookie
parameter in an ASAP_COOKIE_ECHO message to the new PE as the first parameter in an ASAP_COOKIE_ECHO message to the new PE as the first
message on the control channel. Upper layers may be involved in the message on the control channel. Upper layers may be involved in the
failover procedure. failover procedure.
The cookie handling procedure can be used for state sharing. The cookie handling procedure can be used for state sharing.
Therefore a cookie should be signed by the sending PE ASAP endpoint Therefore a cookie should be signed by the sending PE ASAP endpoint
and the cookie should be verified by the receiving PE's ASAP and the cookie should be verified by the receiving PE's ASAP
skipping to change at page 33, line 5 skipping to change at page 33, line 5
An ENRP server MUST implement the handling of ASAP_REGISTRATION, An ENRP server MUST implement the handling of ASAP_REGISTRATION,
ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION ASAP_REGISTRATION_RESPONSE, and
ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support ASAP_DEREGISTRATION_RESPONSE messages. Furthermore it MUST support
the handling of ASAP_ENDPOINT_KEEP_ALIVE, the handling of ASAP_ENDPOINT_KEEP_ALIVE,
ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and
ASAP_ERROR messages. Furthermore it MAY support the handling of ASAP_ERROR messages. Furthermore it MAY support the handling of
ASAP_SERVER_ANNOUNCE messages. ASAP_SERVER_ANNOUNCE messages.
If a node acts as a PU and a PE, it MUST fullfil both roles. If a node acts as a PU and a PE, it MUST fullfil both roles.
5. SCTP considerations 5. SCTP Considerations
Each ASAP message is considered as an SCTP user message. The PPID Each ASAP message is considered as an SCTP user message. The PPID
registered for ASAP SHOULD be used. The SCTP port used at the ENRP registered for ASAP SHOULD be used. The SCTP port used at the ENRP
server might be preconfigured or announced in the server might be preconfigured or announced in the
ASAP_SERVER_ANNOUNCE message or the well known ASAP port. ASAP_SERVER_ANNOUNCE message or the well known ASAP port.
ASAP messages beloning to the control channel MUST be sent using the ASAP messages beloning to the control channel MUST be sent using the
PPID registered for ASAP. Messages belonging to the data channel PPID registered for ASAP. Messages belonging to the data channel
MUST NOT use the PPID registered for ASAP. MUST NOT use the PPID registered for ASAP.
skipping to change at page 38, line 5 skipping to change at page 38, line 5
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
[I-D.ietf-rserpool-policies] [I-D.ietf-rserpool-policies]
6.5.2.1. Round Robin Policy 6.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 might 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.
6.5.3. Sending to a Pool Element Handle 6.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 39, line 48 skipping to change at page 39, line 48
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.
ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP
endpoint from re-sending the message to any alternate PE in case endpoint from re-sending the message to any alternate PE in case
that the first selected PE or the PE pointed to by the PE handle that the first selected PE or the PE pointed to by the PE handle
is found unreachable. Instead, the senders ASAP endpoint shall is found unreachable. Instead, the senders ASAP endpoint shall
notify its upper layer about the unreachability with an notify its upper layer about the unreachability with an
Error.Report and return any unsent data. Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP
endpoint to send the message to the same PE in the pool that the endpoint to send the message to the same PE in the pool that the
skipping to change at page 47, line 45 skipping to change at page 47, 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] MUST be applied. The "Specification Required" policy of [RFC5226] MUST be applied.
8.2. Port numbers 8.2. Port numbers
The references for the already assigned port numbers The references for the already assigned port numbers
asap-tcp 3863/tcp asap-tcp 3863/tcp
asap-udp 3863/udp asap-udp 3863/udp
asap-sctp 3863/sctp asap-sctp 3863/sctp
skipping to change at page 54, line 12 skipping to change at page 54, line 12
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Loughney, J., and M. Stillman, "Requirements for Reliable Loughney, J., and M. Stillman, "Requirements for Reliable
Server Pooling", RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[I-D.ietf-rserpool-policies] [I-D.ietf-rserpool-policies]
Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
Policies", draft-ietf-rserpool-policies-08 (work in Policies", draft-ietf-rserpool-policies-08 (work in
progress), March 2008. progress), March 2008.
[I-D.ietf-rserpool-common-param] [I-D.ietf-rserpool-common-param]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint "Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-16 (work in progress), draft-ietf-rserpool-common-param-16 (work in progress),
March 2008. March 2008.
[I-D.ietf-rserpool-enrp] [I-D.ietf-rserpool-enrp]
Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-18 (work in progress), (ENRP)", draft-ietf-rserpool-enrp-19 (work in progress),
November 2007. March 2008.
[I-D.ietf-rserpool-threats] [I-D.ietf-rserpool-threats]
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Sengodan, "Threats Introduced by RSerPool and Requirements Sengodan, "Threats Introduced by RSerPool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-09 (work in progress), draft-ietf-rserpool-threats-12 (work in progress),
October 2007. May 2008.
11.2. Informative References 11.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
Phone: Phone:
Email: rrs@cisco.com Email: randall@lakerest.net
Qiaobing Xie Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA USA
Phone: Phone: +1 224-465-5954
Email: qxie1@email.mot.com Email: Qiaobing.Xie@gmail.org
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
 End of changes. 26 change blocks. 
48 lines changed or deleted 52 lines changed or added

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