draft-ietf-rserpool-comp-02.txt   draft-ietf-rserpool-comp-03.txt 
RserPool Working Group J. Loughney (ed.) RserPool Working Group J. Loughney (ed.)
INTERNET DRAFT M. Stillman INTERNET DRAFT M. Stillman
Nokia Nokia
M. Tuexen
Siemens AG
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
L. Ong
Ciena
Expires May 21, 2001 November 21, 2001 Issued: March 1, 2002
Expires: September 1, 2002
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
<draft-ietf-rserpool-comp-02.txt> <draft-ietf-rserpool-comp-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of [RFC2026]. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference 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/1id-abstracts.html
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
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2002. All Rights Reserved.
Abstract Abstract
This document compares some related protocols, which overlap the This document compares protocols that may be applicable for Reliable
Reliable Server Pooling problem space. This document discusses the Server Pooling problem space. This document discusses the usage and
applicability of these protocols for Reliable Server Pooling. It applicability of these protocols for Reliable Server Pooling.
intends to show why these protocols are not sufficient to accomplish
the task of reliable server pooling.
Abstract.............................................................1 Abstract..............................................................1
1 Introduction.......................................................3 1 Introduction........................................................3
1.1 Overview........................................................3 1.1 Overview........................................................3
1.2 Terminology.....................................................3 1.2 Terminology.....................................................3
2 Relation to Other Solutions........................................4 2 Relation to Other Solutions.........................................4
2.1 CORBA...........................................................4 2.1 CORBA...........................................................4
2.2 DNS.............................................................5 2.2 DNS.............................................................4
2.2.1 Requirements.................................................5 2.2.1 Requirements.................................................5
2.2.2 Technical Issues.............................................5 2.2.2 Technical Issues.............................................5
2.2.3 Name/Address Resolution......................................7 2.2.3 Name/Address Resolution......................................7
2.3 Service Location Protocol (SLP..................................8 2.3 Service Location Protocol (SLP).................................8
2.3.1 mSLP.........................................................9 2.3.1 Introduction.................................................8
3 Comparison Against Requirements....................................9 2.3.2 What to Use..................................................8
4 Security Concerns..................................................10 2.3.3 Summary......................................................9
5 Acknowledgements...................................................10 3 ASAP and ENRP......................................................10
6 References.........................................................10 3.1 ASAP...........................................................10
7 Authors' Addresses.................................................11 3.2 ENRP...........................................................11
Full Copyright Statement.............................................12 4 Comparison Against Requirements....................................11
5 Security Concerns..................................................12
6 Acknowledgements...................................................12
7 References.........................................................12
8 Authors' Addresses.................................................13
Full Copyright Statement.............................................13
1 Introduction 1 Introduction
1.1 Overview 1.1 Overview
In creating a solution to provide reliable server pools [RSER-ARCH], In creating a solution to provide reliable server pools [RSER-ARCH],
there are a number of existing protocols, which appear to have there are a number of existing protocols, which appear to have
similar properties as to what RSerPool is trying to accomplish. similar properties as to what RSerPool is trying to accomplish.
This document discusses why these protocols are not sufficient to This document discusses the applicability of these protocols in
meet the requirements of Reliable Server Pooling [RSER-REQ]. meeting the requirements of Reliable Server Pooling [RFC3237].
This study does not intend to be complete, rather intends to This study does not intend to be complete, rather intends to
highlight several protocols which working group members have highlight several protocols which working group members have
suggested. suggested.
1.2 Terminology 1.2 Terminology
This document uses the following terms: This document uses the following terms:
Operation scope - The part of the network visible to pool users Operation Scope The part of the network visible to pool users by
by a specific instance of the reliable server a specific instance of the reliable server
pooling protocols. pooling protocols.
Pool - A collection of servers providing the same Pool A collection of servers providing the same
application functionality. Also called a Server application functionality. Also called a Server
Pool. Pool.
Pool handle - A logical pointer to a pool. Each server pool Pool Handle A logical pointer to a pool. Each server pool
will be identifiable in the operation scope of will be identifiable in the operation scope of
the system by a unique pool handle or "name". the system by a unique pool handle or "name".
Also called a Pool Name. Also called a Pool Name.
Pool element - A server entity having registered to a pool. Pool Element A server entity having registered to a pool.
Pool User - A server pool user. Pool User A server pool user.
Pool Element Handle - A logical pointer to a particular pool element Pool Element Handle A logical pointer to a particular pool element
in a pool, consisting of the name of the pool in a pool, consisting of the name of the pool
and a destination transport address of the pool and a destination transport address of the pool
element. Also called an Endpoint Handle. element. Also called an Endpoint Handle.
Name Space - A cohesive structure of pool names and Name Space A cohesive structure of pool names and relations
relations that may be queried by an internal or that may be queried by an internal or external
external agent. agent.
Name Server - Entity which the responsible for managing and Name Server Entity which the responsible for managing and
maintaining the name space within the RSerPool maintaining the name space within the RSerPool
operation scope. operation scope.
1.3 Abbreviations 1.3 Abbreviations
DA: Directory Agent in SLP. DA: Directory Agent in SLP.
DPE: Distributed Processing Environment DPE: Distributed Processing Environment
CORBA: Common Object Request Broker Architecture. CORBA: Common Object Request Broker Architecture.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
SA: Service Agent in SLP. SA: Service Agent in SLP.
SLP: Service Location Protocol. SLP: Service Location Protocol.
UA: User Agent in SLP. UA: User Agent in SLP.
2 Relation to Other Solutions 2 Relation to Other Solutions
This section is intended to discuss the applicability of some This section is intended to discuss the applicability of some
existing solutions with regards to Reliable Server Pooling existing solutions with regards to Reliable Server Pooling
requirements [RSER-REQ]. The protocols discussed have been requirements [RFC3237]. The protocols discussed have been suggested
suggested as possibly overlapping with the problems space of as possibly overlapping with the problems space of RSerPool.
RSerPool.
2.1 CORBA 2.1 CORBA
Often referred to as a Distributed Processing Environment (DPE), Often referred to as a Distributed Processing Environment (DPE),
CORBA was mainly designed to provide location transparency for CORBA was mainly designed to provide location transparency for
distributed applications. However, the following limitations may distributed applications. CORBA's distribution model encourages an
exist when applying CORBA to the design of real time fault-tolerant object-based view, i.e., each communication endpoint is normally an
system: object.
CORBA has not been focused on high availability. The recent
development of a high availability version of CORBA by OMG may be a
step in the right direction towards improving this situation.
Nevertheless, the maturity, implementability, and real-time
performance of the design is yet to be proven.
CORBA's distribution model encourages an object-based view, i.e.,
each communication endpoint is normally an object. This level of
granularity is likely to be somewhat inefficient for designing real-
time fault-tolerant applications.
CORBA, in general, has a large signature that makes the use of it a CORBA has a number of variants, such as fault-tolerant CORBA, Real-
challenge in real-time environments. Small devices with limited time CORBA, etc. CORBA has been used in a number of situations, for
memory and CPU resource (e.g., H.323 or SIP terminals) will find example, Real-time CORBA has been usedin fighter aircraft and weapon
CORBA hard to fit in. systems. Additionally, CORBA has been implentented in a wide range
of devices, from attack submarines to Palm Pilots - the MICO open
source ORB has been ported to the Palm Pilot, and the client-only
application is 45 KB.
CORBA has lacked easily usable support for the asynchronous Currently, the applicability of CORBA is unclear, and interaction
communication model, and this may be an issue in many applications. with other Internet protocols, such as AAA, IPsec and Ipv6 may be
An improved API for asynchronous communication has been added to the problematic.
CORBA standards recently, but many, if not most, CORBA
implementations do not yet support it. There is as yet insufficient
user experience with it to make conclusions regarding this feature's
usability.
2.2 DNS 2.2 DNS
This section will answer the question why DNS is not appropriate as This section will answer the question why DNS is not appropriate as
the sole solution for RSerPool. In addition, it highlights specific the sole solution for RSerPool. In addition, it highlights specific
technical differences between RSerPool and DNS. technical differences between RSerPool and DNS.
During the 49th IETF December 13, 2000 plenary meeting Randy Bush During the 49th IETF December 13, 2000 plenary meeting Randy Bush
presented a talk entitled "The DNS Today: Are we overloading the presented a talk entitled "The DNS Today: Are we overloading the
Saddlebags on an Old Horse?" This talk underlined the issue that DNS Saddlebags on an Old Horse?" This talk underlined the issue that DNS
skipping to change at page 5, line 28 skipping to change at page 5, line 15
to break down entirely due to a growing number of feature to break down entirely due to a growing number of feature
enhancements. enhancements.
One requirement to any solution proposed by RSerPool would be to One requirement to any solution proposed by RSerPool would be to
avoid any additional requirements for DNS in order to support avoid any additional requirements for DNS in order to support
Reliable Server Pooling. Interworking between DNS and RSerPool will Reliable Server Pooling. Interworking between DNS and RSerPool will
be considered so that additional burdens to DNS will not be added. be considered so that additional burdens to DNS will not be added.
2.2.1 Requirements 2.2.1 Requirements
Any solution for RSerPool should meet certain requirements [RSER- Any solution for RSerPool should meet certain requirements
REQ]. These requirements are related to DNS. [RFC3237]. These requirements are related to DNS.
Servers should be able to register to (become PEs) and deregister Servers should be able to register to (become PEs) and deregister
from a server pool transparently without an interruption in from a server pool transparently without an interruption in
service. service.
The RSerPool mechanisms must be able to support different server The RSerPool mechanisms must be able to support different server
selection mechanisms. These are called server pool policies. selection mechanisms. These are called server pool policies.
The RSerPool architecture must be able to detect server failure The RSerPool architecture must be able to detect server failure
quickly and be able to perform failover without service quickly and be able to perform failover without service
skipping to change at page 8, line 15 skipping to change at page 8, line 4
The technical requirement for RSerPool name/address resolution is The technical requirement for RSerPool name/address resolution is
that given a name (or pool handle), find a server pool associated that given a name (or pool handle), find a server pool associated
with this name and return a list of transport addresses (i.e., IP with this name and return a list of transport addresses (i.e., IP
addresses plus port numbers) for reaching a set of currently addresses plus port numbers) for reaching a set of currently
operational servers inside the pool. In other words, in RSerPool we operational servers inside the pool. In other words, in RSerPool we
have the following mapping: have the following mapping:
Name a handle to a server pool, which is often distributed Name a handle to a server pool, which is often distributed
across multiple host machines across multiple host machines
Address IP addresses and port numbers to reach a set of Address IP addresses and port numbers to reach a set of
functionally identical (software) server entities. functionally identical (software) server entities.
2.3 Service Location Protocol (SLP 2.3 Service Location Protocol (SLP)
2.3.1 Introduction
SLP is comprised of three components: User Agents (UA), Service SLP is comprised of three components: User Agents (UA), Service
Agents (SA) and Directory Agents (DA). User agents work on the Agents (SA) and Directory Agents (DA). User agents work on the
user's behalf to contact a service. The UA retrieves service user's behalf to contact a service. The UA retrieves service
information from service agents or directory agents. A service agent information from service agents or directory agents. A service agent
works on behalf of one or more services to advertise services. A works on behalf of one or more services to advertise services. A
directory agent collects service advertisements. directory agent collects service advertisements.
The directory agent of SLP functions simply acts as a cache and is The directory agent of SLP functions simply acts as a cache and is
passive in this regard. The directory agent is optional and SLP can passive in this regard. The directory agent is optional and SLP can
function without it. It is incumbent upon the servers to update the function without it. It is incumbent upon the servers to update the
cache as necessary by reregistering. The directory server is not cache as necessary by reregistering. The directory server is not
required in small networks as the user agents can contact service required in small networks as the user agents can contact service
agents directly using multicast. Unicast queries to SAs are possible agents directly using multicast. Unicast queries to SAs are possible
subsequent to the UA having discovered them. User agents are subsequent to the UA having discovered them. User agents are
encouraged to locate a directory at regular intervals if they can't encouraged to locate a directory at regular intervals if they can't
find one initially, otherwise they can detect DAs by listening find one initially, otherwise they can detect DAs by listening
passively for DA advertisements. passively for DA advertisements.
2.3.2 What to Use
Figure 1 shows how SLP might be realized to provide ENR services:
Pool User (PU) ENR Service Pool Endpoint (PE)
+-------------+ +---------+
| APPLICATION | | SERVICE |
+-+-------------+-+ +---+---------+---+
|ASAP/RSERPOOL API| <--------------------> |ASAP/RSERPOOL API|
+-+----+--------+-+ +----------+ +-+--------+----+-+
| | SLP UA | <----> | SLP DA | <----> | SLP SA | |
| +----+---+ +------+---+ +--------+ |
|SCTP |UDP| | SCTP |UDP| |UDP| SCTP |
+---------+---+ +------+---+ +---+---------+
/ \
/ mesh \
+----+ +----+
| DA |--------| DA |
+----+ +----+
Figure 1: RSERPOOL entities employing SLP for ENR services
Notes:
* Each box constitutes a host (running a PU, PE or ENR server
'stack'), though one host could support more than one of these
functions.
* As far as the Application is concerned, it is using a framework
for exchanging messages with services reliably.
* As far as the Service is concerned, it is making itself available
to a reliable server pool by interacting with the framework API.
* The ASAP/RSERPOOL API obtains endpoint name resolution data in a
timely and robust manner and uses it to determine how to route
PU requests to PEs.
* The ENR service function is performed using SLP. The PU employs
a SLP UA to obtain information from a SLP DA.
* The ENR service function is performed using SLP. The PU employs
a SLP UA to obtain information from a SLP DA.
* The PE employs a SLP SA to register information with a SLP DA.
As the SLP SA is 'mesh-enhanced,' it only registers with one DA
of this type (as long as it detects that this DA is alive &
responsive & returns 'OK' results).
* The SLP DA is part of a mesh. It will forward PE state to other
DAs in the mesh. For example, it will forward the registrations
the SLP SA made on behalf of the PE on right of Figure 1.
* SCTP is used for communication between entities. Multicast UDP
is used by SLP entities for active and passive discovery. While
the RSERPOOL architecture cannot rely upon multicast mechanisms,
it can profit from them when these are present in the network
SLPv2 will be needed, but SLPv2 alone does not fulfill RSERPOOL
update requirements for timeliness. This is achieved through mesh-
enhancements to the Service Location Protocol (mSLP) [MSLP].
These enhancements make it possible for SAs to know of only a subset
of all DAs. Mesh-enhanced SAs need only forward their registrations
to only one mesh-enhanced DA. The mesh takes care of forwarding the
message to the other DAs.
2.3.3 Summary
The most fundamental difference between SLP and RSerPool is that SLP The most fundamental difference between SLP and RSerPool is that SLP
is service-oriented while RSerPool is communication-oriented. More is service-oriented while RSerPool is communication-oriented. More
specifically, what SLP provides to its user is a mapping function specifically, what SLP provides to its user is a mapping function
from a name of a service to the location of the service provider, in from a name of a service to the location of the service provider, in
the form of a URL string. The availability of the service provider the form of a URL string. The availability of the service provider
is outside of the scope of SLP. How a service is accessable can be is outside of the scope of SLP. How a service is accessable can be
described by the SLP attribute list associated with the service URL. described by the SLP attribute list associated with the service URL.
SLP is essentially a discovery protocol, not a transport protocol. SLP is essentially a discovery protocol, not a transport protocol.
Therefore, the granularity of SLP operation is at application Therefore, the granularity of SLP operation is at application
service level. service level.
In contrast, RSerPool provides to its user is a mapping function In contrast, RSerPool provides to its user is a mapping function
from a communication destination name to a set of routable and from a communication destination name to a set of routable and
reachable transport addresses that leads to a group of distributed reachable transport addresses that leads to a group of distributed
software server entities registered under that name that software server entities registered under that name that
collectively represent the named communication destination. With collectively represent the named communication destination. With
respect to SLP, this information could be represented in SLP respect to SLP, this information could be represented in SLP
attributes. RserPool, however, also has the responsibility of attributes. RserPool, however, also has the responsibility of
reliably delivering a user message to one of these server entities. reliably delivering a user message to one of these server entities.
What service(s) a group of servers are providing at the application Currently, mSLP would need changes, for example it was designed to
level or whether the group is just a component of an application scale to ~10 DAs not ~100 DAs. Additionally, SLP is currently to
service provider is out of the scope of RSerPool. In other words, run on top of UDP and TCP. If SCTP support was needed, some
the granularity of RSerPool operation is at communication server additional specification work would be needed.
entity level.
Moreover, RSerPool requires a distributed fault-tolerance and real- SLP security makes no attempt to address the confidentiality of data
time translation services. SLP does not state either of these as transmitted between SLP agents. To properly address this concern,
design requirements and thus does not attempt to fulfill them. In SLP agents would need to establish secure communication with each
addition, SLP defines optional security features, which support other. This would be achieved through the use of IPSec
authentication and integrity. SLP requires IPSec to fully meet the Encapsulating Security Payload.
Security Requirements of RserPool.
The SLP directory agent does not support fault tolerance or Server discovery, however, is something which SLP does well, and if
robustness in contrast to the name servers, which do support it. used for RserPool, this would be useful.
The name servers also monitor the state of the servers, which are
registered in the pool, but the SLP directory agents do not perform
this function.
SLP relies on multicast for some functionality and in RSerPool 3 ASAP and ENRP
multicast is optional.
In summary, SLP meets some of the requirements needed for the name ASAP [ASAP] and ENRP [ENRP] are being developed the RserPool working
service portion of RSerPool, but would require modifications to group. Even though they are separate protocols, they are designed
fully support the requirements for the name service. SLP does not to work together.
address the transport of user messages.
2.3.1 mSLP 3.1 ASAP
SLP alone does not fulfill RSERPOOL update requirements for ASAP uses a name-based addressing model which isolates a logical
timeliness. This is achieved through mesh-enhancements to the communication endpoint from its IP address(es), thus effectively
Service Location Protocol (mSLP) [MSLP]. eliminating the binding between the communication endpoint and its
physical IP address(es) which normally constitutes a single point of
failure. In addition, ASAP defines each logical communication
destination as a pool, providing full transparent support for
server-pooling and load sharing. It also allows dynamic system
scalability - members of a server pool can be added or removed at
any time without interrupting the service.
These enhancements make it possible for SAs to know of only a subset ASAP is not designed to scale Internet wide. It uses a flat, peer-
of all DAs. Mesh-enhanced SAs need only forward their registrations to-peer addressing model. Other protocols, such as DNS could be
to only one mesh-enhanced DA. The mesh takes care of forwarding the used to bridge the pools of servers. It uses a name-based
message to the other DAs. addressing model to logically isolate the communication endpoint
from its IP address(es). If multiple endpoints register under a the
same name, a server pool is effectively created. ASAP is used to
select one Pool Element, based on a number of criteria, such as load
sharing. ASAP monitors the reacability of the Pool Elements in
order to provide fault tolerance.
3 Comparison Against Requirements 3.2 ENRP
ENRP defines procedures and message formats of a distributed fault-
tolerant registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information. It allows
Pool Elements to be dynamically added, updated and removed from
service. There are protocol mechanisms for detecting and removing
unreachable Pool Elements.
4 Comparison Against Requirements
This section attempts to create a comparison table to compare the This section attempts to create a comparison table to compare the
protocols which have been suggested as applicable to the RserPool protocols which have been suggested as applicable to the RserPool
architecture. architecture.
| CORBA | DNS | SLP | ASAP | ENRP | | CORBA | DNS | SLP | ASAP | ENRP |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Robustness | Y | Y | Y | Y | Y | Robustness | Y | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Failover Support | Y | P | P | Y | Y | Failover Support | Y | P | P | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Communication Model | N | P | Y | Y | Y | Communication Model | N | P | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Processing Power | N | Y | Y | Y | Y | Processing Power | N | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Support of RSerPool | N | Y | N | N | N | Support of RSerPool | N | Y | N | N | N |
Unaware Clients | | | | | | Unaware Clients | | | | | |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Registering and | N | P | P | Y | Y | Registering and | N | P | P | Y | Y |
Deregistering | | | | | | Deregistering | | | | | |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Naming | Y | Y | Y | Y | Y | Naming | Y | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Name Resolution only to | Y | N | Y | Y | Y | Name Resolution only to | Y | N | Y | Y | Y |
Active Elements | | | | | | Active Elements | | | | | |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Server Selection Policies | Y | P | P | P | P | Server Selection Policies | Y | P | P | P | P |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Timing Requirements and | N | N | Y | Y | Y | Timing Requirements and | P | N | Y | Y | Y |
Scaling | | | | | | Scaling | | | | | |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Scalability | N | Y | Y | Y | Y | Scalability | N | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Security - General | N | P | P | P | P | Security - General | Y | P | P | P | P |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Security - Name Space | N | P | P | P | P | Security - Name Space | P | P | P | P | P |
Services | | | | | | Services | | | | | |
-----------------------------+-------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+------+
Y = Yes, meets requirement Y = Yes, meets requirement
P = Partially meets requirement P = Partially meets requirement
N = No, does not meet requirement N = No, does not meet requirement
N/A = Not applicable N/A = Not applicable
4 Security Concerns 5 Security Concerns
This type of non-protocol document does not directly affect the This type of non-protocol document does not directly affect the
security of the Internet. security of the Internet.
5 Acknowledgements 6 Acknowledgements
The authors would like to thank Bernard Aboba, Erik Guttman, Matt The authors would like to thank Bernard Aboba, Erik Guttman, Matt
Holdrege, Christopher Ross and Werner Vogels for their invaluable Holdrege, Lyndon Ong, Christopher Ross, Micheal Tuexen and Werner
comments and suggestions. Vogels for their invaluable comments and suggestions.
7 References
6 References
[ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access [ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access
Protocol (ASAP)", draft-ietf-rserpool-asap-00.txt, Protocol (ASAP)", Work in progress.
June, 2001. A work in progress.
[ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution [ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-00.txt, Protocol (ENRP)", Work inprogress.
June, 2001. A work inprogress.
[MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location [MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location
Protocol", draft-zhao-slp-da-interaction-12.txt, Protocol" Work in progress.
July, 2001. A work in progress.
[RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server [RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server
Pooling" <draft-ietf-rserpool-arch-00.txt>, Work in Pooling" Work in Progress.
Progress, April 2001.
[RSER-REQ] Tuexen, M. et al., "Requirements for Reliable Server [RFC3237] Tuexen, M. et al., "Requirements for Reliable Server
Pooling" <draft-ietf-rserpool-reqts-03.txt>, Work in Pooling", RFC3237, January 2002.
Progress, May 2001.
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC [RFC793] J. B. Postel, "Transmission Control Protocol", RFC
793, September 1981. 793, September 1981.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol
(FTP)", RFC 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process - [RFC2026] S. Bradner, "The Internet Standards Process -
Revision 3", RFC 2026, October 1996. Revision 3", RFC 2026, October 1996.
[RFC2608] E. Guttman et al., "Service Location Protocol, [RFC2608] E. Guttman et al., "Service Location Protocol,
Version 2", RFC 2608, June 1999. Version 2", RFC 2608, June 1999.
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [RFC2719] L. Ong et al., "Framework Architecture for Signaling
Transport", RFC 2719, October 1999. Transport", RFC 2719, October 1999.
[RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the [RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February location of services (DNS SRV)", RFC 2782, February
2000. 2000.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [RFC2960] R. R. Stewart et al., "Stream Control Transmission
Protocol", RFC 2960, November 2000. Protocol", RFC 2960, November 2000.
7 Authors' Addresses 8 Authors' Addresses
John Loughney John Loughney
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: john.loughney@nokia.com Email: john.loughney@nokia.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Michael Tuexen
Siemens AG
ICN WN CS SE 51
D-81359 Munich
Germany
Email: Michael.Tuexen@icn.siemens.de
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, Il 60004 Arlington Heights, Il 60004
USA USA
Email: qxie1@email.mot.com Email: qxie1@email.mot.com
Randall Stewart Randall Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
24 Burning Bush Trail 24 Burning Bush Trail
Crystal Lake, Il 60012 Crystal Lake, Il 60012
USA USA
Email: rrs@cisco.com Email: rrs@cisco.com
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
USA
Email: lyong@ciena.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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