draft-ietf-rserpool-arch-10.txt   draft-ietf-rserpool-arch-11.txt 
Network Working Group M. Tuexen, Ed. Network Working Group M. Tuexen, Ed.
Internet-Draft Muenster Univ. of Applied Sciences Internet-Draft Muenster Univ. of Applied Sciences
Expires: January 8, 2006 Q. Xie Expires: September 30, 2006 Q. Xie
Motorola, Inc. Motorola, Inc.
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Systems, Inc. Cisco Systems, Inc.
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
A. Silverton A. Silverton
Motorola Labs Motorola Labs
July 7, 2005 March 29, 2006
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-10.txt draft-ietf-rserpool-arch-11.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 42 skipping to change at page 1, line 42
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 8, 2006. This Internet-Draft will expire on September 30, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes an architecture and protocols for the This document describes an architecture and protocols for the
management and operation of server pools supporting highly reliable management and operation of server pools supporting highly reliable
applications, and for client access mechanisms to a server pool. applications, and for client access mechanisms to a server pool.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem Space . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 5 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2.1 RSerPool Functional Components . . . . . . . . . . . . . . 5 2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 6
2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 5 2.1. RSerPool Functional Components . . . . . . . . . . . . . . 7
2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Pool Elements . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. ENRP Servers . . . . . . . . . . . . . . . . . . . . . 7
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 6 2.1.3. Pool Users . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6 2.2. RSerPool Protocol Overview . . . . . . . . . . . . . . . . 8
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 7 2.2.1. Endpoint Handlespace Redundancy Protocol . . . . . . . 8
2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7 2.2.2. Aggregate Server Access Protocol . . . . . . . . . . . 9
2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8 2.2.3. PU <-> ENRP Server Communication . . . . . . . . . . . 9
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8 2.2.4. PE <-> ENRP Server Communication . . . . . . . . . . . 10
2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9 2.2.5. PU <-> PE Communication . . . . . . . . . . . . . . . 10
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10 2.2.6. ENRP Server <-> ENRP Server Communication . . . . . . 11
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10 2.2.7. PE <->PE Communication . . . . . . . . . . . . . . . . 12
2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10 2.3. Failover Support . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1. Business Cards . . . . . . . . . . . . . . . . . . . . 12
2.4 Typical Interactions between RSerPool Components . . . . . 12 2.3.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 14
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Typical Interactions between RSerPool Components . . . . . 14
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 14 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 15 3.1. Two File Transfer Examples . . . . . . . . . . . . . . . . 16
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 16 3.1.1. The RSerPool Aware Client . . . . . . . . . . . . . . 17
3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 17 3.1.2. The RSerPool Unaware Client . . . . . . . . . . . . . 18
3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 18 3.2. Load Balancing Example . . . . . . . . . . . . . . . . . . 19
3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 19 3.3. Telephony Signaling Example . . . . . . . . . . . . . . . 20
3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 20 3.3.1. Decomposed GWC and GK Scenario . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 3.3.2. Collocated GWC and GK Scenario . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2 Informative References . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
1.1 Overview 1.1. The Problem Space
Fault tolerance is a difficult and challenging problem space. Most
of the solutions in this space involve an extensive effort on the
part of an application programmer and oftentimes the result is a
proprietary solution. There are a number of issues concerning
developers of fault tolerant applications including:
1. How to find a server that provides the service desired?
2. If the server that is providing me the service dies, how do I
find another one?
3. What type of redundancy model will I use, 2N or N+K?
4. How does a server providing a service share state with potential
peer servers in case of a failure?
5. How does a server assure that when it fails (or dies), the
clients will access the "best" server that is able to handle the
failure (or if you will take over for the departed server)?
6. From an operations and maintenance standpoint how do we add or
subtract capacity dynamically without reconfiguring our network?
A fault tolerant application needs to deal with these issues and many
more. Often an application is developed and then later, it is
realized that the application needs to be fault tolerant. The
response to this new requirement mandates either a hack or re-write
of the application.
So how can application writers solves these issues and makes it easy
for the application designer to add fault tolerance without hacking
or rewriting the application code? We use layering to solve this
problem. A session layer is inserted below the application layer to
provide a framework for fault tolerance. This removes some of the
complexity from the application writers hands thus freeing the
application writter to concentrate on the application. Note that not
all of the issues listed above can be solved by the session layer
framework alone, in particular the application will still need to
deal with state sharing, however the session layer framework will
also provide small tools when it can to help make even this job
easier for the application writer.
A second important point is that this layering no longer requires
each application to custom programmed for fault tolerance. By
running an application on top of the session layer fault tolerant
services, there is no longer the need to design and implement fault
tolerance one application at a time. There are several benefits to
this approach:
1. Time and cost savings for the developers of the application
2. Experts in the area have developed the session layer fault
tolerance mechanism
3. An application can be developed without a fault tolerant
requirement and later in the life cycle, if this requirement
emerges, it can be met with Rserpool without a costly redesign.
4. Rserpool provides a set of APIs and hooks for the application
developer to implement fault tolerance
5. Rserpool provides a simple building block to the application for
rudimentary state sharing.
The above summary is the overall goal of Rserpool. We strive to
remove the details and complexity of fault tolerance from the
application writer and, when the session layer cannot solve the issue
(such as state sharing), give the application writer some small
building blocks on which they can solve the problem with minimal
effort.
In this document you will be introduced to a set of concepts for
solving a number of these problems. Often times the document will
refer to a named element (e.g Pool User) in the architecture sending
or receiving a message. When seeing this, please note that this is
NOT the application sending or receiving the query, but the session
layer below. Envision if you will the application opening up a
special form of socket. This socket will allow reading and writing
of data, but underneath will have special properties that allow it to
send and receive additional messages when the upper layer user
requests some service such as sending a message or binding a name.
Note again, the goal of RSERPOOL is NOT to solve all of the problems,
but to instead solve a subset of the fault tolerant issues and at the
same time provide a toolkit of standard utilities that will help an
application solve the remaining items in an easier way.
1.2. Overview
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. These servers are called Pool the same application functionality. These servers are called Pool
Elements (PEs). PEs form the first class of entities in the RSerPool Elements (PEs). PEs form the first class of entities in the RSerPool
architecture. Multiple PEs in a server pool can be used to provide architecture. Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example. fault tolerance or load sharing, for example.
Each server pool is identified by a unique identifier which is simply Each server pool is identified by a unique identifier which is simply
a byte string, called the pool handle. This allows binary a byte string, called the pool handle. This allows binary
identifiers to be used. identifiers to be used.
skipping to change at page 3, line 48 skipping to change at page 5, line 39
o A port number associated with the transport protocol, e.g. SCTP, o A port number associated with the transport protocol, e.g. SCTP,
TCP or UDP. TCP or UDP.
Note that the RSerPool architecture supports both IPv4 and IPv6 Note that the RSerPool architecture supports both IPv4 and IPv6
addressing. addressing.
In each operational scope there must be at least one ENRP server. In each operational scope there must be at least one ENRP server.
All ENRP servers within the operational scope have knowledge of all All ENRP servers within the operational scope have knowledge of all
server pools within the operational scope. server pools within the operational scope.
RFC3237 [9] also requires that the ENRP servers should not resolve a RFC3237 [RFC3237] also requires that the ENRP servers should not
pool handle to a transport layer address of a PE which is not in resolve a pool handle to a transport layer address of a PE which is
operation. Therefore each PE is supervised by one specific ENRP not in operation. Therefore each PE is supervised by one specific
server, called the home ENRP server of that PE. If it detects that ENRP server, called the home ENRP server of that PE. If it detects
the PE is out of service all other ENRP servers are informed. that the PE is out of service all other ENRP servers are informed.
1.2 Terminology 1.3. Terminology
This document uses the following terms: This document uses the following terms:
Home ENRP Server: The ENRP server a Pool Element has registered with. Home ENRP Server: The ENRP server a Pool Element has registered with.
This ENRP server supervises the Pool Element. This ENRP server supervises the Pool Element.
Operational scope: The part of the network visible to pool users by a Operational scope: The part of the network visible to pool users by a
specific instance of the reliable server pooling protocols. specific instance of the reliable server pooling protocols.
Pool (or server pool): A collection of servers providing the same Pool (or server pool): A collection of servers providing the same
skipping to change at page 4, line 36 skipping to change at page 6, line 32
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 that Handle space: A cohesive structure of pool handles and relations that
may be queried by an internal or external agent. may be queried by an internal or external agent.
ENRP server: Entity which is responsible for managing and maintaining ENRP server: Entity which is responsible for managing and maintaining
the handle space within the RSerPool operational scope. the handle space within the RSerPool operational scope.
1.3 Abbreviations 1.4. Abbreviations
ASAP: Aggregate Server Access Protocol ASAP: Aggregate Server Access Protocol
ENRP: Endpoint haNdlespace Redundancy Protocol ENRP: Endpoint haNdlespace Redundancy Protocol
PE: Pool element PE: Pool element
PU: Pool user PU: Pool user
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
2. Reliable Server Pooling Architecture 2. Reliable Server Pooling Architecture
In this section, we define a reliable server pool architecture. In this section, we define a reliable server pool architecture.
2.1 RSerPool Functional Components 2.1. RSerPool Functional Components
There are three classes of entities in the RSerPool architecture: There are three classes of entities in the RSerPool architecture:
o Pool Elements (PEs). o Pool Elements (PEs).
o ENRP Servers. o ENRP Servers.
o Pool Users (PUs). o Pool Users (PUs).
2.1.1 Pool Elements 2.1.1. Pool Elements
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. These servers are called Pool the same application functionality. These servers are called Pool
Elements (PEs). PEs form the first class of entities in the RSerPool Elements (PEs). PEs form the first class of entities in the RSerPool
architecture. Multiple PEs in a server pool can be used to provide architecture. Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example. fault tolerance or load sharing.
Each server pool is identified by a unique identifier which is simply Each server pool is identified by a unique identifier which is simply
a byte string, called the pool handle. This allows binary a byte string, called the pool handle. This allows binary
identifiers to be used. identifiers to be used.
These pool handles are not valid in the whole internet but only in These pool handles are not valid in the whole internet but only in
smaller domains, called the operational scope. Furthermore, the smaller domains, called the operational scope. Furthermore, the
handle-space is assumed to be flat, so that multiple levels of query handle-space is assumed to be flat, so that multiple levels of query
are not necessary to resolve a pool handle. are not necessary to resolve a pool handle.
2.1.2 ENRP Servers 2.1.2. ENRP Servers
The second class of entities in the RSerPool architecture is the The second class of entities in the RSerPool architecture is the
class of ENRP servers. ENRP servers are designed to provide a fully class of ENRP servers. ENRP servers are designed to provide a fully
distributed fault-tolerant real-time translation service that maps a distributed fault-tolerant real-time translation service that maps a
pool handle to set of transport addresses pointing to a specific pool handle to set of transport addresses pointing to a specific
group of networked communication endpoints registered under that pool group of networked communication endpoints registered under that pool
handle. To be more precise, ENRP servers can resolve a pool handle handle. To be more precise, ENRP servers can resolve a pool handle
to a list of information which allows the PU to access a PE of the to a list of information which allows the PU to access a PE of the
server pool identified by the handle. This information includes: server pool identified by the handle. This information includes:
skipping to change at page 6, line 15 skipping to change at page 8, line 9
o A port number associated with the transport protocol, e.g. SCTP, o A port number associated with the transport protocol, e.g. SCTP,
TCP or UDP. TCP or UDP.
Note that the RSerPool architecture supports both IPv4 and IPv6 Note that the RSerPool architecture supports both IPv4 and IPv6
addressing. addressing.
In each operational scope there must be at least one ENRP server. In each operational scope there must be at least one ENRP server.
All ENRP servers within the operational scope have knowledge of all All ENRP servers within the operational scope have knowledge of all
server pools within the operational scope. server pools within the operational scope.
RFC3237 [9] also requires that the ENRP servers should not resolve a RFC3237 [RFC3237] also requires that the ENRP servers should not
pool handle to a transport layer address of a PE which is not in resolve a pool handle to a transport layer address of a PE which is
operation. Therefore each PE is supervised by one specific ENRP not in operation. Therefore each PE is supervised by one specific
server, called the home ENRP server of that PE. If it detects that ENRP server, called the home ENRP server of that PE. If it detects
the PE is out of service all other ENRP servers are informed. that the PE is out of service all other ENRP servers are informed.
2.1.3 Pool Users 2.1.3. Pool Users
A third class of entities in the architecture is the Pool User (PU) A third class of entities in the architecture is the Pool User (PU)
class, consisting of the clients being served by the PEs of a server class, consisting of the clients being served by the PEs of a server
pool. pool.
2.2 RSerPool Protocol Overview 2.2. RSerPool Protocol Overview
Based on the requirements in RFC3237 [9], the architecture of two new Based on the requirements in RFC3237 [RFC3237], the architecture of
protocols is introduced in this document: ENRP (Endpoint haNdlespace two new protocols is introduced in this document: ENRP (Endpoint
Redundancy Protocol) and ASAP (Aggregate Server Access Protocol). haNdlespace Redundancy Protocol) and ASAP (Aggregate Server Access
These are used because no existing protocols are suitable (see [3]). Protocol). These are used because no existing protocols are suitable
(for a detailed discussion of comparisons please see [I-D.ietf-
rserpool-comp]).
2.2.1 Endpoint Handlespace Redundancy Protocol 2.2.1. Endpoint Handlespace Redundancy Protocol
The ENRP servers use a protocol called Endpoint haNdlespace The ENRP servers use a protocol called Endpoint haNdlespace
Redundancy Protocol (ENRP) for communication with each other to Redundancy Protocol (ENRP) for communication with each other to
exchange information and updates about the server pools. exchange information and updates about the server pools.
ENRP guarantees the integrity of the RSerPool handlespace by ENRP guarantees the integrity of the RSerPool handlespace by
providing the means for an ENRP server to providing the means for an ENRP server to
o update its peers regarding changes to the handlspace caused by the o update its peers regarding changes to the handlspace caused by the
addition of a PE or the status change of an existing PE, addition of a PE or the status change of an existing PE,
o monitor the health of its peers, and, if necessary, take over the o monitor the health of its peers, and, if necessary, take over the
responsibility of being the home ENRP server for a set of PEs when responsibility of being the home ENRP server for a set of PEs when
the ENRP server previously responsible for those PEs has failed, the ENRP server previously responsible for those PEs has failed,
and and
o audit the handlespace for inconsistencies and synchronize the o audit the handlespace for inconsistencies and synchronize the
handlespace amongst its peers when inconsistencies have been handlespace amongst its peers when inconsistencies have been
found. found.
2.2.2 Aggregate Server Access Protocol 2.2.2. Aggregate Server Access Protocol
The PU wanting service from the pool uses the Aggregate Server Access The PU wanting service from the pool uses the Aggregate Server Access
Protocol (ASAP) to access members of the pool. Depending on the Protocol (ASAP) to access members of the pool. Depending on the
level of support desired by the application, use of ASAP may be level of support desired by the application, use of ASAP may be
limited to an initial query for an active PE, or ASAP may be used to limited to an initial query for an active PE, or ASAP may be used to
mediate all communication between the PU and PE, so that automatic mediate all communication between the PU and PE, so that automatic
failover from a failed PE to an alternate PE can be supported. failover from a failed PE to an alternate PE can be supported.
ASAP uses pool handles for addressing which isolates a logical ASAP uses pool handles for addressing which isolates a logical
communication endpoint from its IP address(es), thus effectively communication endpoint from its IP address(es), thus effectively
skipping to change at page 7, line 36 skipping to change at page 9, line 35
registers or deregisters itself by communicating with an ENRP server, registers or deregisters itself by communicating with an ENRP server,
which will normally be the home ENRP server. ASAP allows dynamic which will normally be the home ENRP server. ASAP allows dynamic
system scalability, allowing the pool membership to change at any system scalability, allowing the pool membership to change at any
time. time.
ASAP is used by a home ENRP server to supervise the PEs that have ASAP is used by a home ENRP server to supervise the PEs that have
registered with that ENRP server. If the home ENRP server detects registered with that ENRP server. If the home ENRP server detects
that a PE is out of service via ASAP, it notifies its peers using that a PE is out of service via ASAP, it notifies its peers using
ENRP as described previously. ENRP as described previously.
2.2.3 PU <-> ENRP Server Communication 2.2.3. PU <-> ENRP Server Communication
The PU <-> ENRP server communication is used for resolving pool The PU <-> ENRP server communication is used for resolving pool
handles and uses ASAP. The PU sends a pool handle to the ENRP server handles and uses ASAP. The PU sends a pool handle to the ENRP server
and gets back the information necessary for accessing a server in a and gets back the information necessary for accessing a server in a
server pool. server pool.
This communication can be based on SCTP or TCP if the PU does not This communication can be based on SCTP or TCP if the PU does not
support SCTP. The protocol stack for a PU is shown in Figure 1. support SCTP. The protocol stack for a PU is shown in Figure 1.
********** ************ ********** ************
skipping to change at page 8, line 22 skipping to change at page 10, line 22
+--------+ +--------+ +--------+ +--------+
|SCTP/TCP| |SCTP/TCP| |SCTP/TCP| |SCTP/TCP|
+--------+ +--------+ +--------+ +--------+
| IP | | IP | | IP | | IP |
+--------+ +--------+ +--------+ +--------+
Protocol stack between PU and ENRP server Protocol stack between PU and ENRP server
Figure 1 Figure 1
2.2.4 PE <-> ENRP Server Communication 2.2.4. PE <-> ENRP Server Communication
The PE <-> ENRP server communication is used for registration and The PE <-> ENRP server communication is used for registration and
deregistration of the PE in one or more pools and for the supervision deregistration of the PE in one or more pools and for the supervision
of the PE by the home ENRP server. This communication uses ASAP and of the PE by the home ENRP server. This communication uses ASAP and
is based on SCTP, the protocol stack is shown in the following is based on SCTP, the protocol stack is shown in the following
figure. figure.
******** ********** ******** **********
* PE * * ENRP * * PE * * ENRP *
* * * server * * * * server *
skipping to change at page 8, line 46 skipping to change at page 10, line 46
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PE and ENRP server Protocol stack between PE and ENRP server
Figure 2 Figure 2
2.2.5 PU <-> PE Communication 2.2.5. PU <-> PE Communication
The PU <-> PE communication can be divided into two parts: The PU <-> PE communication can be divided into two parts:
o control channel o control channel
o data channel o data channel
The data channel is used for the transmission of the upper layer The data channel is used for the transmission of the upper layer
data, the control channel is used to exchange RSerPool information. data, the control channel is used to exchange RSerPool information.
There are two supported scenarios: There are two supported scenarios:
o Multiplexed data and control channel. Both channels are o Multiplexed data and control channel. Both channels are
transported over one transport connection. This can either be an transported over one transport connection. This can either be an
SCTP association, with data and control channel are separated by SCTP association, with data and control channel are separated by
skipping to change at page 9, line 17 skipping to change at page 11, line 14
o data channel o data channel
The data channel is used for the transmission of the upper layer The data channel is used for the transmission of the upper layer
data, the control channel is used to exchange RSerPool information. data, the control channel is used to exchange RSerPool information.
There are two supported scenarios: There are two supported scenarios:
o Multiplexed data and control channel. Both channels are o Multiplexed data and control channel. Both channels are
transported over one transport connection. This can either be an transported over one transport connection. This can either be an
SCTP association, with data and control channel are separated by SCTP association, with data and control channel are separated by
the PPID, or an TCP connection, with data and control channel the PPID, or a TCP connection, with data and control channel being
being handled by a TCP mapping layer. handled by a TCP mapping layer.
o Data channel and no control channel. There is no restriction on o Data channel and no control channel. There is no restriction on
the transport protocol in this case. Note that certain enhanced the transport protocol in this case. Note that certain enhanced
failover services (e.g. business cards, state cookies, message failover services (e.g. business cards, state cookies, message
failover) are not available when this method is used. failover described in Section 2.3) are not available when this
method is used.
For a given pool, all PUs and PEs should make the same choice for the For a given pool, all PUs and PEs should make the same choice for the
style of interaction between each other: that is, for a given pool, style of interaction between each other: that is, for a given pool,
either all PEs and PUs in that pool use a multiplexed control/data either all PEs and PUs in that pool use a multiplexed control/data
channel for PU-PE communication, or all PEs and PUs in that pool use channel for PU-PE communication, or all PEs and PUs in that pool use
a data channel only for PU-PE communication. a data channel only for PU-PE communication.
When the multiplexed data and control channel is used, enhanced When the multiplexed data and control channel is used, enhanced
failover services may be provided, including: failover services may be provided, including:
o The PE can send a business card to the PU for providing o The PE can send a business card to the PU which provides
information to which other PE the PU should failover in case of a information as to which other PE the PU should failover to in case
failover. of a failure in the serving PE (a last will and testament so to
speak).
o The PE can send cookies to the PU. The PE would store only the o The PE can send cookies to the PU. The PU would store only the
last cookie and send it to the new PE in case of a failover. last cookie and send it to the new PE in case of a failover. This
provides a small hook that a PE can use to propagate small amounts
of state information upon failure.
See Section 2.3 for further details. See Section 2.3 for further details.
2.2.6 ENRP Server <-> ENRP Server Communication 2.2.6. ENRP Server <-> ENRP Server Communication
The communication between ENRP servers is used to share the knowledge The communication between ENRP servers is used to share the knowledge
about all server pools between all ENRP servers in an operational about all server pools between all ENRP servers in an operational
scope. scope.
For this communication ENRP over SCTP is used and the protocol stack For this communication ENRP over SCTP is used and the protocol stack
is shown in Figure 3. is shown in Figure 3.
********** ********** ********** **********
* ENRP * * ENRP * * ENRP * * ENRP *
skipping to change at page 10, line 26 skipping to change at page 12, line 26
+------+ +------+ +------+ +------+
Protocol stack between ENRP servers Protocol stack between ENRP servers
Figure 3 Figure 3
When a ENRP server initializes a UDP multicast message may be When a ENRP server initializes a UDP multicast message may be
transmitted for initial detection of other ENRP servers in the transmitted for initial detection of other ENRP servers in the
operational scope. The other ENRP servers send a response using a operational scope. The other ENRP servers send a response using a
unicast UDP message. unicast UDP message.
2.2.7 PE <-> PE Communication 2.2.7. PE <->PE Communication
This is a special case of the PU <-> PE communication. In this case This is a special case of the PU <-> PE communication. In this case
the PU is also a PE in a server pool, this means that one PE is the PU is also a PE in a server pool, this means that one PE is
acting like a PU during the communication setup. acting like a PU during the communication setup.
The difference between a pure PU <-> PE communication is that the PE The difference between a pure PU <-> PE communication is that the PE
acting as a PU can send the PE the information that it is actually a acting as a PU can send the PE the information that it is actually a
PE of a pool. This means that the pool handle is transferred via the PE of a pool. This means that the pool handle is transferred via the
control channel. See Section 2.3 for further details. control channel. See Section 2.3 for further details.
2.3 Failover Support 2.3. Failover Support
If the PU detects the failure of a PE it may fail over to a different If the PU detects the failure of a PE it may fail over to a different
PE. The selection to a new PE should be made such that most likely PE. The selection to a new PE should be made such that most likely
the new PE is not affected by the failed one. the new PE is not affected by the failed one.
There are some mechanisms provided by RSerPool to support the There are some mechanisms provided by RSerPool to support the
failover to a new PE. failover to a new PE.
2.3.1 Business Cards 2.3.1. Business Cards
A PE can send a business card to its peer containing its pool handle A PE can send a business card to its peer (PE or PU) containing its
and optionally information to which other PEs the peer should pool handle and optionally information to which other PEs the peer
failover. should failover. This gives a PE a form of last will and testament
that can be used to guide a PU to select the "next best" PE. This
determination may be made by the PE giving the business card in such
a way as to spread the load evenly across the server pool, or it may
be given with the knowledge that certain PE's will have a more
current set of state available to service the PU.
Presenting the pool handle is important in case of PE <-> PE Presenting the pool handle is important in case of PE <-> PE
communication in which one of the PEs acts as a PU for establishing communication in which one of the PEs acts as a PU for establishing
the communication. The pool handle of the PE which initiated the the communication. This can yield fault tolerance in both directions
communication may not be known by the peer. in cases where instead of client/ server, peer to peer concepts are
being used and both are members of separate server pools. Often
times in such a case, the PE selected does not know the name of the
PU's server pool, by providing that information both PE's will be
capable of failing over to an alternate.
Providing information to which PE the PU should failover can also be Providing information to which PE the PU should failover can also be
very important. Consider the scenario presented in the following very important. Consider the scenario presented in the following
figure. figure.
....................... .......................
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 1 | . . | PE 1 | .
. | | . . | | .
skipping to change at page 11, line 39 skipping to change at page 13, line 48
. . . .
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 3 | . . | PE 3 | .
. | | . . | | .
. +-------+ . . +-------+ .
....................... .......................
Two PUs accessing the same PE Two PUs accessing the same PE
Figure 4
PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2
share state but not PE 2 and PE 3. Using the business card of PE 2 share state but not PE 2 and PE 3. Using the business card of PE 2
it is possible for PE 2 to inform PU 1 that it should fail over to PE it is possible for PE 2 to inform PU 1 that it should fail over to PE
1 in case of a failure. 1 in case of a failure.
A slightly more complicated situation is if two pool users, PU 1 and A slightly more complicated situation is if two pool users, PU 1 and
PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE.
Then it is important that PU 1 and PU 2 fail over to the same PE. Then it is important that PU 1 and PU 2 fail over to the same PE.
This can be handled in a way such that PE 2 gives the same business This can be handled in a way such that PE 2 gives the same business
card to PU 1 and PU 2. card to PU 1 and PU 2.
2.3.2 Cookies 2.3.2. Cookies
Cookies may optionally be sent from the PE to the PU. The PU only Cookies may optionally be sent from the PE to the PU. The PU only
stores the last received cookie. In case of fail over the PU sends stores the last received cookie. In case of fail over the PU sends
this last received cookie to the new PE. This method provides a this last received cookie to the new PE. This method provides a
simple way of state sharing between the PEs. Please note that the simple way of state sharing between the PEs. Please note that the
old PE should sign the cookie and the receiving PE should verify the old PE should sign the cookie and the receiving PE should verify the
signature. For the PU, the cookie has no structure and is only signature. For the PU, the cookie has no structure and is only
stored and transmitted to the new PE. stored and transmitted to the new PE.
2.4 Typical Interactions between RSerPool Components 2.4. Typical Interactions between RSerPool Components
The following drawing shows the typical RSerPool components and their The following drawing shows the typical RSerPool components and their
possible interactions with each other: possible interactions with each other:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~ ~ operational scope ~
~ ......................... ......................... ~ ~ ......................... ......................... ~
~ . server pool 1 . . server pool 2 . ~ ~ . server pool 1 . . server pool 2 . ~
~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~
skipping to change at page 13, line 41 skipping to change at page 16, line 26
(OAM) functions. (OAM) functions.
(f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/
gateway enables clients ("other clients"), which are not RSerPool gateway enables clients ("other clients"), which are not RSerPool
aware, to access services provided by an RSerPool based server aware, to access services provided by an RSerPool based server
pool. It should be noted that these proxies/gateways may become a pool. It should be noted that these proxies/gateways may become a
single point of failure. single point of failure.
3. Examples 3. Examples
In this section the basic concepts behind ENRP and ASAP are motivated In this section the basic concepts behind ENRP and ASAP are
through examples. First, an RSerPool aware FTP server and Rserpool illustrated through examples. First, an RSerPool aware FTP server
aware clients are presented. Secondly, a scenario with an RSerPool and Rserpool aware clients are presented. Secondly, a scenario with
aware server with an Rserpool non-aware client shows how to an RSerPool aware server with an Rserpool non-aware client shows how
effectively use Rserpool with legacy clients or in a situation where to effectively use Rserpool with legacy clients or in a situation
exposure to the PU of the list of addresses associated with the where exposure to the PU of the list of addresses associated with the
handlespace is undesirable. This requirement has been expressed by handlespace is undesirable. This requirement has been expressed by
some telephony network operators who are concerned about potential some telephony network operators who are concerned about potential
network address mapping. The last two examples illustrate load network address mapping. The last two examples illustrate load
balancing and telephony scenarios. balancing and telephony scenarios.
In this section the basic concepts of ENRP and ASAP will be 3.1. Two File Transfer Examples
described. First an RSerPool aware FTP server is considered. The
interaction with an RSerPool aware and an non-aware client is given.
Finally, a telephony example is considered.
3.1 Two File Transfer Examples
In this section we present two file transfer examples using ENRP and In this section we present two file transfer examples using ENRP and
ASAP. We present two separate examples demonstrating an RSerPool- ASAP. We present two separate examples demonstrating an RSerPool-
aware client and an RSerPool-unaware client that is using a Proxy or aware client and an RSerPool-unaware client that is using a Proxy or
Gateway to perform the file transfer. In these examples we will use Gateway to perform the file transfer. In these examples we will use
a FTP RFC959 [5] model with some modifications. In the first example a FTP RFC959 [RFC0959] model with some modifications. In the first
(client is RSerPool-aware) we will modify FTP concepts so that the example (client is RSerPool-aware) we will modify FTP concepts so
file transfer takes place over SCTP. In the second example, we will that the file transfer takes place over SCTP. In the second example,
use TCP between the RSerPool-unaware client and the Proxy. The Proxy we will use TCP between the RSerPool-unaware client and the Proxy.
itself will use the modified FTP with RSerPool as illustrated in the The Proxy itself will use the modified FTP with RSerPool as
first example. illustrated in the first example.
Please note that in the example we do NOT follow FTP RFC959 [5] Please note that in the example we do NOT follow FTP RFC959 [RFC0959]
precisely but use FTP-like concepts and attempt to adhere to the precisely but use FTP-like concepts and attempt to adhere to the
basic FTP model. These examples use FTP for illustrative purposes. basic FTP model. These examples use FTP for illustrative purposes.
FTP was chosen since many of the basic concept are well known and FTP was chosen since many of the basic concept are well known and
should be familiar to readers. should be familiar to readers.
3.1.1 The RSerPool Aware Client 3.1.1. The RSerPool Aware Client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "file transfer pool" . ~ ~ . "file transfer pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ +-> |PE(1,A)| |PE(1,C)| . ~ ~ +-> |PE(1,A)| |PE(1,C)| . ~
~ |. +-------+ +-------+ . ~ ~ |. +-------+ +-------+ . ~
~ |. ^ ^ . ~ ~ |. ^ ^ . ~
~ |. +----------+ | . ~ ~ |. +----------+ | . ~
skipping to change at page 16, line 15 skipping to change at page 18, line 21
4. Suppose that during the file transfer transmission, PE(1,B) 4. Suppose that during the file transfer transmission, PE(1,B)
fails. If the PE's are sharing file transfer state, a fail-over fails. If the PE's are sharing file transfer state, a fail-over
to PE(1,A) could be initiated. PE(1,A) then continues the to PE(1,A) could be initiated. PE(1,A) then continues the
transfer until complete (see (d)). In parallel, a request from transfer until complete (see (d)). In parallel, a request from
PE(1,A) is made to the ENRP server to request a cache update for PE(1,A) is made to the ENRP server to request a cache update for
the server pool "File Transfer Pool". Furthermore, a report is the server pool "File Transfer Pool". Furthermore, a report is
generated that PE(1,B) is non-responsive. This would trigger generated that PE(1,B) is non-responsive. This would trigger
appropriate audits that may remove PE(1,B) from the pool if the appropriate audits that may remove PE(1,B) from the pool if the
ENRP server had not already detected the failure) (using (a)). ENRP server had not already detected the failure) (using (a)).
3.1.2 The RSerPool Unaware Client 3.1.2. The RSerPool Unaware Client
In this example we investigate the use of a Proxy server assuming the In this example we investigate the use of a Proxy server assuming the
same set of scenario as illustrated above. same set of scenario as illustrated above.
In this example the steps will occur: In this example the steps will occur:
1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp
protocol. The client sends the login request to the proxy (using protocol. The client sends the login request to the proxy (using
(e)). (e)).
skipping to change at page 17, line 38 skipping to change at page 19, line 38
~ | v | (a) ~ ~ | v | (a) ~
~ v v ~ ~ v v ~
~ ::::::::::::::::: (e)-> ***************** ~ ~ ::::::::::::::::: (e)-> ***************** ~
~ : FTP client :<------------->* proxy/gateway * ~ ~ : FTP client :<------------->* proxy/gateway * ~
~ ::::::::::::::::: (f) ***************** ~ ~ ::::::::::::::::: (f) ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RSerPool unaware client. Architecture for RSerPool unaware client.
Figure 7 Figure 7
3.2 Load Balancing Example 3.2. Load Balancing Example
This example is similar to the one above describing an RSerPool This example is similar to the one above describing an RSerPool
unaware client. In both examples the clients do not need to support unaware client. In both examples the clients do not need to support
the RSerPool protocol suite. the RSerPool protocol suite.
There are several servers in a pool and the traffic from clients is There are several servers in a pool and the traffic from clients is
distributed among them by a load balancer. The load balancer can distributed among them by a load balancer. The load balancer can
make use of load information provided by the servers for optimal load make use of load information provided by the servers for optimal load
distribution. distribution.
skipping to change at page 18, line 42 skipping to change at page 20, line 41
~ | | (a) ~ ~ | | (a) ~
~ v v ~ ~ v v ~
~ ::::::::::::::::: (b) ********************** ~ ~ ::::::::::::::::: (b) ********************** ~
~ : client :<----------->* load balancer (PU) * ~ ~ : client :<----------->* load balancer (PU) * ~
~ ::::::::::::::::: ********************** ~ ~ ::::::::::::::::: ********************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for an RSerPool based load balancer. Architecture for an RSerPool based load balancer.
Figure 8 Figure 8
3.3 Telephony Signaling Example 3.3. Telephony Signaling Example
This example shows the use of ASAP/RSerPool to support server pooling This example shows the use of ASAP/RSerPool to support server pooling
for high availability of a telephony application such as a Voice over for high availability of a telephony application such as a Voice over
IP Gateway Controller (GWC) and Gatekeeper services (GK). IP Gateway Controller (GWC) and Gatekeeper services (GK).
In this example, we show two different scenarios of deploying these In this example, we show two different scenarios of deploying these
services using RSerPool in order to illustrate the flexibility of the services using RSerPool in order to illustrate the flexibility of the
RSerPool architecture. RSerPool architecture.
3.3.1 Decomposed GWC and GK Scenario 3.3.1. Decomposed GWC and GK Scenario
In this scenario, both GWC and GK services are deployed as separate In this scenario, both GWC and GK services are deployed as separate
pools with some number of PEs, as shown in the following diagram. pools with some number of PEs, as shown in the following diagram.
Each of the pools will register their unique pool handle with the Each of the pools will register their unique pool handle with the
ENRP server. We also assume that there are a Signaling Gateway (SG) ENRP server. We also assume that there are a Signaling Gateway (SG)
and a Media Gateway (MG) present and both are RSerPool aware. and a Media Gateway (MG) present and both are RSerPool aware.
................... ...................
. gateway . . gateway .
. controller pool . . controller pool .
skipping to change at page 20, line 43 skipping to change at page 22, line 43
from the Gatekeeper, a timer expiration event will trigger the call from the Gatekeeper, a timer expiration event will trigger the call
state machine within PE(2, C) to resend the control message. The state machine within PE(2, C) to resend the control message. The
ASAP layer at PE(2, C) will then notice the failure of PE(1, B) ASAP layer at PE(2, C) will then notice the failure of PE(1, B)
through the endpoint unreachability detection by the transport through the endpoint unreachability detection by the transport
protocol beneath ASAP and automatically deliver the re-sent call protocol beneath ASAP and automatically deliver the re-sent call
control message to the alternate GK pool member PE(1, A). With control message to the alternate GK pool member PE(1, A). With
appropriate intra-pool call state sharing support, PE(1, A) will appropriate intra-pool call state sharing support, PE(1, A) will
correctly handle the call and reply to PE(2, C) and hence progress correctly handle the call and reply to PE(2, C) and hence progress
the call. the call.
3.3.2 Collocated GWC and GK Scenario 3.3.2. Collocated GWC and GK Scenario
In this scenario, the GWC and GK services are collocated (e.g., they In this scenario, the GWC and GK services are collocated (e.g., they
are implemented as a single process). In this case, one can form a are implemented as a single process). In this case, one can form a
pool that provides both GWC and GK services as shown in the figure pool that provides both GWC and GK services as shown in the figure
below. below.
The same sequence as described in 5.2.1 takes place, except that step The same sequence as described in 5.2.1 takes place, except that step
(4) now becomes internal to the PE(3,C). Again, we assume server C (4) now becomes internal to the PE(3,C). Again, we assume server C
is selected by SG. is selected by SG.
skipping to change at page 21, line 40 skipping to change at page 23, line 40
Deployment of Collocated GWC and GK. Deployment of Collocated GWC and GK.
Figure 10 Figure 10
4. Security Considerations 4. Security Considerations
The RSerPool protocol must allow us to secure the RSerPool The RSerPool protocol must allow us to secure the RSerPool
infrastructure. There are security and privacy issues that relate to infrastructure. There are security and privacy issues that relate to
the handle space, pool element registration and user queries of the the handle space, pool element registration and user queries of the
handle space. In [2] a complete threat analysis of RSerPool handle space. In [I-D.ietf-rserpool-threats] a complete threat
components is presented. analysis of RSerPool components is presented.
5. IANA Considerations 5. IANA Considerations
There are no actions needed. There are no actions needed.
6. Acknowledgements 6. Acknowledgments
The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie
Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen
Stillman, Werner Vogels and many others for their invaluable comments Stillman, Werner Vogels and many others for their invaluable comments
and suggestions. and suggestions.
7. References 7. References
7.1 Normative References 7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [I-D.ietf-rserpool-threats]
BCP 9, RFC 2026, October 1996. Stillman, M., "Threats Introduced by Rserpool and
Requirements for Security in response to Threats",
draft-ietf-rserpool-threats-05 (work in progress),
July 2005.
[2] Stillman, M., "Threats Introduced by Rserpool and Requirements [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
for Security in response to Threats", 3", BCP 9, RFC 2026, October 1996.
draft-ietf-rserpool-threats-04 (work in progress), January 2005.
[3] Loughney, J., "Comparison of Protocols for Reliable Server 7.2. Informative References
Pooling", draft-ietf-rserpool-comp-09 (work in progress),
February 2005.
7.2 Informative References [I-D.ietf-rserpool-comp]
Loughney, J., "Comparison of Protocols for Reliable Server
Pooling", draft-ietf-rserpool-comp-10 (work in progress),
July 2005.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, September 1981.
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
RFC 959, October 1985. STD 9, RFC 959, October 1985.
[6] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
Location Protocol, Version 2", RFC 2608, June 1999. "Service Location Protocol, Version 2", RFC 2608,
June 1999.
[7] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp,
Architecture for Signaling Transport", RFC 2719, October 1999. "Framework Architecture for Signaling Transport",
RFC 2719, October 1999.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
"Stream Control Transmission Protocol", RFC 2960, October 2000. Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[9] 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.
Authors' Addresses Authors' Addresses
Michael Tuexen (editor) Michael Tuexen (editor)
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
skipping to change at page 25, line 41 skipping to change at page 27, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 61 change blocks. 
145 lines changed or deleted 247 lines changed or added

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