draft-ietf-rserpool-overview-05.txt   draft-ietf-rserpool-overview-06.txt 
Network Working Group P. Lei Network Working Group P. Lei
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational L. Ong Intended status: Informational L. Ong
Expires: August 25, 2008 Ciena Corporation Expires: November 7, 2008 Ciena Corporation
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
T. Dreibholz T. Dreibholz
University of Duisburg-Essen University of Duisburg-Essen
February 22, 2008 May 06, 2008
An Overview of Reliable Server Pooling Protocols An Overview of Reliable Server Pooling Protocols
draft-ietf-rserpool-overview-05.txt draft-ietf-rserpool-overview-06.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 August 25, 2008. This Internet-Draft will expire on November 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Reliable Server Pooling effort (abbreviated "RSerPool"), provides The Reliable Server Pooling effort (abbreviated "RSerPool"), provides
an application-independent set of services and protocols for building an application-independent set of services and protocols for building
fault tolerant and highly available client/server applications. This fault tolerant and highly available client/server applications. This
document provides an overview of the protocols and mechanisms in the document provides an overview of the protocols and mechanisms in the
reliable server pooling suite. reliable server pooling suite.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6 2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6
2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6 2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6
2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 7
2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7
2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7 2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7
2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7 2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7
2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 8
2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 8
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8 3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8
3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server Discovery and Home Server Selection . . . . . . . . 8 3.2. Server Discovery and Home Server Selection . . . . . . . . 9
3.3. Failure Detection, Handlespace Audit and 3.3. Failure Detection, Handlespace Audit and
Synchronization . . . . . . . . . . . . . . . . . . . . . 9 Synchronization . . . . . . . . . . . . . . . . . . . . . 9
3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9 3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Example Scenario using RSerPool Resolution Service . . . . 9 4.1. Example Scenario using RSerPool Resolution Service . . . . 9
4.2. Example Scenario using RSerPool Session Services . . . . . 11 4.2. Example Scenario using RSerPool Session Services . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Reference Implementation . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Reliable Server Pooling (RSerPool) protocol suite is designed to The Reliable Server Pooling (RSerPool) protocol suite is designed to
provide client applications ("pool users") with the ability to select provide client applications ("pool users") with the ability to select
a server (a "pool element") from among a group of servers providing a server (a "pool element") from among a group of servers providing
equivalent service (a "pool"). equivalent service (a "pool"). The protocols are currently targeted
for Experimental Track.
The RSerPool architecture supports high-availability and load The RSerPool architecture supports high-availability and load
balancing by enabling a pool user to identify the most appropriate balancing by enabling a pool user to identify the most appropriate
server from the server pool at a given time. The architecture is server from the server pool at a given time. The architecture is
defined to support a set of basic goals: defined to support a set of basic goals:
o application-independent protocol mechanisms o application-independent protocol mechanisms
o separation of server naming from IP addressing o separation of server naming from IP addressing
skipping to change at page 4, line 35 skipping to change at page 4, line 35
....................... .......................
Figure 1 Figure 1
A server pool is defined as a set of one or more servers providing A server pool is defined as a set of one or more servers providing
the same application functionality. The servers are called Pool the same application functionality. The servers are called Pool
Elements (PEs). Multiple PEs in a server pool can be used to provide Elements (PEs). Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example. The PEs register into fault tolerance or load sharing, for example. The PEs register into
and deregister out of the pool at an entity called the Endpoint and deregister out of the pool at an entity called the Endpoint
haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate
Server Access Protocol ASAP [2] (this association is labelled ASAP(1) Server Access Protocol ASAP [I-D.ietf-rserpool-asap] (this
in the figure). association is labelled ASAP(1) in the figure).
Each server pool is identified by a unique byte string called the Each server pool is identified by a unique byte string called the
pool handle (PH). The pool handle allows a mapping from the pool to pool handle (PH). The pool handle allows a mapping from the pool to
a specific PE located by its IP address (both IPv4 and IPv6 PE a specific PE located by its IP address (both IPv4 and IPv6 PE
addresses are supported) and port number. The pool handle is what is addresses are supported) and port number. The pool handle is what is
specified by the Pool User (PU) when it attempts to access a server specified by the Pool User (PU) when it attempts to access a server
in the pool. To resolve the pool handle to the address necessary to in the pool. To resolve the pool handle to the address necessary to
access a PE, the PU consults an ENRP server using ASAP (this access a PE, the PU consults an ENRP server using ASAP (this
association is labeled ASAP(2) in the figure). The protocols used association is labeled ASAP(2) in the figure). The space of pool
between PU and PE are application-specific. handles is assumed to be a flat space with limited operational scope
(see RFC3237 [RFC3237]). Administration of pool handles is not
addressed by the RSerPool protocol drafts at this time. The
protocols used between PU and PE are application-specific. It is
assumed that the PU and PE are configured to support a common set of
protocols for application layer communication, independent of the
RSerPool mechanisms.
RSerPool provides a number of tools to aid client migration between RSerPool provides a number of tools to aid client migration between
servers on server failure: it allows the client to identify servers on server failure: it allows the client to identify
alternative servers, either on initial discovery or in real time; it alternative servers, either on initial discovery or in real time; it
also allows the original server to provide a state cookie to the also allows the original server to provide a state cookie to the
client that can be forwarded to an alternative server to provide client that can be forwarded to an alternative server to provide
application-specific state information. This information is application-specific state information. This information is
exchanged between PE and PU directly, over the association labeled PU exchanged between PE and PU directly, over the association labeled PU
to PE in the figure. to PE in the figure.
It is envisioned that ENRP servers provide a fully distributed and It is envisioned that ENRP servers provide a fully distributed and
fault-tolerant registry service. They use ENRP [3] to maintain fault-tolerant registry service. They use ENRP
synchronization of data concerning the pool handle mapping space. [I-D.ietf-rserpool-enrp] to maintain synchronization of data
For PUs and PEs, the ENRP servers are functionally equal. Due to the concerning the pool handle mapping space. For PUs and PEs, the ENRP
synchronization provided by ENRP, they can contact an arbitrary one servers are functionally equal. Due to the synchronization provided
for registration/deregistration (PE) or PH resolution (PU). An by ENRP, they can contact an arbitrary one for registration/
illustration containing 3 ENRP servers is provided in Figure 2 below: deregistration (PE) or PH resolution (PU). An illustration
containing 3 ENRP servers is provided in Figure 2 below:
______ _____ ______ _____
... / ENRP \ / ENRP \ ... ... / ENRP \ / ENRP \ ...
PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
... ASAP \______/ ENRP \______/ ASAP ... ... ASAP \______/ ENRP \______/ ASAP ...
^ ^ ^ ^
| | | |
| / ENRP \ | | / ENRP \ |
+---->|Server|<----+ +---->|Server|<----+
ENRP \______/ ENRP ENRP \______/ ENRP
^ ^
| ASAP | ASAP
v v
... ...
PEs/PUs PEs/PUs
... ...
Figure 2 Figure 2
The requirements for the Reliable Server Pooling framework are The requirements for the Reliable Server Pooling framework are
defined in RFC3237 [1]. It is worth noting that the requirements on defined in RFC3237 [RFC3237]. It is worth noting that the
RSerPool in the area of load balancing partially overlap with GRID requirements on RSerPool in the area of load balancing partially
computing/high performance computing. However, the scope of both overlap with GRID computing/high performance computing. However, the
areas is completely different: GRID and high performance computing scope of both areas is completely different: GRID and high
also cover topics like managing different administrative domains, performance computing also cover topics like managing different
data locking and synchronization, inter-session communication and administrative domains, data locking and synchronization, inter-
resource accounting for powerful computation services, but the session communication and resource accounting for powerful
intention of RSerPool is simply a lightweight realization of load computation services, but the intention of RSerPool is simply a
distribution and session management. In particular, these lightweight realization of load distribution and session management.
functionalities are intended to be used on systems with small memory
and CPU resources only. Any further functionality is not in the In particular, these functionalities are intended to be used on
scope of RSerPool and can -- if necessary -- provided by the systems with small memory and CPU resources only. Any further
application itself. functionality is not in the scope of RSerPool and can -- if necessary
-- provided by the application itself.
This document provides an overview of the RSerPool protocol suite, This document provides an overview of the RSerPool protocol suite,
specifically the Aggregate Server Access Protocol ASAP [2] and the specifically the Aggregate Server Access Protocol ASAP
Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to [I-D.ietf-rserpool-asap] and the Endpoint Handlespace Redundancy
the protocol specifications, there is a common parameter format Protocol ENRP [I-D.ietf-rserpool-enrp]. In addition to the protocol
specification COMMON [4] for both protocols, a definition of server specifications, there is a common parameter format specification
selection rules (pool policies) POLICIES [5], as well as a security COMMON [I-D.ietf-rserpool-common-param] for both protocols, a
threat analysis THREATS [6]. definition of server selection rules (pool policies) POLICIES
[I-D.ietf-rserpool-policies], as well as a security threat analysis
THREATS [I-D.ietf-rserpool-threats].
2. Aggregate Server Access Protocol (ASAP) Overview 2. Aggregate Server Access Protocol (ASAP) Overview
ASAP defines a straight-forward set of mechanisms necessary to ASAP defines a straight-forward set of mechanisms necessary to
support the creation and maintenance of pools of redundant servers. support the creation and maintenance of pools of redundant servers.
These mechanisms include: These mechanisms include:
o registration of a new server into a server pool o registration of a new server into a server pool
o deregistration of an existing server from a pool o deregistration of an existing server from a pool
skipping to change at page 6, line 35 skipping to change at page 6, line 44
o failover mechanisms for handling a server failure o failover mechanisms for handling a server failure
2.1. Pool Initialization 2.1. Pool Initialization
Pools come into existence when a PE registers the first instance of Pools come into existence when a PE registers the first instance of
the pool name with an ENRP server. They disappear when the last PE the pool name with an ENRP server. They disappear when the last PE
deregisters. In other words, the starting of the first PE on some deregisters. In other words, the starting of the first PE on some
machine causes the creation of the pool when the registration reaches machine causes the creation of the pool when the registration reaches
the ENRP server. the ENRP server.
It is assumed that information needed for RSerPool, such as the
address of an ENRP server to contact, is configured into the PE
beforehand. Methods of automating this configuration process are not
addressed at this time.
2.2. Pool Entity Registration 2.2. Pool Entity Registration
A new server joins an existing pool by sending a Registration message A new server joins an existing pool by sending a Registration message
via ASAP to an ENRP server, indicating the pool handle of the pool via ASAP to an ENRP server, indicating the pool handle of the pool
that it wishes to join, a PE identifier for itself (chosen randomly), that it wishes to join, a PE identifier for itself (chosen randomly),
information about its lifetime in the pool, and what transport information about its lifetime in the pool, and what transport
protocols and selection policy it supports. The ENRP server that it protocols and selection policy it supports. The ENRP server that it
first contacts is called its Home ENRP server, and maintains a list first contacts is called its Home ENRP server, and maintains a list
of subscriptions by the PE as well as performs periodic audits to of subscriptions by the PE as well as performs periodic audits to
confirm that the PE is still responsive. confirm that the PE is still responsive.
skipping to change at page 9, line 49 skipping to change at page 10, line 19
available on the client system, there are typically only three available on the client system, there are typically only three
modifications required to the application source code: modifications required to the application source code:
1. Instead of specifying the hostnames of primary, secondary, 1. Instead of specifying the hostnames of primary, secondary,
tertiary servers, etc., the application user specifies a pool tertiary servers, etc., the application user specifies a pool
handle. handle.
2. Instead of using a DNS based service (e.g. the Unix library 2. Instead of using a DNS based service (e.g. the Unix library
function getaddrinfo()) to translate from a hostname to an IP function getaddrinfo()) to translate from a hostname to an IP
address, the application will invoke an RSerPool service address, the application will invoke an RSerPool service
primitive GETPRIMARYSERVER that takes as input a pool handle, and primitive provisionally named GETPRIMARYSERVER that takes a pool
returns the IP address of the primary server. The application handle as input, and returns the IP address of the primary
then uses that IP address just as it would have used the IP server. The application then uses that IP address just as it
address returned by the DNS in the previous scenario. would have used the IP address returned by the DNS in the
previous scenario.
3. Without the use of additional RSerPool services, failure 3. Without the use of additional RSerPool services, failure
detection and failover procedures must be designed into each detection and failover procedures must be designed into each
application. However, when failure is detected on the primary application. However, when failure is detected on the primary
server, instead of invoking DNS translation again on the hostname server, instead of invoking DNS translation again on the hostname
of a secondary server, the application invokes the service of a secondary server, the application invokes a service
primitive GETNEXTSERVER, which performs two functions in a single primitive provisionally named GETNEXTSERVER, which performs two
operation. functions in a single operation.
1. First it indicates to the RSerPool layer the failure of the 1. First, it indicates to the RSerPool layer the failure of the
server returned by a previous GETPRIMARYSERVER or server returned by a previous GETPRIMARYSERVER or
GETNEXTSERVER call. GETNEXTSERVER call.
2. Second, it provides the IP address of the next server that 2. Second, it provides the IP address of the next server that
should be contacted, according to the best information should be contacted, according to the best information
available to the RSerPool layer at the present time (e.g. set available to the RSerPool layer at the present time (e.g. set
of available pool elements, pool element policy in effect for of available pool elements, pool element policy in effect for
the pool, etc.). the pool, etc.).
Note: at the time of this document, a full API for use with RSerPool
Protocols has not yet been defined.
For pool element ("server") applications where an ASAP implementation For pool element ("server") applications where an ASAP implementation
is available, two changes are required to the application source is available, two changes are required to the application source
code: code:
1. The server should invoke the REGISTER service primitive upon 1. The server should invoke the REGISTER service primitive upon
startup to add itself into the server pool using an appropriate startup to add itself into the server pool using an appropriate
pool handle. This also includes the address(es) protocol or pool handle. This also includes the address(es) protocol or
mapping id, port (if required by the mapping), and pooling mapping id, port (if required by the mapping), and pooling
policy(s). policy(s).
2. The server should invoke the DEREGISTER service primitive to 2. The server should invoke the DEREGISTER service primitive to
remove itself from the server pool when shutting down. remove itself from the server pool when shutting down.
When using these RSerPool services, RSerPool provides benefits that When using these RSerPool services, RSerPool provides benefits that
are limited (as compared to utilizing all services), but nevertheless are limited (as compared to utilizing all services), but nevertheless
quite useful as compared to not using RSerPool at all. First, the quite useful as compared to not using RSerPool at all. First, the
client user need only supply a single string, i.e. the pool handle, client user need only supply a single string, i.e. the pool handle,
rather than a list of servers. Second, the decision as to which rather than a list of servers. Second, the decision as to which
server is to be used can be determined dynamically by the server server is to be used can be determined dynamically by the server
selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP
[2]). Finally, when failures occur, these are reported to the pool [I-D.ietf-rserpool-asap]). Finally, when failures occur, these are
via signalling present in ASAP [2] and ENRP [3], other clients will reported to the pool via signalling present in ASAP
eventually know (once this failure is confirmed by other elements of [I-D.ietf-rserpool-asap] and ENRP [I-D.ietf-rserpool-enrp], other
the RSerPool architecture) that this server has failed. clients will eventually know (once this failure is confirmed by other
elements of the RSerPool architecture) that this server has failed.
4.2. Example Scenario using RSerPool Session Services 4.2. Example Scenario using RSerPool Session Services
When the full suite of RSerPool services is used, all communication When the full suite of RSerPool services is used, all communication
between the pool user and the pool element is mediated by the between the pool user and the pool element is mediated by the
RSerPool framework, including session establishment and teardown, and RSerPool framework, including session establishment and teardown, and
the sending and receiving of data. Accordingly, it is necessary to the sending and receiving of data. Accordingly, it is necessary to
modify the application to use the service primitives (i.e. the API) modify the application to use the service primitives (i.e. the API)
provided by RSerPool, rather than the transport layer primitives provided by RSerPool, rather than the transport layer primitives
provided by TCP, SCTP, or whatever transport protocol is being used. provided by TCP, SCTP, or whatever transport protocol is being used.
skipping to change at page 12, line 14 skipping to change at page 12, line 35
failure in the communication link between A and B, PE B can use failure in the communication link between A and B, PE B can use
the information in the business card to contact an equivalent PE the information in the business card to contact an equivalent PE
to PU A from pool X. to PU A from pool X.
Additionally, if the application at PU A is aware of some Additionally, if the application at PU A is aware of some
particular PEs of pool X that would be preferred for B to contact particular PEs of pool X that would be preferred for B to contact
in the event that A becomes unreachable from B, PU A can provide in the event that A becomes unreachable from B, PU A can provide
that list to the ASAP layer, and it will be included in A's that list to the ASAP layer, and it will be included in A's
business card (see Section 2.5.2). business card (see Section 2.5.2).
5. Security Considerations 5. Reference Implementation
The reference implementation of RSerPool is available at
[RSerPoolPage] and described in [Dre2006].
6. Security Considerations
This document does not identify security requirements beyond those This document does not identify security requirements beyond those
already documented in the ENRP and ASAP protocol specifications. A already documented in the ENRP and ASAP protocol specifications. A
security threat analysis of RSerPool is provided in THREATS [6]. security threat analysis of RSerPool is provided in THREATS
[I-D.ietf-rserpool-threats].
6. IANA Considerations 7. IANA Considerations
This document does not require additional IANA actions beyond those This document does not require additional IANA actions beyond those
already identified in the ENRP and ASAP protocol specifications. already identified in the ENRP and ASAP protocol specifications.
7. Acknowledgements 8. Acknowledgements
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall
Stewart, Scott Bradner, and many others for their invaluable Stewart, Scott Bradner, and many others for their invaluable
comments. comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
J., and M. Stillman, "Requirements for Reliable Server Pooling", Loughney, J., and M. Stillman, "Requirements for Reliable
RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[2] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [I-D.ietf-rserpool-asap]
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
(work in progress), November 2007. "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-19 (work in progress),
March 2008.
[3] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. [I-D.ietf-rserpool-enrp]
Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A.
draft-ietf-rserpool-enrp-18 (work in progress), November 2007. Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-19 (work in progress),
March 2008.
[4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [I-D.ietf-rserpool-common-param]
Server Access Protocol (ASAP) and Endpoint Handlespace Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Redundancy Protocol (ENRP) Parameters", "Aggregate Server Access Protocol (ASAP) and Endpoint
draft-ietf-rserpool-common-param-15 (work in progress), Handlespace Redundancy Protocol (ENRP) Parameters",
December 2007. draft-ietf-rserpool-common-param-16 (work in progress),
March 2008.
[5] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", [I-D.ietf-rserpool-policies]
draft-ietf-rserpool-policies-07 (work in progress), Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
November 2007. Policies", draft-ietf-rserpool-policies-08 (work in
progress), March 2008.
[6] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. [I-D.ietf-rserpool-threats]
Sengodan, "Threats Introduced by RSerPool and Requirements for Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Security in Response to Threats", Sengodan, "Threats Introduced by RSerPool and Requirements
draft-ietf-rserpool-threats-09 (work in progress), October 2007. for Security in Response to Threats",
draft-ietf-rserpool-threats-11 (work in progress),
April 2008.
8.2. Informative References 9.2. Informative References
[7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", [RSerPoolPage]
Dreibholz, T., "Thomas Dreibholz's RSerPool Page",
URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/. URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.
[8] Dreibholz, T., "Reliable Server Pooling -- Evaluation, [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation,
Optimization and Extension of a Novel IETF Architecture", Ph.D. Optimization and Extension of a Novel IETF Architecture",
Thesis University of Duisburg-Essen, Faculty of Economics, Ph.D. Thesis University of Duisburg-Essen, Faculty of
Institute for Computer Science and Business Information Systems, Economics, Institute for Computer Science and Business
URL: http://duepublico.uni-duisburg-essen.de/servlets/ Information Systems, URL: http://
DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/
Derivate-16326/Dre2006-final.pdf, March 2007.
Authors' Addresses Authors' Addresses
Peter Lei Peter Lei
Cisco Systems, Inc. Cisco Systems, Inc.
955 Happfield Dr. 955 Happfield Dr.
Arlington Heights, IL 60004 Arlington Heights, IL 60004
US US
Phone: +1 773 695-8201 Phone: +1 773 695-8201
skipping to change at page 15, line 44 skipping to change at line 669
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 36 change blocks. 
97 lines changed or deleted 131 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/