draft-ietf-rserpool-comp-08.txt   draft-ietf-rserpool-comp-09.txt 
Network Working Group J. Loughney, Ed. Network Working Group J. Loughney, Ed.
Internet-Draft M. Stillman Internet-Draft M. Stillman
Expires: January 17, 2005 Nokia Expires: August 25, 2005 Nokia
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
A. Silverton A. Silverton
Motorola Motorola
July 16, 2004 February 21, 2005
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
draft-ietf-rserpool-comp-08.txt draft-ietf-rserpool-comp-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005. This Internet-Draft will expire on August 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 12 skipping to change at page 2, line 15
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Relation to Other Solutions . . . . . . . . . . . . . . . . . 4 2. Relation to Other Technologies . . . . . . . . . . . . . . . . 4
2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . 6 2.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . 6
2.3 Dynamic Delegation Discovery System (DDDS) and URI . . . . 9 2.3 Dynamic Delegation Discovery System (DDDS) and URI . . . . 9
2.4 Service Location Protocol (SLP) . . . . . . . . . . . . . 11 2.4 Service Location Protocol (SLP) . . . . . . . . . . . . . 11
2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 11 2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 What to Use . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 What to Use . . . . . . . . . . . . . . . . . . . . . 12
2.4.3 Summary of SLP Issues . . . . . . . . . . . . . . . . 13 2.4.3 Summary of SLP Issues . . . . . . . . . . . . . . . . 13
2.5 L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . 15 2.5 L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . 15 2.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . 15 2.5.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . 15
2.5.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . 16 2.5.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . 16
2.5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 ASAP and ENRP . . . . . . . . . . . . . . . . . . . . . . 19 2.6 ASAP and ENRP . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 ASAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6.1 ASAP . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 ENRP . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6.2 ENRP . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Comparison Against Requirements . . . . . . . . . . . . . . . 20 3. Comparison Against Requirements . . . . . . . . . . . . . . . 20
4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 21 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 6.1 Normative References . . . . . . . . . . . . . . . . . . . 21
6.2 Non-Normative References . . . . . . . . . . . . . . . . . . 21 6.2 Non-Normative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
In creating a solution to provide reliable server pools [1], there In creating a solution to provide reliable server pools [1], there
are a number of existing protocols, which appear to have similar are a number of existing protocols, which appear to have similar
properties as to what RSERPOOL is trying to accomplish. This properties as to what RSerPool is trying to accomplish. This
document discusses the applicability of these protocols in meeting document discusses the applicability of these protocols in meeting
the requirements of Reliable Server Pooling [2]. the 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:
skipping to change at page 3, line 37 skipping to change at page 3, line 37
functionality. Also called a Server Pool. functionality. Also called a Server Pool.
Pool Handle: A logical pointer to a pool. Each server pool will be Pool Handle: A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique pool identifiable in the operation scope of the system by a unique pool
handle or "name". Also called a Pool Name. handle or "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.
Name Space: A cohesive structure of pool names and relations that may Handle-Space: A cohesive structure of pool names and relations that
be queried by an internal or external agent. may be queried by an internal or external agent.
Name Server: Entity which is responsible for managing and maintaining ENRP Server: Entity which is responsible for managing and maintaining
the name space within the RSERPOOL operational scope. the handle-space within the RSerPool operational 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.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
PU: Pool User. 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.
TTL: Time to live in DNS. TTL: Time to live in DNS.
2. Relation to Other Solutions 2. Relation to Other Technologies
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 [2]. The protocols discussed have been suggested as requirements [2]. The protocols discussed have been suggested 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 weapon example, Real-time CORBA has been used in fighter aircraft and weapon
systems. Additionally, CORBA has been implemented in a wide range of systems. Additionally, CORBA has been implemented in a wide range of
devices, from attack submarines to Palm Pilots - the MICO open source devices, from attack submarines to Palm Pilots - the MICO open source
ORB has been ported to the Palm Pilot, and the client- only ORB has been ported to the Palm Pilot, and the client- only
application is 45 KB in size. application is 45 KB in size.
CORBA, a DPE, sits above the communications layer that is the purview CORBA, a DPE, sits above the communications layer that is the purview
of most IETF work, specifically, RSERPOOL. In a conceptual model of of most IETF work, specifically, RSerPool. In a conceptual model of
a middleware stack for highly available clustering, CORBA is a middleware stack for highly available clustering, CORBA is
considered an application service and not a messaging or clustering considered an application service and not a messaging or clustering
service. A distributed application may utilize a CORBA ORB for service. A distributed application may utilize a CORBA ORB for
location transparency at the application layer, and the ORB may in location transparency at the application layer, and the ORB may in
turn utilize RSERPOOL for its communications layer. For example, a turn utilize RSerPool for its communications layer. For example, a
real-time CORBA ORB such as Tau, would benefit from having its real-time CORBA ORB such as Tau, would benefit from having its
interfaces extended to take advantage of RSERPOOL concepts. 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.
RSERPOOL and DNS are protocols with very different objectives. RSerPool and DNS are protocols with very different objectives.
RSERPOOL is designed to provide a range of services up to the point RSerPool is designed to provide a range of services up to the point
of relieving an application of the overhead of maintaining a session of relieving an application of the overhead of maintaining a session
with an active server. DNS was not intended to handle such a range 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 of functions. DNS may, however, be able to handle some of the lower
range of RSERPOOL functionality. range of RSerPool functionality.
One requirement of any solution proposed by RSERPOOL would be to One requirement of 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 [2]. Any solution for RSerPool should meet certain requirements [2].
These requirements are discussed below in relation to DNS. These requirements are discussed below in relation 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
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 is the architecture of host resolvers. These are stub solution is the architecture of host resolvers. These are stub
resolvers - which means that they require their local DNS servers to resolvers - which means that they require their local DNS 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 the Additionally, if the client can contact the server directly, then the
server knows the real IP address of the client. Since there is no server knows the real IP address of the client. Since there is no
third party involved, the caching TTL can be set as low as desired third party involved, the caching TTL can be set as low as desired
(even to zero). That will increase load on the server, but nowhere (even to zero). That will increase load on the server, but nowhere
else. else.
Finally, DNS is based on a recursion. This recursion presents Finally, DNS is based on a recursion. This recursion presents
certain difficulties for RSERPOOL. Even if a host resolver is not a certain difficulties for RSerPool. Even if a host resolver is not a
stub resolver, it has to go to another full resolver where 2 stub resolver, it has to go to another full resolver where 2
possibilities exists: either the mapping name-IP address is found or possibilities exists: either the mapping name-IP address is found or
it has to do another recursive resolution of the name, staring from it has to do another recursive resolution of the name, staring from
that intermediate resolver, until there is a cache hit in one of the that 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
skipping to change at page 7, line 12 skipping to change at page 7, line 12
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 (i.e., PEs) to register RSerPool must allow software server entities (i.e., PEs) to register
themselves with a name server dynamically. They can also de-register themselves with a name server dynamically. They can also de-register
themselves for purposes of preventative maintenance or can be themselves for purposes of preventative maintenance or can be
de-registered by a name server that believes the server entity is no de-registered by an ENRP server that believes the server entity is no
longer 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 ENRP servers.
2.2.2.3 Load Balancing 2.2.2.3 Load Balancing
RFC 2782 [3] itself points out some of the limitations of using DNS RFC 2782 [3] itself points out some of the limitations of using DNS
SRV for load balancing between servers. SRV for load balancing between servers.
Weight is only intended for static, not dynamic, server selection. Weight is only intended for static, not dynamic, server selection.
Using SRV weight for dynamic server selection would require Using SRV weight for dynamic server selection would require
assigning unreasonably short TTLs to the SRV RRs, which would assigning unreasonably short TTLs to the SRV RRs, which would
limit the usefulness of the DNS caching mechanism, thus increasing limit the usefulness of the DNS caching mechanism, thus increasing
skipping to change at page 7, line 41 skipping to change at page 7, line 41
redirecting clients to servers randomly as various caches in various redirecting clients to servers randomly as various caches in various
resolvers expire at random (although small) intervals. DNS offers resolvers expire at random (although small) intervals. DNS offers
excellent network scalability but poor control over load balance. excellent network scalability but poor control over load 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
RSERPOOL working group has agreed that one of its main design goals RSerPool working group has agreed that one of its main design goals
for RSERPOOL is "...performance for supporting real-time for RSerPool is "...performance for supporting real-time
applications", as reflected in RFC 3237 [2]. An example of such applications", as reflected in RFC 3237 [2]. An example of such
real-time applications would be the IP-based call control real-time applications would be the IP-based call control
applications in a 3G cellular network. applications in a 3G cellular network.
To achieve this goal, it is felt critical that RSERPOOL monitors the To achieve this goal, it is felt critical that RSerPool monitors the
state of each server entity on various hosts on a continual basis and state of each server entity on various hosts on a continual basis and
collects several state variables including up/down state and current collects several state variables including up/down state and current
load. If a server is no longer operational, eventually it will be load. If a server is no longer operational, eventually it will be
dropped from the list of available servers maintained by the name dropped from the list of available servers maintained by the ENRP
server, so that subsequent application name queries will not resolve server, so that subsequent application name queries will not resolve
to this server address. to this server address.
DNS does not incorporate an application layer heartbeat. DNS does not incorporate an application layer heartbeat.
Heartbeating would dramatically boost traffic levels, and given the Heartbeating would dramatically boost traffic levels, and given the
unavoidable third party dependencies of DNS, the resulting loading unavoidable third party dependencies of DNS, the resulting loading
would be unacceptable. It is passive in the sense that it does not would be unacceptable. It is passive in the sense that it does not
monitor or store information on the state of the host such as whether monitor or store information on the state of the host such as whether
the host is up or down or what kind of load it is currently the host is up or down or what kind of load it is currently
experiencing. experiencing.
It is not entirely impossible to make DNS utilize the assistance of It is not entirely impossible to make DNS utilize the assistance of
an external heartbeat function/protocol for this monitoring purpose. an external heartbeat function/protocol for this monitoring purpose.
However, to achieve the degree of real-time performance RSERPOOL is However, to achieve the degree of real-time performance RSerPool is
seeking, one would most likely need a tight coupling of this external seeking, one would most likely need a tight coupling of this external
function to the DNS operation. This in turn would likely result in function to the DNS operation. This in turn would likely result in
substantial modification of the existing DNS, which is what we want substantial modification of the existing DNS, which is what we want
to avoid. to avoid.
2.2.2.5 Name/Address Resolution Granularity 2.2.2.5 Name/Address Resolution Granularity
The technical requirement for DNS name/address resolution is The technical requirement for DNS name/address resolution is
basically that given a name, find a host associated with this name basically that given a name, find a host associated with this name
and return its IP address(es). In other words, in DNS we have the and return its IP address(es). In other words, in DNS we have the
following mapping: following mapping:
Name ; a host machine Name ; a host machine
-to- -to-
Address ; IP address(es) to reach the host machine Address ; IP address(es) to reach the host machine
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
address(es) plus port number) 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 Name ; a handle to a server pool
-to- -to-
Address ; transport address(es) (i.e., IP plus port number) to Address ; transport address(es) (i.e., IP plus port number) to
; reach a set of functionally identical server entities ; reach a set of functionally identical server entities
; (software processes). These software entities can be ; (software processes). These software entities can be
; distributed across multiple host machines. ; distributed across multiple host machines.
Without significant extensions, the current DNS would have difficulty Without significant extensions, the current DNS would have difficulty
achieving this type of name mapping. achieving this type of name mapping.
2.2.2.6 Lack of Support for Real-time Fault Detection and Recovery 2.2.2.6 Lack of Support for Real-time Fault Detection and Recovery
Even if we could somehow overcome the aforementioned shortcomings of Even if we could somehow overcome the aforementioned shortcomings of
DNS in terms of providing the name resolution service to RSERPOOL, we DNS in terms of providing the name resolution service to RSerPool, we
still would not have the support for real-time fault detection and still would not have the support for real-time fault detection and
recovery (i.e., failover) which is a key requirement in RSERPOOL. recovery (i.e., failover) which is a key requirement in RSerPool.
To meet this requirement, a mechanism would need to be in place that To meet this requirement, a mechanism would need to be in place that
would detect the unreachability of a message recipient and re-direct would detect the unreachability of a message recipient and re-direct
or re-route a user message to an alternate recipient in the same or re-route a user message to an alternate recipient in the same
destination pool in real-time or semi-real-time. DNS currently destination pool in real-time or semi-real-time. DNS currently
contains no such mechanism. contains no such mechanism.
2.2.2.7 Lack of Support for Redundancy Models 2.2.2.7 Lack of Support for Redundancy Models
Server pooling as defined in RSERPOOL requires support for different Server pooling as defined in RSerPool requires support for different
redundancy arrangements or models depending on the needs of the redundancy arrangements or models depending on the needs of the
specific application. Commonly used models in practice includes N+M, specific application. Commonly used models in practice includes N+M,
N-active, etc. These models basically define how a PE behaves when N-active, etc. These models basically define how a PE behaves when
another PE in the same pool fails and it is often critical for the 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 application to have full control over this behavior of each PE in the
pool. Without major extensions, it seems difficult for DNS to pool. Without major extensions, it seems difficult for DNS to
support such redundancy models. support such redundancy models.
2.3 Dynamic Delegation Discovery System (DDDS) and URI 2.3 Dynamic Delegation Discovery System (DDDS) and URI
In this section, we discuss the difficulties for RSERPOOL to make use In this section, we discuss the difficulties for RSerPool to make use
of DDDS and URI as building blocks for its distributed pool handle of DDDS and URI as building blocks for its distributed pool handle
database (i.e., RSERPOOL namespace). database (i.e., RSerPool handle-space).
RFC 3401 [5] defines DDDS as an abstract algorithm for applying RFC 3401 [5] defines DDDS as an abstract algorithm for applying
dynamically retrieved string transformation rules to an dynamically retrieved string transformation rules to an
application-unique string. DDDS has been found useful for URI application-unique string. DDDS has been found useful for URI
Resolution, ENUM telephone number to URI resolution, and the NAPTR Resolution, ENUM telephone number to URI resolution, and the NAPTR
DNS resource record. DNS resource record.
As stated in [5], DDDS is "used to implement lazy binding of strings As stated in [5], DDDS is "used to implement lazy binding of strings
to data, in order to support dynamically configured delegation to data, in order to support dynamically configured delegation
systems. The DDDS functions by mapping some unique string to data systems. The DDDS functions by mapping some unique string to data
stored within a DDDS Database by iteratively applying string stored within a DDDS Database by iteratively applying string
transformation rules until a terminal condition is reached." transformation rules until a terminal condition is reached."
In order to discuss the applicability of DDDS/URI in RSERPOOL, we In order to discuss the applicability of DDDS/URI in RSerPool, we
need first talk about some fundamental characteristics of pool need first talk about some fundamental characteristics of pool
handles or names in RSERPOOL. handles or names in RSerPool.
It is important to note that, handles or names in RSERPOOL are meant It is important to note that, handles or names in RSerPool are meant
to identify pools comprising of _generic_ communications nodes. to identify pools comprising of _generic_ communications nodes.
Those nodes in reality will be some kind of servers - service Those nodes in reality will be some kind of servers - service
applications that runs on some networked machines. However, it is applications that runs on some networked machines. However, it is
very important to note that the working group has never had the very important to note that the working group has never had the
intention to go beyond the "server of generic IP applications" in its intention to go beyond the "server of generic IP applications" in its
pool definition. Nor has it seen the need to categorize the types of pool definition. Nor has it seen the need to categorize the types of
the service applications for the purpose of RSERPOOL. This is the service applications for the purpose of RSerPool. This is
fundamentally different from the assumption behind URI as well as the fundamentally different from the assumption behind URI as well as the
Service Location Protocol (to be discussed below). Service Location Protocol (to be discussed below).
With the above noted, here are some additional characteristics of With the above noted, here are some additional characteristics of
RSERPOOL handles/names: RSerPool handles/names:
1. RSERPOOL handles have only local significance, i.e., there is no 1. RSerPool handles have only local significance, i.e., there is no
requirement for pool handles to be globally unique. requirement for pool handles to be globally unique.
This is because the first tier of applications we envision for This is because the first tier of applications we envision for
RSERPOOL is those tightly coupled local systems that can use RSerPool is those tightly coupled local systems that can use
RSERPOOL to make its components highly available. For example, a RSerPool to make its components highly available. For example, a
3G radio access network that contains charging server, call 3G radio access network that contains charging server, call
controller, media server, etc. where RSERPOOL can make those controller, media server, etc. where RSerPool can make those
currently singleton elements into pools and thus gain high currently singleton elements into pools and thus gain high
availability. This type of local systems can be as compact as a availability. This type of local systems can be as compact as a
bunch of server blades located in a single high performance bunch of server blades located in a single high performance
chassis or a group of closely located boxes in a central office chassis or a group of closely located boxes in a central office
or in a few closely located buildings. The use of RSERPOOL in or in a few closely located buildings. The use of RSerPool in
such scenarios can be totally transparent to the outside world. such scenarios can be totally transparent to the outside world.
For example, a SIP phone may be talking to a softswitch without For example, a SIP phone may be talking to a softswitch without
knowing that the call control elements inside the softswitch are knowing that the call control elements inside the softswitch are
a bunch of RSERPOOL-enabled pools. In such cases, the pool names a bunch of RSerPool-enabled pools. In such cases, the pool names
has no need to be globally unique (there is even no need for the has no need to be globally unique (there is even no need for the
outside to know they exist). They only need to be unique within outside to know they exist). They only need to be unique within
the softswitch itself. the softswitch itself.
We also have considered the possibility of supporting larger We also have considered the possibility of supporting larger
scale (even global) deployment cases of RSERPOOL. In the scale (even global) deployment cases of RSerPool. In the
requirement, we indicate we want RSERPOOL to be able to do that requirement, we indicate we want RSerPool to be able to do that
but we have made it clear that RSERPOOL will not be able to do but we have made it clear that RSerPool will not be able to do
that by itself. Instead, it will rely on existing external that by itself. Instead, it will rely on existing external
infrastructures (e.g., DNS, possibly URN/DDDS) to bridge locally infrastructures (e.g., DNS, possibly URN/DDDS) to bridge locally
scoped RSERPOOL clouds into a larger scale deployment. scoped RSerPool clouds into a larger scale deployment.
2. RSERPOOL handles have no need for supporting any structure/ 2. RSerPool handles have no need for supporting any
syntax. structure/syntax.
As merely locally significant identifiers for distinguishing As merely locally significant identifiers for distinguishing
pools of generic communication nodes, we consider adding pools of generic communication nodes, we consider adding
structure/syntax to RSERPOOL handle definition will buy us structure/syntax to RSerPool handle definition will buy us
nothing but will have real negative impact on the performance and nothing but will have real negative impact on the performance and
increase the implementation complexity. The only recommend we increase the implementation complexity. The only recommend we
have made so far is to use NULL-terminated ascii string for the have made so far is to use NULL-terminated ascii string for the
pool handles. This seems to meet our needs nicely. pool handles. This seems to meet our needs nicely.
3. RSERPOOL handles are relatively dynamic. 3. RSerPool handles are relatively dynamic.
We consider that the pools may change relatively frequently; they We consider that the pools may change relatively frequently; they
may come and go as the system re-adjusts its capacity or may come and go as the system re-adjusts its capacity or
configuration. We do not envision the handles to be long lived. configuration. We do not envision the handles to be long lived.
4. RSERPOOL handles are not for human readers. 4. RSerPool handles are not for human readers.
Unlike UNIs (URN/URL), we do not envision RSERPOOL handles to Unlike UNIs (URN/URL), we do not envision RSerPool handles to
appear in e-mails, web documents, etc. for human viewing. appear in e-mails, web documents, etc. for human viewing.
Probably the only case where RSERPOOL handles will be read by a Probably the only case where RSerPool handles will be read by a
human is in a log file or configuration file, just like other human is in a log file or configuration file, just like other
system configuration parameters. system configuration parameters.
Due to the aforementioned characteristics of RSERPOOL handles, we do Due to the aforementioned characteristics of RSerPool handles, we do
not see the benefit for directly using URNs/URIs for RSERPOOL not see the benefit for directly using URNs/URIs for RSerPool
handles. The two rather fundamental requirements (per RFC 1737) that handles. The two rather fundamental requirements (per RFC 1737) that
brought us URNs - the global scope and persistence - do not apply to brought us URNs - the global scope and persistence - do not apply to
RSERPOOL handles. Moreover, as mentioned above, we see little RSerPool handles. Moreover, as mentioned above, we see little
benefit of making RSERPOOL handles human-readable or parsable in free benefit of making RSerPool handles human-readable or parsable in free
text. text.
In the future, there may be the possibility that URNs and the In the future, there may be the possibility that URNs and the
associated infrastructure (e.g., DNS, DDDS) to play a vital role when associated infrastructure (e.g., DNS, DDDS) to play a vital role when
we start to consider wide area or global deployment scenarios for we start to consider wide area or global deployment scenarios for
RSERPOOL. For instance, a SIP client device that is looking for RSerPool. For instance, a SIP client device that is looking for
certain network resource will start with a URN that is eventually certain network resource will start with a URN that is eventually
resolved to a pool handle that is then passed to an RSERPOOL resolved to a pool handle that is then passed to an RSerPool
namespace server, which in turn will resolve the pool name to a list namespace server, which in turn will resolve the pool name to a list
of reachable/routable transport addresses of the server instances. of reachable/routable transport addresses of the server instances.
Similarly, since RSERPOOL handles are not global and have no Similarly, since RSerPool handles are not global and have no
structure/syntax, we do not see that using DDDS inside RSERPOOL can structure/syntax, we do not see that using DDDS inside RSerPool can
bring meaningful benefits. bring meaningful benefits.
2.4 Service Location Protocol (SLP) 2.4 Service Location Protocol (SLP)
2.4.1 Introduction 2.4.1 Introduction
SLP [4] 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 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
skipping to change at page 12, line 22 skipping to change at page 12, line 22
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 directly small networks as the user agents can contact service agents directly
using multicast. Unicast queries to SAs are possible subsequent to using multicast. Unicast queries to SAs are possible subsequent to
the UA having discovered them. User agents are encouraged to locate the UA having discovered them. User agents are encouraged to locate
a directory at regular intervals if they can't find one initially, a directory at regular intervals if they can't find one initially,
otherwise they can detect DAs by listening passively for DA otherwise they can detect DAs by listening passively for DA
advertisements. advertisements.
2.4.2 What to Use 2.4.2 What to Use
Figure 1 shows how SLP might be realized to provide RSERPOOL endpoint Figure 1 shows how SLP might be realized to provide RSerPool endpoint
name resolution (ENR) services: 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 |
+---------+---+ +------+---+ +---+---------+ +---------+---+ +------+---+ +---+---------+
/ \ / \
/ 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:
o 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.
o 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.
o 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.
o 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 PU timely and robust manner and uses it to determine how to route PU
requests to PEs. requests to PEs.
o The ENR service function is performed using SLP. The PU employs a o The ENR service function is performed using SLP. The PU employs a
SLP UA to obtain information from a SLP DA. SLP UA to obtain information from a SLP DA.
o The ENR service function is performed using SLP. The PU employs a
SLP UA to obtain information from a SLP DA.
o The PE employs a SLP SA to register information with a SLP DA. As o 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 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 & this type (as long as it detects that this DA is alive &
responsive & returns 'OK' results). responsive & returns 'OK' results).
o 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.
o SCTP is used for communication between entities. Multicast UDP is o SCTP is used for communication between entities. Multicast UDP is
used by SLP entities for active and passive discovery. While the used by SLP entities for active and passive discovery. While the
RSERPOOL architecture cannot rely upon multicast mechanisms, it RSerPool architecture cannot rely upon multicast mechanisms, 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) [6]. enhancements to the Service Location Protocol (mSLP) [6].
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.4.3 Summary of SLP Issues 2.4.3 Summary of SLP Issues
A fundamental difference between SLP and RSERPOOL is that SLP is a A fundamental difference between SLP and RSerPool is that SLP is a
protocol that focuses on the service level, while RSERPOOL is at the protocol that focuses on the service level, while RSerPool is at the
communication level. More specifically, what SLP provides to its communication level. More specifically, what SLP provides to its
user is a mapping function from a name of a _service_ (e.g., b/w user is a mapping function from a name of a _service_ (e.g., b/w
printing, color printing, faxing) to the location of the service printing, color printing, faxing) to the location of the service
provider, in the form of a URL string. The availability of the provider, in the form of a URL string. The availability of the
service provider is outside of the scope of SLP. How a service is service provider is outside of the scope of SLP. How a service is
accessible can be described by the SLP attribute list associated with accessible can be described by the SLP attribute list associated with
the service URL. SLP is essentially a discovery protocol, not a the service URL. SLP is essentially a discovery protocol, not a
transport protocol. Therefore, the granularity of SLP operation is transport protocol. Therefore, the granularity of SLP operation is
at application service level. at application service level.
In contrast, what RSERPOOL provides to its user is a mapping function In contrast, what RSerPool provides to its user is a mapping function
from a communication destination name (i.e., a pool handle) to a set from a communication destination name (i.e., a pool handle) to a set
of routable and reachable transport addresses that leads to a group of routable and reachable transport addresses that leads to a group
of distributed software server entities registered under that name. of distributed software server entities registered under that name.
RSERPOOL has NO intention to understand or convey to its user what is RSerPool has NO intention to understand or convey to its user what is
the service (e.g., printing, faxing, document scanning) the named the service (e.g., printing, faxing, document scanning) the named
pool is providing at the application level. In other words, the pool is providing at the application level. In other words, the
responsibility of RSERPOOL is only to reliably deliver a user message responsibility of RSerPool is only to reliably deliver a user message
to one of those server entities in the destination pool. to one of those server entities in the destination pool.
In theory, information such as transport addresses and their In theory, information such as transport addresses and their
reachability could be represented in SLP attributes. Currently, mSLP reachability could be represented in SLP attributes. Currently, mSLP
would need changes, for example it was designed to scale to ~10 DAs would need changes, for example it was designed to scale to ~10 DAs
not ~100 DAs. Additionally, SLP is currently designed to run on top not ~100 DAs. Additionally, SLP is currently designed to run on top
of UDP and TCP. If SCTP support is needed, some additional of UDP and TCP. If SCTP support is needed, some additional
specification work would be needed. 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 agents would need to establish secure communication with each SLP agents would need to establish secure communication with each
other. This would be achieved through the use of IPSec Encapsulating other. This would be achieved through the use of IPSec 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.
Other difficulties and shortcomings for using SLP to implement Other difficulties and shortcomings for using SLP to implement
RSERPOOL include: RSerPool include:
o Due to the fact that the resolution granularity of SLP is at the o Due to the fact that the resolution granularity of SLP is at the
service level, it relies on a syntax rich scheme to define service level, it relies on a syntax rich scheme to define
services (e.g., printers > color printers > color printers with services (e.g., printers > color printers > color printers with
720+ resolution, etc). This implies that SLP implementation will 720+ resolution, etc). This implies that SLP implementation will
need to perform syntax analysis, filtering, and parsing when a need to perform syntax analysis, filtering, and parsing when a
name is queried, and will need to dynamically search its name name is queried, and will need to dynamically search its name
space to identify which entities are to be included in the space to identify which entities are to be included in the
response to a specific query. This type of complicated processing response to a specific query. This type of complicated processing
and searching for each query may severely limit the performance of and searching for each query may severely limit the performance of
SLP in a real-time world which is a key requirement of RSERPOOL. SLP in a real-time world which is a key requirement of RSerPool.
o Without major extensions, SLP will not be able to provide a o Without major extensions, SLP will not be able to provide a
solution for real-time or semi-real-time fault detection and solution for real-time or semi-real-time fault detection and
recovery. This is partially because SLP is a discovery protocol, recovery. This is partially because SLP is a discovery protocol,
not a communication protocol. not a communication protocol.
2.5 L4/L7 Switching 2.5 L4/L7 Switching
2.5.1 Introduction 2.5.1 Introduction
This section discusses L4 and L7 switching techniques and their This section discusses L4 and L7 switching techniques and their
relation to the RSERPOOL architecture [2]. Since these technologies relation to the RSerPool architecture [2]. Since these technologies
are highly proprietary, it is difficult to discuss these techniques are highly proprietary, it is difficult to discuss these techniques
in a thorough manner. in a thorough manner.
In both cases, the deployment of these techniques is dependent upon In both cases, the deployment of these techniques is dependent upon
the type of switching equipment deployed and breaks the end-to-end the type of switching equipment deployed and breaks the end-to-end
communication model required by RSERPOOL. These devices provide a communication model required by RSerPool. These devices provide a
specialized service intended to address a few network challenges, specialized service intended to address a few network challenges,
e.g., web caching and web cache load balancing, firewall load e.g., web caching and web cache load balancing, firewall load
balancing, web server scaling, and streaming media load balancing. balancing, web server scaling, and streaming media load balancing.
They are not robust methods for providing network reliability or They are not robust methods for providing network reliability or
highly reliable and highly available location transparent server highly reliable and highly available location transparent server
clustering as required by RSERPOOL. clustering as required by RSerPool.
The following sections will provide an overview and example of each The following sections will provide an overview and example of each
technique and an accounting for key RSERPOOL architectural technique and an accounting for key RSerPool architectural
requirements not met. See Section 3 for a more detailed accounting requirements not met. See Section 3 for a more detailed accounting
of requirements compliance. of requirements compliance.
2.5.2 L4 Switching 2.5.2 L4 Switching
L4 devices make switching decisions based on the TCP or UDP port L4 devices make switching decisions based on the TCP or UDP port
numbers of the packet in transit. numbers of the packet in transit.
2.5.2.1 Example 2.5.2.1 Example
skipping to change at page 16, line 16 skipping to change at page 16, line 13
containing cacheable objects and non-cacheable objects, therefore, L7 containing cacheable objects and non-cacheable objects, therefore, L7
devices, which look inside packets, are deployed where such devices, which look inside packets, are deployed where such
determinations must be made. In general, anytime that knowledge of determinations must be made. In general, anytime that knowledge of
the application level data is required to make a switching decision, the application level data is required to make a switching decision,
L7 devices must be deployed. L7 devices must be deployed.
2.5.2.2 Technical Issues 2.5.2.2 Technical Issues
The more general behavior of L4 switching, redirecting traffic based The more general behavior of L4 switching, redirecting traffic based
on destination UDP or TCP ports, is similar to a function provided by 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 RSerPool. Where it differs in this regard is that L4 switching is
dependent upon the network infrastructure and not peer-to-peer or dependent upon the network infrastructure and not peer-to-peer or
end-to-end as required by RSERPOOL. end-to-end as required by RSerPool.
L4 switching meets the requirement of forwarding to active elements L4 switching meets the requirement of forwarding to active elements
only, as a switch will detect unreachable PEs, but does not provide only, as a switch will detect unreachable PEs, but does not provide
for the necessary registration and deregistration of PEs or for the necessary registration and deregistration of PEs or
resolution by name. L4 switches require the manual configuration of resolution by name. L4 switches require the manual configuration of
access control lists to determine switching behavior. This is access control lists to determine switching behavior. This is
achieved in RSERPOOL by more flexible means and without any achieved in RSerPool by more flexible means and without any
dependence on specialized network equipment. dependence on specialized network equipment.
Most of the features of ASAP [7] and ENRP [8] are not met by a device Most of the features of ASAP [7] and ENRP [8] are not met by a device
employing L4 switching techniques. See the comparison table in employing L4 switching techniques. See the comparison table in
Section 5. Section 5.
2.5.2.3 Security Issues 2.5.2.3 Security Issues
It is not clear that L4 switching introduces any new security It is not clear that L4 switching introduces any new security
concerns. In fact, in a two-port security model, where secure concerns. In fact, in a two-port security model, where secure
RSERPOOL services are provided on one port, and similar, but insecure RSerPool services are provided on one port, and similar, but insecure
services, on another, L4 switching could be used to direct traffic to services, on another, L4 switching could be used to direct traffic to
a secure or insecure PE or ENRP server as necessary. a secure or insecure PE or ENRP server as necessary.
2.5.3 L7 Switching 2.5.3 L7 Switching
As previously mentioned, L7 switching was developed to differentiate As previously mentioned, L7 switching was developed to differentiate
between the type of objects being directed by network switches. In between the type of objects being directed by network switches. In
the L4 case, the devices cannot differentiate between the types of the L4 case, the devices cannot differentiate between the types of
data, only the destination of the packets containing that data. L7 data, only the destination of the packets containing that data. L7
switches look at the application layer of a packet in transit to switches look at the application layer of a packet in transit to
skipping to change at page 17, line 24 skipping to change at page 17, line 22
the server and for the duration of this connection, must graft the the server and for the duration of this connection, must graft the
client-switch and switch-server connections together by modifying IP client-switch and switch-server connections together by modifying IP
addresses and TCP ports on the fly. Cacheable data is handled addresses and TCP ports on the fly. Cacheable data is handled
similarly, but is redirected to groups of web caches as opposed to similarly, but is redirected to groups of web caches as opposed to
the web servers. the web servers.
2.5.3.2 Technical Issues 2.5.3.2 Technical Issues
It is not clear that L7 switching adds anything, as a general It is not clear that L7 switching adds anything, as a general
mechanism, beyond what is provided by L4 switching, towards providing mechanism, beyond what is provided by L4 switching, towards providing
a sufficient RSERPOOL architecture. a sufficient RSerPool architecture.
While this technique can be very valuable as a means to scale web 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 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 the part of the switch to realize these gains. The nature of this
method also requires that for each type of application traffic method also requires that for each type of application traffic
handled, a custom software module must be written and added to the handled, a custom software module must be written and added to the
switch operating system. It is not known, due to the proprietary 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 nature of these devices, if this can be done by the end user and/or
added dynamically to deployed systems. added dynamically to deployed systems.
It may be possible to write custom modules for a switch, given the It may be possible to write custom modules for a switch, given the
appropriate access to hardware and software, to provide some type of appropriate access to hardware and software, to provide some type of
enhanced reliability in a controlled network. But, it is the aim of enhanced reliability in a controlled network. But, it is the aim of
RSERPOOL to provide a general mechanism that is widely deployable and RSerPool to provide a general mechanism that is widely deployable and
highly portable. L7 switching requires a significant amount of highly portable. L7 switching requires a significant amount of
development to customize each of the endpoint switches to which PUs development to customize each of the endpoint switches to which PUs
and PEs may be attached. and PEs may be attached.
Also of concern is the compatibility of SCTP with L7 techniques. The Also of concern is the compatibility of SCTP with L7 techniques. The
interception and subsequent splicing of sessions may nullify some of interception and subsequent splicing of sessions may nullify some of
the inherent benefits of SCTP and certainly add additional and the inherent benefits of SCTP and certainly add additional and
unnecessary complexity and latency to the transport layer. ASAP and unnecessary complexity and latency to the transport layer. ASAP and
ENRP along with the multi-homing and stream based behavior of SCTP ENRP along with the multi-homing and stream based behavior of SCTP
provide more benefit than custom L7 switching would provide and at a provide more benefit than custom L7 switching would provide and at a
significantly lower cost. significantly lower cost.
2.5.3.3 Security Issues 2.5.3.3 Security Issues
While L7 switches do provide some robustness to TCP-based DoS attacks While L7 switches do provide some robustness to TCP-based DoS attacks
directed at servers by requiring a proper three-way handshake, and directed at servers by requiring a proper three-way handshake, and
they can be used to redirect encrypted traffic to certain servers they can be used to redirect encrypted traffic to certain servers
better capable of processing that traffic, they may break the better capable of processing that traffic, they may break the
security model of RSERPOOL. security model of RSerPool.
It may not be possible to make all the routing and switching It may not be possible to make all the routing and switching
decisions necessary to support RSERPOOL services without knowing more decisions necessary to support RSerPool services without knowing more
than just the destination address and port of a packet. The than just the destination address and port of a packet. The
necessary extended attributes are not elements of L4 or L7 switching, necessary extended attributes are not elements of L4 or L7 switching,
but are instead, parameters of ASAP and ENRP. As the ENRP traffic is 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 encrypted in RSerPool, the L7 devices would not be able to extract
the necessary session layer data without becoming potential third the necessary session layer data without becoming potential third
party security liabilities. party security liabilities.
2.5.4 Summary 2.5.4 Summary
The L4/L7 switching techniques, being network oriented services, are The L4/L7 switching techniques, being network oriented services, are
not able to provide the communications session oriented behavior not able to provide the communications session oriented behavior
required by RSERPOOL. required by RSerPool.
Adequate support for naming, as well as registration and Adequate support for naming, as well as registration and
deregistration services, is not provided by these devices. RSERPOOL deregistration services, is not provided by these devices. RSerPool
requires a fault tolerant name service as well as the ability to requires a fault tolerant name service as well as the ability to
register and deregister PEs in real-time. To accomplish this with register and deregister PEs in real-time. To accomplish this with
L4/L7 switching, one would need to define a standard protocol to L4/L7 switching, one would need to define a standard protocol to
allow the switches to communicate amongst themselves and, perhaps, allow the switches to communicate amongst themselves and, perhaps,
implement a co-resident name server on the switch. implement a co-resident name server on the switch.
The RSERPOOL communication model is broken as these mechanisms are The RSerPool communication model is broken as these mechanisms are
deployed on switch hardware as opposed to end devices such as PEs, deployed on switch hardware as opposed to end devices such as PEs,
PUs, and ENRP servers. This implies a significant requirement for PUs, and ENRP servers. This implies a significant requirement for
processing power and a lack of support for mobility. It is unlikely 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 that one could or would build L4/L7 behavior into end devices and
RSERPOOL requires peer-to-peer functionality. RSerPool requires peer-to-peer functionality.
The equipment needed to deploy such solutions can be an order of The equipment needed to deploy such solutions can be an order of
magnitude more expensive per port than a traditional L2/L3 device and magnitude more expensive per port than a traditional L2/L3 device and
oftentimes must be deployed in addition to L2/L3 hardware. It has oftentimes must be deployed in addition to L2/L3 hardware. It has
been observed that L4/L7 devices show poor performance when acting as been observed that L4/L7 devices show poor performance when acting as
an L2/L3 switch. This combined requirement for network an L2/L3 switch. This combined requirement for network
infrastructure is not appropriate for RSERPOOL. infrastructure is not appropriate for RSerPool.
L4/L7 switching while clearly good in certain areas, lacks the L4/L7 switching while clearly good in certain areas, lacks the
ability to provide a robust framework for location transparent ability to provide a robust framework for location transparent
clustering capable of scaling in size and performance from web server clustering capable of scaling in size and performance from web server
or other Internet applications to real-time telecommunications or other Internet applications to real-time telecommunications
infrastructure. There are a host of concerns with the ability of infrastructure. There are a host of concerns with the ability of
these techniques to meet critical RSERPOOL requirements in the areas these techniques to meet critical RSerPool requirements in the areas
of flexibility, adaptability, timing, security, etc. The amount of of flexibility, adaptability, timing, security, etc. The amount of
effort required to achieve RSERPOOL functionality across L4/L7 effort required to achieve RSerPool functionality across L4/L7
switches would amount to implementing RSERPOOL, as it is currently switches would amount to implementing RSerPool, as it is currently
defined, on those very switches. defined, on those very switches.
2.6 ASAP and ENRP 2.6 ASAP and ENRP
ASAP [7] and ENRP [8] are being developed in the RSERPOOL working ASAP [7] and ENRP [8] are being developed in the RSerPool working
group. Even though they are separate protocols, they are designed to group. Even though they are separate protocols, they are designed to
work together. work together.
2.6.1 ASAP 2.6.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
skipping to change at page 19, line 41 skipping to change at page 19, line 38
ASAP monitors the reachability of the Pool Elements in order to ASAP monitors the reachability of the Pool Elements in order to
provide fault tolerance. To support real-time or semi-real-time provide fault tolerance. To support real-time or semi-real-time
fault detection and recovery, ASAP makes use of the peer reachability fault detection and recovery, ASAP makes use of the peer reachability
feedback from either the transport layer (such as SCTP) or the upper feedback from either the transport layer (such as SCTP) or the upper
layer protocol and re-send (or failover) user messages to alternate layer protocol and re-send (or failover) user messages to alternate
PEs in the destination pool. Load sharing and redundancy model PEs in the destination pool. Load sharing and redundancy model
support is provided in ASAP at the message sender side. ASAP allows support is provided in ASAP at the message sender side. ASAP allows
extensions to be made in the future to accommodate new load sharing extensions to be made in the future to accommodate new load sharing
policies and redundancy models. policies and redundancy models.
ASAP supports the "keepalive" monitoring of PEs by the name server ASAP supports the "keepalive" monitoring of PEs by the ENRP server
and session failover, in which a set of application messages are and session failover, in which a set of application messages are
defined as a "session" and ASAP provides best-effort transmission of defined as a "session" and ASAP provides best-effort transmission of
all the messages in the "session" to the same PE in the destination all the messages in the "session" to the same PE in the destination
pool. For some classes of service, ASAP can provide failover for the pool. For some classes of service, ASAP can provide failover for the
remaining message in the "session" to an alternate PE if the first PE remaining message in the "session" to an alternate PE if the first PE
fails. fails.
2.6.2 ENRP 2.6.2 ENRP
ENRP defines procedures and message formats of a pool registry ENRP defines procedures and message formats of a pool registry
service (or name service) for storing, bookkeeping, retrieving, and 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 also protocol mechanisms for detecting and service. There are also protocol mechanisms for detecting and
removing unreachable Pool Elements. removing unreachable Pool Elements.
Within the operational scope of RSERPOOL, ENRP defines the procedures Within the operational scope of RSerPool, ENRP defines the procedures
and message formats of a distributed, fault-tolerant registry service and message formats of a distributed, fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool operation
and membership information. This is to avoid the name service itself and membership information. This is to avoid the name service itself
becoming a single point of failure in the system. becoming a single point of failure in the system.
ENRP itself is dynamically scalable, meaning that new ENRP servers ENRP itself is dynamically scalable, meaning that new ENRP servers
can be added and existing servers can be removed as needed. This can be added and existing servers can be removed as needed. This
feature can be used to achieve zero planned downtime upgrade of a feature can be used to achieve zero planned downtime upgrade of a
system - a common requirement for many mission critical applications. system - a common requirement for many mission critical applications.
ENRP is not designed to scale Internet wide. It uses a flat name ENRP is not designed to scale Internet wide. It uses a flat name
space model to gain performance. Other protocols, such as DNS could 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 be used to bridge small ENRP name spaces to create a large scale name
space. space.
3. Comparison Against Requirements 3. 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 technologies and protocols which have been suggested as applicable to
architecture. the RSerPool architecture.
ASAP ASAP
| CORBA | DNS | SLP | ENRP | L4/L7 | | CORBA | DNS | SLP | ENRP | L4/L7 |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Robustness | Y | Y | Y | Y | Y | Robustness | Y | Y | Y | Y | Y |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Failover Support | Y | P | P | Y | P | Failover Support | Y | P | P | Y | P |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Communication Model | N | P | Y | Y | N | Communication Model | N | P | Y | Y | N |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Processing Power | N | Y | Y | Y | N | 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 | N | Registering and | N | P | P | Y | N |
Deregistering | | | | | | Deregistering | | | | | |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Naming | Y | Y | Y | Y | N | 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 | | | | | |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
skipping to change at page 21, line 41 skipping to change at page 21, line 38
5. Acknowledgements 5. 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, Jon Peterson, Christopher Ross, Micheal Tuexen Holdrege, Lyndon Ong, Jon Peterson, Christopher Ross, Micheal Tuexen
and Werner Vogels for their invaluable comments and suggestions. and Werner Vogels for their invaluable comments and suggestions.
6. References 6. References
6.1 Normative References 6.1 Normative References
[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J. and A.
"Architecture for Reliable Server Pooling", Silverton, "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-07 (work in progress), Oct 2003. Internet-Draft draft-ietf-rserpool-arch-09, February 2005.
[2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002. RFC 3237, January 2002.
6.2 Non-Normative References 6.2 Non-Normative References
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
skipping to change at page 22, line 17 skipping to change at page 22, line 15
[4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002. One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Zhao, W., Schulzrinne, H. and E. Guttman, "Mesh-enhanced Service [6] Zhao, W., Schulzrinne, H. and E. Guttman, "Mesh-enhanced Service
Location Protocol (mSLP)", RFC 3528, April 2003. Location Protocol (mSLP)", RFC 3528, April 2003.
[7] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [7] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 Server Access Protocol (ASAP)",
(work in progress), June 2004. Internet-Draft draft-ietf-rserpool-asap-09, June 2004.
[8] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [8] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-09 (work in Protocol (ENRP)", Internet-Draft draft-ietf-rserpool-enrp-09,
progress), July 2004. July 2004.
[9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [9] Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
Authors' Addresses Authors' Addresses
John Loughney (editor) John Loughney (editor)
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
Nokia Group FIN-00045 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
Phone: +1-607-273-0724 Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com 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
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com Email: qxie1@email.mot.com
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
USA USA
Phone: +1-815-477-2127 Phone: +1-815-477-2127
EMail: rrs@cisco.com Email: rrs@cisco.com
Aron J. Silverton Aron J. Silverton
Motorola, Inc. Motorola, Inc.
1301 East Algonquin Road 1301 East Algonquin Road
Mail Drop 2246 Mail Drop 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1-847-576-8747 Phone: +1-847-576-8747
EMail: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 24, line 41 skipping to change at page 24, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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