draft-ietf-rserpool-comp-05.txt   draft-ietf-rserpool-comp-06.txt 
RserPool Working Group J. Loughney (ed.) Network Working Group J. Loughney, Ed.
INTERNET DRAFT M. Stillman Internet-Draft M. Stillman
Nokia Expires: December 29, 2003 Nokia
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
A. Silverton
Issued: November 4, 2002 Motorola
Expires: May 4, 2003 June 30, 2003
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
<draft-ietf-rserpool-comp-05.txt> draft-ietf-rserpool-comp-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is in full conformance with
of Section 10 of RFC2026. all provisions 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
other groups may also distribute working documents as Internet- 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
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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://
http://www.ietf.org/1id-abstracts.html 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.
Distribution of this memo is unlimited. This Internet-Draft will expire on December 29, 2003.
Copyright (C) The Internet Society 2002. All Rights Reserved. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document compares protocols that may be applicable for the This document compares protocols that may be applicable for the
Reliable Server Pooling problem space. This document discusses the Reliable Server Pooling problem space. This document discusses the
usage and applicability of these protocols for the Reliable Server usage and applicability of these protocols for the Reliable Server
Pooling architecture. Pooling architecture.
Abstract.............................................................1 Table of Contents
1 Introduction.......................................................3
1.1 Overview........................................................3
1.2 Terminology.....................................................3
2 Relation to Other Solutions........................................4
2.1 CORBA...........................................................4
2.2 DNS.............................................................4
2.2.1 Requirements.................................................5
2.2.2 Technical Issues.............................................5
2.2.3 Name/Address Resolution......................................7
2.3 Service Location Protocol (SLP).................................8
2.3.1 Introduction.................................................8
2.3.2 What to Use..................................................8
2.3.3 Summary......................................................9
3 ASAP and ENRP.....................................................10
3.1 ASAP...........................................................10
3.2 ENRP...........................................................11
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3
2. Relation to Other Solutions . . . . . . . . . . . . . . . . 4
2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Service Location Protocol (SLP) . . . . . . . . . . . . . . 9
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 What to Use . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Summary of SLP Issues . . . . . . . . . . . . . . . . . . . 11
3. L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Security Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Security Issues . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. ASAP and ENRP . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 ASAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 ENRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Comparison Against Requirements . . . . . . . . . . . . . . 17
6. Security Concerns . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . 18
Non-Normative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 21
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 [1], there
there are a number of existing protocols, which appear to have are a number of existing protocols, which appear to have similar
similar properties as to what RSerPool is trying to accomplish. properties as to what RSERPOOL is trying to accomplish. This document
This document discusses the applicability of these protocols in discusses the applicability of these protocols in meeting the
meeting the requirements of Reliable Server Pooling [RFC3237]. requirements of Reliable Server Pooling [2].
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 by Operation Scope: The part of the network visible to pool users by a
a specific instance of the reliable server specific instance of the reliable server pooling protocols.
pooling protocols.
Pool A collection of servers providing the same
application functionality. Also called a Server
Pool.
Pool Handle A logical pointer to a pool. Each server pool Pool: A collection of servers providing the same application
will be identifiable in the operation scope of functionality. Also called a Server Pool.
the system by a unique pool handle or "name".
Also called a Pool Name.
Pool Element A server entity having registered to a pool. Pool Handle: A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique pool
handle or "name". Also called a Pool Name.
Pool User A server pool user. Pool Element: A server entity having registered to a pool.
Pool Element Handle A logical pointer to a particular pool element Pool User: A server pool user.
in a pool, consisting of the name of the pool
and a destination transport address of the pool
element. Also called an Endpoint Handle.
Name Space A cohesive structure of pool names and relations Name Space: A cohesive structure of pool names and relations that may
that may be queried by an internal or external be queried by an internal or 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.
OMG: Object Management Group OMG: Object Management Group.
PE: Pool element ORB: Object Request Broker.
PU: Pool user PE: Pool Element.
PU: Pool User.
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 TTL: Time to live in DNS.
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 [RFC3237]. The protocols discussed have been suggested requirements [2]. The protocols discussed have been suggested as
as possibly overlapping with the problems space of RSerPool. possibly overlapping with the problems space of 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. CORBA's distribution model encourages an distributed applications. CORBA's distribution model encourages an
object-based view, i.e., each communication endpoint is normally an object-based view, i.e., each communication endpoint is normally an
object. object.
CORBA has a number of variants, such as fault-tolerant CORBA, Real- CORBA has a number of variants, such as fault-tolerant CORBA, Real-
time CORBA, etc. CORBA has been used in a number of situations, for time CORBA, etc. CORBA has been used in a number of situations, for
example, Real-time CORBA has been used in fighter aircraft and example, Real-time CORBA has been used in fighter aircraft and weapon
weapon systems. Additionally, CORBA has been implentented in a wide systems. Additionally, CORBA has been implemented in a wide range of
range of devices, from attack submarines to Palm Pilots - the MICO devices, from attack submarines to Palm Pilots - the MICO open source
open source ORB has been ported to the Palm Pilot, and the client- ORB has been ported to the Palm Pilot, and the client- only
only application is 45 KB in size. application is 45 KB in size.
Currently, the applicability of CORBA for reliable server pooling is CORBA, a DPE, sits above the communications layer that is the purview
unclear, and interaction with other Internet protocols, such as AAA, of most IETF work, specifically, RSERPOOL. In a conceptual model of
IPsec and IPv6 may be problematic. a middleware stack for highly available clustering, CORBA is
considered an application service and not a messaging or clustering
service. A distributed application may utilize a CORBA ORB for
location transparency at the application layer, and the ORB may in
turn utilize RSERPOOL for its communications layer. For example, a
real-time CORBA ORB such as Tau, would benefit from having its
interfaces extended to take advantage of RSERPOOL concepts.
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
is currently overloaded with extraneous tasks and has the potential is currently overloaded with extraneous tasks and has the potential
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 RSERPOOL and DNS are protocols with very different objectives.
RSERPOOL is designed to provide a range of services up to the point
of relieving an application of the overhead of maintaining a session
with an active server. DNS was not intended to handle such a range
of functions. DNS may, however, be able to handle some of the lower
range of RSERPOOL functionality.
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 Any solution for RSERPOOL should meet certain requirements [2].
[RFC3237]. These requirements are related to DNS. These requirements are related to DNS.
"Servers should be able to register to (become PEs) and "Servers should be able to register to (become PEs) and deregister
deregister from a server pool transparently without an from a server pool transparently without an interruption in
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
interruption. interruption.
Server pools are identified by pool handles. These pool handles Server pools are identified by pool handles. These pool handles
are only valid inside the operation scope. Interoperability are only valid inside the operation scope. Interoperability
between different namespaces has to be provided by other between different namespaces has to be provided by other
mechanisms." mechanisms."
2.2.2 Technical Issues 2.2.2 Technical Issues
This section discusses the relationship between DNS and the This section discusses the relationship between DNS and the
requirements for RserPool. requirements for RserPool.
2.2.2.1 Host Resolver Problems 2.2.2.1 Host Resolver Problems
A major issue that prevents the use of DNS as part of the RSerPool A major issue that prevents the use of DNS as part of the RSERPOOL
solution the issue is the architecture of host resolvers. These are solution is the architecture of host resolvers. These are stub
stub resolvers - which means that they require their local DNS resolvers - which means that they require their local DNS servers to
servers to do recursion for them. do recursion for them.
In turn, this implies that setting TTL low or 0 will dramatically In turn, this implies that setting TTL low or 0 will dramatically
increase the load not only on the authoritative DNS servers - but increase the load not only on the authoritative DNS servers - but
also on these third party servers. also on these third party servers.
A secondary effect of this is that the authoritative DNS will not A secondary effect of this is that the authoritative DNS will not
know the IP address of the DNS client - only the IP address of the know the IP address of the DNS client - only the IP address of the
local DNS. This affects the ability to do global load balancing local DNS. This affects the ability to do global load balancing
correctly. correctly.
There is no way to get around these issues unless you require all There is no way to get around these issues unless one requires all
hosts to be full resolvers. Putting full resolvers on newer hosts hosts to be full resolvers. Putting full resolvers on newer hosts
isn't sufficient because the issues would still exist for all the isn't sufficient because the issues would still exist for all the
legacy systems, which will form the bulk of the host population for legacy systems, which will form the bulk of the host population for
years to come. The solution is not to use third party servers. years to come. The solution is not to use third party servers.
Additionally, if the client can contact the server directly, then Additionally, if the client can contact the server directly, then the
the server knows the real IP address of the client. Since there is server knows the real IP address of the client. Since there is no
no third party involved, the caching TTL can be set as low as third party involved, the caching TTL can be set as low as desired
desired (even to zero). That will increase load on the server, but (even to zero). That will increase load on the server, but nowhere
nowhere else. else.
Finally, DNS is based on a recursion. This recursion presents Finally, DNS is based on a recursion. This recursion presents certain
certain difficulties for RSerPool. Even if a host resolver is not a difficulties for RSERPOOL. Even if a host resolver is not a stub
stub resolver, it has to go to another full resolver where 2 resolver, it has to go to another full resolver where 2 possibilities
possibilities exists: either the mapping name-IP address is found or exists: either the mapping name-IP address is found or it has to do
it has to do another recursive resolution of the name, staring from another recursive resolution of the name, staring from that
that intermediate resolver, until there is a cache hit in one of the intermediate resolver, until there is a cache hit in one of the
intermediate resolvers or it is resolved by its root resolver (or intermediate resolvers or it is resolved by its root resolver (or
home DNS server). home DNS server).
This process of recursion means that there is no end-to-end This process of recursion means that there is no end-to-end
communication between the host and its server where the name-to-IP communication between the host and its server where the name-to-IP
mapping resides. That also means that a lot of timers are running in mapping resides. That also means that a lot of timers are running in
intermediate systems. Any updating of the transient status of the intermediate systems. Any updating of the transient status of the
pool element or of the pool may need to be propagated through the pool element or of the pool may need to be propagated through the
DNS. DNS.
2.2.2.2 Dynamic Registration 2.2.2.2 Dynamic Registration
Registration / de-registration of servers is needed. It can be done Registration / de-registration of servers is needed. It can be done
with DNS by NOTIFY/IXFR. However, frequent updates and replication with DNS by NOTIFY/IXFR. However, frequent updates and replication
are incompatible. This is not a DNS problem per se, but it has an are incompatible. This is not a DNS problem per se, but it has an
effect on DNS as it is deployed. effect on DNS as it is deployed.
RSerPool MUST allow software server entities to register themselves RSERPOOL MUST allow software server entities (i.e., PEs) to register
with a name server dynamically. They can also de-register themselves themselves with a name server dynamically. They can also de-register
for purposes of preventative maintenance or can be de-registered by themselves for purposes of preventative maintenance or can be
a name server that believes the server entity is no longer de-registered by a name server that believes the server entity is no
operational. This is a dynamic approach, which is coordinated longer operational. This is a dynamic approach, which is coordinated
through servers in the pool and among RSerPool name servers. through servers in the pool and among RSERPOOL name servers.
2.2.2.3 Load Balancing 2.2.2.3 Load Balancing
RFC 2782 itself points out some of the limitations of using DNS SRV RFC 2782 [3] itself points out some of the limitations of using DNS
for load balancing between servers. SRV for load balancing between servers.
Weight is only intended for static, not dynamic, server Weight is only intended for static, not dynamic, server selection.
selection. Using SRV weight for dynamic server selection would Using SRV weight for dynamic server selection would require
require assigning unreasonably short TTLs to the SRV RRs, assigning unreasonably short TTLs to the SRV RRs, which would
which would limit the usefulness of the DNS caching mechanism, limit the usefulness of the DNS caching mechanism, thus increasing
thus increasing overall network load and decreasing overall overall network load and decreasing overall reliability.
reliability.
Based on this, DNS can only really support stochastic load Based on this, DNS can only really support stochastic load balancing,
balancing, redirecting clients to servers randomly as various caches redirecting clients to servers randomly as various caches in various
in various resolvers expire at random (although small) intervals. resolvers expire at random (although small) intervals. DNS offers
DNS offers excellent network scalability but poor control over load excellent network scalability but poor control over load balance.
balance.
As mentioned previously, the issue of doing DNS-based dynamic load As mentioned previously, the issue of doing DNS-based dynamic load
balancing on short time scales will have impacts on third parties, balancing on short time scales will have impacts on third parties,
due to the presence of stub resolvers. due to the presence of stub resolvers.
2.2.2.4 Heartbeating & Status Monitoring 2.2.2.4 Heartbeating & Status Monitoring
DNS does not incorporate an application layer heartbeat. DNS does not incorporate an application layer heartbeat. Heartbeating
Heartbeating would dramatically boost traffic levels, and given the would dramatically boost traffic levels, and given the unavoidable
unavoidable third party dependencies of DNS, the resulting loading third party dependencies of DNS, the resulting loading would be
would be unacceptable. It is passive in the sense that it does not unacceptable. It is passive in the sense that it does not monitor or
monitor or store information on the state of the host such as store information on the state of the host such as whether the host
whether the host is up or down or what kind of load it is currently is up or down or what kind of load it is currently experiencing.
experiencing.
RSerPool SHOULD monitor the state of each server entity on various RSERPOOL SHOULD monitor the state of each server entity on various
hosts on a continual basis and can collect several state variables hosts on a continual basis and can collect several state variables
including up/down state and current load. If a server is no longer including up/down state and current load. If a server is no longer
operational, eventually it will be dropped from the list of operational, eventually it will be dropped from the list of available
available servers maintained by the name server, so that subsequent servers maintained by the name server, so that subsequent application
application name queries will not resolve to this server address. name queries will not resolve to this server address.
2.2.3 Name/Address Resolution 2.2.2.5 Name/Address Resolution Granularity
The technical requirement for DNS name/address resolution is that The technical requirement for DNS name/address resolution is
given a name, find a host associated with this name and return its basically that given a name, find a host associated with this name
IP address(es). In other words, in DNS we have the following and return its IP address(es). In other words, in DNS we have the
mapping: following mapping:
Name a host machine Name ; a host machine
Address(es) IP address(es) to reach a (hardware) host machine -to-
The technical requirement for RSerPool name/address resolution is Address ; IP address(es) to reach the host machine
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 address(es) plus port number) 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
across multiple host machines
Address IP addresses and port numbers to reach a set of -to-
functionally identical (software) server entities.
Address ; transport address(es) (i.e., IP plus port number) to
; reach a set of functionally identical server entities
; (software processes). These software entities can be
; distributed across multiple host machines.
Without significant extensions, the current DNS would have difficulty
to achieve this type of name mapping.
2.2.2.6 Lack of Support for Real-time Fault Detection and Recovery
Even if we could somehow overcome the aforementioned shortcomings of
DNS in terms of providing the name resolution service to RSERPOOL, we
still would not have the support for real-time fault detection and
recovery (i.e., failover) which is a key requirement in RSERPOOL.
To meet this requirement, a mechanism would need to be in place that
would detect the unreachability of a message recipient and re-direct
or re-route a user message to an alternate recipient in the same
destination pool in real-time or semi-real-time. DNS currently
contains no such mechanism.
2.2.2.7 Lack of Support for Redundancy Models
Server pooling as defined in RSERPOOL requires support for different
redundancy arrangements or models depending on the needs of the
specific application. Commonly used models in practice includes N+M,
N-active, etc. These models basically define how a PE is going to
behave when another PE in the same pool fails and it is often
critical for the application to have full control over this behavior
of each PE in the pool. Without major extensions, it seems difficult
for DNS to support such redundancy models.
2.3 Service Location Protocol (SLP) 2.3 Service Location Protocol (SLP)
2.3.1 Introduction 2.3.1 Introduction
SLP is comprised of three components: User Agents (UA), Service SLP [4] 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
user's behalf to contact a service. The UA retrieves service behalf to contact a service. The UA retrieves service information
information from service agents or directory agents. A service agent from service agents or directory agents. A service agent works on
works on behalf of one or more services to advertise services. A behalf of one or more services to advertise services. A directory
directory agent collects service advertisements. agent collects service advertisements.
The directory agent of SLP simply acts as a cache and is passive in The directory agent of SLP simply acts as a cache and is passive in
this regard. The directory agent is optional and SLP can function this regard. The directory agent is optional and SLP can function
without it. It is incumbent upon the servers to update the cache as without it. It is incumbent upon the servers to update the cache as
necessary by reregistering. The directory server is not required in necessary by reregistering. The directory server is not required in
small networks as the user agents can contact service agents small networks as the user agents can contact service agents directly
directly using multicast. Unicast queries to SAs are possible using multicast. Unicast queries to SAs are possible subsequent to
subsequent to the UA having discovered them. User agents are the UA having discovered them. User agents are encouraged to locate a
encouraged to locate a directory at regular intervals if they can't directory at regular intervals if they can't find one initially,
find one initially, otherwise they can detect DAs by listening otherwise they can detect DAs by listening passively for DA
passively for DA advertisements. advertisements.
2.3.2 What to Use 2.3.2 What to Use
Figure 1 shows how SLP might be realized to provide ENR services: Figure 1 shows how SLP might be realized to provide RSERPOOL endpoint
name resolution (ENR) services:
Pool User (PU) ENR Service Pool Endpoint (PE) Pool User (PU) ENR Service Pool Endpoint (PE)
+-------------+ +---------+ +-------------+ +---------+
| APPLICATION | | SERVICE | | APPLICATION | | SERVICE |
+-+-------------+-+ +---+---------+---+ +-+-------------+-+ +---+---------+---+
|ASAP/RSERPOOL API| <--------------------> |ASAP/RSERPOOL API| |ASAP/RSERPOOL API| <--------------------> |ASAP/RSERPOOL API|
+-+----+--------+-+ +----------+ +-+--------+----+-+ +-+----+--------+-+ +----------+ +-+--------+----+-+
| | SLP UA | <----> | SLP DA | <----> | SLP SA | | | | SLP UA | <----> | SLP DA | <----> | SLP SA | |
| +----+---+ +------+---+ +--------+ | | +----+---+ +------+---+ +--------+ |
|SCTP |UDP| | SCTP |UDP| |UDP| SCTP | |SCTP |UDP| | SCTP |UDP| |UDP| SCTP |
skipping to change at page 9, line 5 skipping to change at page 10, line 14
/ \ / \
/ mesh \ / mesh \
+----+ +----+ +----+ +----+
| DA |--------| DA | | DA |--------| DA |
+----+ +----+ +----+ +----+
Figure 1: RSERPOOL entities employing SLP for ENR services Figure 1: RSERPOOL entities employing SLP for ENR services
Notes: Notes:
* Each box constitutes a host (running a PU, PE or ENR server o Each box constitutes a host (running a PU, PE or ENR server
'stack'), though one host could support more than one of these 'stack'), though one host could support more than one of these
functions. functions.
* As far as the Application is concerned, it is using a framework o As far as the Application is concerned, it is using a framework
for exchanging messages with services reliably. for exchanging messages with services reliably.
* As far as the Service is concerned, it is making itself available o As far as the Service is concerned, it is making itself available
to a reliable server pool by interacting with the framework API. to a reliable server pool by interacting with the framework API.
* The ASAP/RSERPOOL API obtains endpoint name resolution data in a o The ASAP/RSERPOOL API obtains endpoint name resolution data in a
timely and robust manner and uses it to determine how to route timely and robust manner and uses it to determine how to route PU
PU requests to PEs. requests to PEs.
* The ENR service function is performed using SLP. The PU employs o The ENR service function is performed using SLP. The PU employs a
a SLP UA to obtain information from a SLP DA. SLP UA to obtain information from a SLP DA.
* The ENR service function is performed using SLP. The PU employs o The ENR service function is performed using SLP. The PU employs a
a SLP UA to obtain information from a SLP DA. SLP UA to obtain information from a SLP DA.
* The PE employs a SLP SA to register information with a SLP DA. o The PE employs a SLP SA to register information with a SLP DA. As
As the SLP SA is 'mesh-enhanced,' it only registers with one DA the SLP SA is 'mesh-enhanced,' it only registers with one DA of
of this type (as long as it detects that this DA is alive & this type (as long as it detects that this DA is alive &
responsive & returns 'OK' results). responsive & returns 'OK' results).
* The SLP DA is part of a mesh. It will forward PE state to other o 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 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. the SLP SA made on behalf of the PE on right of Figure 1.
* SCTP is used for communication between entities. Multicast UDP o SCTP is used for communication between entities. Multicast UDP is
is used by SLP entities for active and passive discovery. While used by SLP entities for active and passive discovery. While the
the RSERPOOL architecture cannot rely upon multicast mechanisms, RSERPOOL architecture cannot rely upon multicast mechanisms, it
it can profit from them when these are present in the network can profit from them when these are present in the network
SLPv2 will be needed, but SLPv2 alone does not fulfill RSERPOOL SLPv2 will be needed, but SLPv2 alone does not fulfill RSERPOOL
update requirements for timeliness. This is achieved through mesh- update requirements for timeliness. This is achieved through mesh-
enhancements to the Service Location Protocol (mSLP) [MSLP]. enhancements to the Service Location Protocol (mSLP) [5].
These enhancements make it possible for SAs to know of only a subset These enhancements make it possible for SAs to know of only a subset
of all DAs. Mesh-enhanced SAs need only forward their registrations of all DAs. Mesh-enhanced SAs need only forward their registrations
to only one mesh-enhanced DA. The mesh takes care of forwarding the to only one mesh-enhanced DA. The mesh takes care of forwarding the
message to the other DAs. message to the other DAs.
2.3.3 Summary 2.3.3 Summary of SLP Issues
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
is outside of the scope of SLP. How a service is accessable can be outside of the scope of SLP. How a service is accessible 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
service level. level.
In contrast, RSerPool provides to its user is a mapping function In contrast, RSERPOOL provides to its user is a mapping function from
from a communication destination name to a set of routable and a communication destination name to a set of routable and reachable
reachable transport addresses that leads to a group of distributed transport addresses that leads to a group of distributed software
software server entities registered under that name that server entities registered under that name that collectively
collectively represent the named communication destination. With represent the named communication destination. With respect to SLP,
respect to SLP, this information could be represented in SLP this information could be represented in SLP attributes. RSERPOOL,
attributes. RserPool, however, also has the responsibility of however, also has the responsibility of reliably delivering a user
reliably delivering a user message to one of these server entities. message to one of these server entities.
Currently, mSLP would need changes, for example it was designed to Currently, mSLP would need changes, for example it was designed to
scale to ~10 DAs not ~100 DAs. Additionally, SLP is currently scale to ~10 DAs not ~100 DAs. Additionally, SLP is currently
designed to run on top of UDP and TCP. If SCTP support is needed, designed to run on top of UDP and TCP. If SCTP support is needed,
some additional specification work would be needed. some additional specification work would be needed.
SLP security makes no attempt to address the confidentiality of data SLP security makes no attempt to address the confidentiality of data
transmitted between SLP agents. To properly address this concern, transmitted between SLP agents. To properly address this concern, SLP
SLP agents would need to establish secure communication with each agents would need to establish secure communication with each other.
other. This would be achieved through the use of IPSec This would be achieved through the use of IPSec Encapsulating
Encapsulating Security Payload. Security Payload.
Server discovery, however, is something which SLP does well, and if Server discovery, however, is something which SLP does well, and if
used for RserPool, this would be useful. used for RSERPOOL, this would be useful.
3 ASAP and ENRP Other difficulties and shortcomings for using SLP to implement
RSERPOOL include:
ASAP [ASAP] and ENRP [ENRP] are being developed the RserPool working o Due to the fact that the resolution granularity of SLP is at the
group. Even though they are separate protocols, they are designed service level, it relies on a syntax rich scheme to define
to work together. services (e.g., printers > color printers > color printers with
720+ resolution, etc). This implies that SLP implementation will
need to perform syntax analysis, filtering, and parsing when a
name is queried, and will need to dynamically search its name
space to identify which entities are to be included in the
response to a specific query. This type of complicated processing
and searching for each query may severely limit the performance of
SLP in a real-time world which is a key requirement of RSERPOOL.
3.1 ASAP o Without major extensions, SLP will not be able to provide a
solution for real-time or semi-real-time fault detection and
recovery. This is partially because SLP is a discovery protocol,
not a communication protocol.
3. L4/L7 Switching
3.1 Introduction
This section discusses L4 and L7 switching techniques and their
relation to the RSERPOOL architecture [2]. Since these technologies
are highly proprietary, it is difficult to detail these techniques in
a thorough manner.
In both cases, the deployment of these techniques is dependent upon
the type of switching equipment deployed and breaks the end-to-end
communication model required by RSERPOOL. These devices provide a
specialized service intended to address a few network challenges,
e.g., web caching and web cache load balancing, firewall load
balancing, web server scaling, and streaming media load balancing.
They are not robust methods for providing network reliability or
highly reliable and highly available location transparent server
clustering as required by RSERPOOL.
The following sections will provide an overview and example of each
technique and an accounting for key RSERPOOL architectural
requirements not met. See Section 5 for a more detailed accounting
of requirements compliance.
3.2 L4 Switching
L4 devices make switching decisions based on the TCP or UDP port
numbers of the packet in transit.
3.2.1 Example
Web caching is an example of L4 switching. The topology requires the
introduction of an L4 capable switch in series with an existing
network connection and L2/L3 switch. This is of particular use to
web cache configurations where, for example, all traffic destined for
port 80 (HTTP) could be redirected to a web cache or distributed by
the switch across a number of web caches to achieve load balancing.
The L4 switch can react to a failed cache and cease to send traffic
to that device by automatically detecting that it is unreachable.
This is all accomplished without any configuration on a client
device.
An equally compelling use for this type of switching is load
balancing across firewalls. If the firewalls are employing stateful
packet inspection for TCP connections, then the L4 switch must track
which packets belong to which connection and see that all such
packets are switched to the same firewall.
An L4 switch is incapable of differentiating between packets
containing cacheable objects and non-cacheable objects, therefore, L7
devices, which look inside packets, are deployed where such
determinations must be made. In general, anytime that knowledge of
the application level data is required to make a switching decision,
L7 devices must be deployed.
3.2.2 Technical Issues
The more general behavior of L4 switching, redirecting traffic based
on destination UDP or TCP ports, is similar to a function provided by
RSERPOOL. Where it differs in this regard is that L4 switching is
dependent upon the network infrastructure and not peer-to-peer or
end-to-end as required by RSERPOOL.
L4 switching meets the requirement of forwarding to active elements
only, as a switch will detect unreachable PEs, but does not provide
for the necessary registration and deregistration of PEs or
resolution by name. L4 switches require the manual configuration of
access control lists to determine switching behavior. This is
achieved in RSERPOOL by more flexible means and without any
dependence on specialized network equipment.
Most of the extended features of ASAP [6] and ENRP [7] are not met by
a device employing L4 switching techniques.
3.2.3 Security Issues
It is not clear that L4 switching introduces any new security
concerns. In fact, in a two-port security model, where secure
RSERPOOL services are provided on one port, and similar, but insecure
services, on another, L4 switching could be used to direct traffic to
a secure or insecure PE or ENRP server as necessary.
3.3 L7 Switching
As previously mentioned, L7 switching was developed to differentiate
between the type of objects being directed by network switches. In
the L4 case, the devices cannot differentiate between the types of
data, only the destination of the packets containing that data. L7
switches look at the application layer of a packet in transit to
determine what type of object is contained within.
3.3.1 Example
For an L7 switch to do this, it is necessary to intercept data
midstream. In the case of HTTP, which is carried over TCP, the L7
switch must break the TCP handshake when a new request is made to the
server attached to the switch. This process begins during the
initialization of the TCP connection and before the higher level
protocol, i.e., HTTP, sends its request. The switch acts as the
server during the TCP SYN, SYN ACK, ACK handshake between that server
and the client. Once the HTTP request is issued by the client and
the switch decides that this is non-cacheable data that should be
directed to the server as opposed to a web cache, the L7 switch sets
up a second connection with the actual server through an additional
three-way handshake. The switch will forward the client's request to
the server and for the duration of this connection, must graft the
client-switch and switch-server connections together by modifying IP
addresses and TCP ports on the fly. Cacheable data is handled
similarly, but is redirected to groups of web caches as opposed to
the web servers.
3.3.2 Technical Issues
It is not clear that L7 switching adds anything, as a general
mechanism, beyond what is provided by L4 switching, towards providing
a sufficient RSERPOOL architecture.
While this technique can be very valuable as a means to scale web
servers, it is apparent that it takes a significant amount of work on
the part of the switch to realize these gains. The nature of this
method also requires that for each type of application traffic
handled, a custom software module must be written and added to the
switch operating system. It is not known, due to the proprietary
nature of these devices, if this can be done by the end user and/or
added dynamically to deployed systems.
It may be possible to write custom modules for a switch, given the
appropriate access to hardware and software, to provide some type of
enhanced reliability in a controlled network. But, it is the aim of
RSERPOOL to provide a general mechanism that is widely deployable and
highly portable. L7 switching requires a significant amount of
development to customize each of the endpoint switches to which PUs
and PEs may be attached.
Also of concern is the compatibility of SCTP with L7 techniques. The
interception and subsequent splicing of sessions may nullify some of
the inherent benefits of SCTP and certainly add additional and
unnecessary complexity and latency to the transport layer. ASAP and
ENRP along with the multi-homing and stream based behavior of SCTP
provide more benefit than custom L7 switching would provide and at a
significantly lower cost.
3.3.3 Security Issues
While L7 switches do provide some robustness to TCP-based DoS attacks
directed at servers by requiring a proper three-way handshake, and
they can be used to redirect encrypted traffic to certain servers
better capable of processing that traffic, they may break the
security model of RSERPOOL.
It may not be possible to make all the routing and switching
decisions necessary to support RSERPOOL services without knowing more
than just the destination address and port of a packet. The
necessary extended attributes are not elements of L4 or L7 switching,
but are instead, parameters of ASAP and ENRP. As the ENRP traffic is
encrypted in RSERPOOL, the L7 devices would not be able to extract
the necessary session layer data without becoming potential third
party security liabilities.
3.4 Summary
The L4/L7 switching techniques, being network oriented services, are
not able to provide the communications session oriented behavior
required by RSERPOOL.
Adequate support for naming, as well as registration and
deregistration services, is not provided by these devices. RSERPOOL
requires a fault tolerant name service as well as the ability to
register and deregister PEs in real-time. To accomplish this with L4/
L7 switching, one would need to define a standard protocol to allow
the switches to communicate amongst themselves and, perhaps,
implement a co-resident name server on the switch.
The RSERPOOL communication model is broken as these mechanisms are
deployed on switch hardware as opposed to end devices such as PEs,
PUs, and ENRP servers. This implies a significant requirement for
processing power and a lack of support for mobility. It is unlikely
that one could or would build L4/L7 behavior into end devices and
RSERPOOL requires peer-to-peer functionality.
The equipment needed to deploy such solutions can be an order of
magnitude more expensive per port than a traditional L2/L3 device and
oftentimes must be deployed in addition to L2/L3 hardware. It has
been observed that L4/L7 devices show poor performance when acting as
an L2/L3 switch. This combined requirement for network
infrastructure is not appropriate for RSERPOOL.
L4/L7 switching while clearly good in certain areas, lacks the
ability to provide a robust framework for location transparent
clustering capable of scaling in size and performance from web server
or other Internet applications to real-time telecommunications
infrastructure. There are a host of concerns with the ability of
these techniques to meet critical RSERPOOL requirements in the areas
of flexibility, adaptability, timing, security, etc. The amount of
effort required to achieve RSERPOOL functionality across L4/L7
switches would amount to implementing RSERPOOL, as it is currently
defined, on those very switches.
4. ASAP and ENRP
ASAP [6] and ENRP [7] are being developed in the RSERPOOL working
group. Even though they are separate protocols, they are designed to
work together.
4.1 ASAP
ASAP uses a name-based addressing model which isolates a logical ASAP uses a name-based addressing model which isolates a logical
communication endpoint from its IP address(es), thus effectively communication endpoint from its IP address(es), thus effectively
eliminating the binding between the communication endpoint and its eliminating the binding between the communication endpoint and its
physical IP address(es) which normally constitutes a single point of physical IP address(es) which normally constitutes a single point of
failure. In addition, ASAP defines each logical communication failure. In addition, ASAP defines each logical communication
destination as a pool, providing full transparent support for destination as a pool, providing full transparent support for
server-pooling and load sharing. It also allows dynamic system server-pooling and load sharing. If multiple endpoints register under
scalability - members of a server pool can be added or removed at a the same name, a server pool is effectively created. It also allows
any time without interrupting the service. dynamic system scalability - members of a server pool can be added or
removed at any time without interrupting the service.
ASAP is not designed to scale Internet wide. It uses a flat, peer- ASAP monitors the reachability of the Pool Elements in order to
to-peer addressing model. Other protocols, such as DNS could be provide fault tolerance. To support real-time or semi-real-time fault
used to bridge the pools of servers. It uses a name-based detection and recovery, ASAP makes use of the peer reachability
addressing model to logically isolate the communication endpoint feedback from either the transport layer (such as SCTP) or the upper
from its IP address(es). If multiple endpoints register under a the layer protocol and re-send (or failover) user messages to alternate
same name, a server pool is effectively created. ASAP is used to PEs in the destination pool. Load sharing and redundancy model
select one Pool Element, based on a number of criteria, such as load support is provided in ASAP at the message sender side. And ASAP
sharing. ASAP monitors the reacability of the Pool Elements in allows extensions to be made in the future to accommodate new load
order to provide fault tolerance. sharing policies and redundancy models.
3.2 ENRP ASAP supports the "keepalive" monitoring of PEs by the name server
and session failover, in which a set of application messages are
defined as a "session" and ASAP provides best-effort transmission of
all the messages in the "session" to the same PE in the destination
pool, and failover the remaining message in the "session" to the same
alternate PE if the first PE fails.
ENRP defines procedures and message formats of a distributed fault- 4.2 ENRP
tolerant registry service for storing, bookkeeping, retrieving, and
ENRP defines procedures and message formats of a pool registry
service (or name service) for storing, bookkeeping, retrieving, and
distributing pool operation and membership information. It allows distributing pool operation and membership information. It allows
Pool Elements to be dynamically added, updated and removed from Pool Elements to be dynamically added, updated and removed from
service. There are protocol mechanisms for detecting and removing service. There are also protocol mechanisms for detecting and
unreachable Pool Elements. removing unreachable Pool Elements.
4 Comparison Against Requirements Another important aspect of ENRP is that itself is fully distributed
and replicated. This is to avoid the name service itself becoming a
single point of failure in the system.
ENRP itself is dynamically scalable, meaning that new ENRP servers
can be added and existing servers be removed as needed. This feature
can be used to achieve zero planned downtime upgrade of a system - an
often found requirement in many mission critical applications.
ENRP is not designed to scale Internet wide. It uses a flat name
space model to gain performance. Other protocols, such as DNS could
be used to bridge small ENRP name spaces to create a large scale name
space.
5. 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 | ASAP
-----------------------------+--------+-----+-----+------+------+ | CORBA | DNS | SLP | ENRP | L4/L7 |
-----------------------------+--------+-----+-----+------+-------+
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 | P |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Communication Model | N | P | Y | Y | Y | Communication Model | N | P | Y | Y | N |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Processing Power | N | Y | Y | Y | Y | Processing Power | N | Y | Y | Y | N |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
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 | N |
Deregistering | | | | | | Deregistering | | | | | |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Naming | Y | Y | Y | Y | Y | Naming | Y | Y | Y | Y | N |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
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 | P | N | Y | Y | Y | Timing Requirements and | P | N | Y | Y | P |
Scaling | | | | | | Scaling | | | | | |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Scalability | N | Y | Y | Y | Y | Scalability | N | Y | Y | Y | Y |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Security - General | Y | P | P | P | P | Security - General | Y | P | P | P | P |
-----------------------------+--------+-----+-----+------+------+ -----------------------------+--------+-----+-----+------+-------+
Security - Name Space | P | P | P | P | P | Security - Name Space | P | P | P | P | N |
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
5 Security Concerns 6. 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.
6 Acknowledgements 7. Acknowledgements
The authors would like to thank Bernard Aboba, Erik Guttman, Matt The authors would like to thank Bernard Aboba, Erik Guttman, Matt
Holdrege, Lyndon Ong, Christopher Ross, Micheal Tuexen and Werner Holdrege, Lyndon Ong, Christopher Ross, Micheal Tuexen and Werner
Vogels for their invaluable comments and suggestions. Vogels for their invaluable comments and suggestions.
7 Normative References Normative References
[ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access
Protocol (ASAP)", Work in progress.
[ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution
Protocol (ENRP)", Work inprogress.
[MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
Protocol" Work in progress. J. and M. Stillman, "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-05 (work in progress), Feb 2003.
[RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
Pooling" Work in Progress. J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002.
[RFC3237] Tuexen, M. et al., "Requirements for Reliable Server Non-Normative References
Pooling", RFC3237, January 2002.
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
793, September 1981. specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2026] S. Bradner, "The Internet Standards Process - [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Revision 3", RFC 2026, October 1996. Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] E. Guttman et al., "Service Location Protocol, [5] Zhao, W., Schulzrinne, H. and E. Guttman, "Mesh-enhanced Service
Version 2", RFC 2608, June 1999. Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [6] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Transport", RFC 2719, October 1999. Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-07
(work in progress), May 2003.
[RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the [7] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
location of services (DNS SRV)", RFC 2782, February Protocol (ENRP)", draft-ietf-rserpool-enrp-06 (work in
2000. progress), May 2003.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [8] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
Protocol", RFC 2960, November 2000. 9, RFC 2026, October 1996.
8 Authors' Addresses Authors' Addresses
John Loughney John Loughney (editor)
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group Nokia Group FIN-00045
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
Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com
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
Randall Stewart Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
24 Burning Bush Trail 8725 West Higgins Road
Crystal Lake, Il 60012 Suite 300
Chicago, IL 60631
USA USA
Email: rrs@cisco.com
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Aron J. Silverton
Motorola, Inc.
1301 East Algonquin Road
Mail Drop 2246
Schaumburg, IL 60196
USA
Phone: +1-847-576-8747
EMail: Aron.J.Silverton@motorola.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
are included on all such copies and derivative works. However, this 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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 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. 

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