draft-ietf-rserpool-comp-06.txt   draft-ietf-rserpool-comp-07.txt 
Network Working Group J. Loughney, Ed. Network Working Group J. Loughney, Ed.
Internet-Draft M. Stillman Internet-Draft M. Stillman
Expires: December 29, 2003 Nokia Expires: April 1, 2004 Nokia
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
A. Silverton A. Silverton
Motorola Motorola
June 30, 2003 October 02, 2003
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
draft-ietf-rserpool-comp-06.txt draft-ietf-rserpool-comp-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions 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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 December 29, 2003. This Internet-Draft will expire on April 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3
2. Relation to Other Solutions . . . . . . . . . . . . . . . . 4 2. Relation to Other Solutions . . . . . . . . . . . . . . . . 4
2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Service Location Protocol (SLP) . . . . . . . . . . . . . . 9 2.3 Service Location Protocol (SLP) . . . . . . . . . . . . . . 9
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 What to Use . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 What to Use . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Summary of SLP Issues . . . . . . . . . . . . . . . . . . . 11 2.3.3 Summary of SLP Issues . . . . . . . . . . . . . . . . . . . 11
3. L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . . 12 2.4 L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . 13 2.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Security Issues . . . . . . . . . . . . . . . . . . . . . . 13 2.5 ASAP and ENRP . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1 ASAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.2 ENRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . 14 3. Comparison Against Requirements . . . . . . . . . . . . . . 17
3.3.3 Security Issues . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . 18
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
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 Normative References . . . . . . . . . . . . . . . . . . . . 18
Non-Normative References . . . . . . . . . . . . . . . . . . 19 Non-Normative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 21
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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
requirements of Reliable Server Pooling [2]. 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 a Operational Scope: The part of the network visible to pool users by a
specific instance of the reliable server pooling protocols. specific instance of the reliable server pooling protocols.
Pool: A collection of servers providing the same application Pool: A collection of servers providing the same application
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 Name Space: A cohesive structure of pool names and relations that may
be queried by an internal or external agent. be queried by an internal or external agent.
Name Server: Entity which the responsible for managing and Name Server: Entity which is responsible for managing and maintaining
maintaining the name space within the RSERPOOL operation scope. the name 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 5, line 26 skipping to change at page 5, line 26
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 to 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 related 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
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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
to achieve 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 is going to N-active, etc. These models basically define how a PE behaves when
behave when another PE in the same pool fails and it is often another PE in the same pool fails and it is often critical for the
critical for the application to have full control over this behavior application to have full control over this behavior of each PE in the
of each PE in the pool. Without major extensions, it seems difficult pool. Without major extensions, it seems difficult for DNS to support
for DNS to support such redundancy models. such redundancy models.
2.3 Service Location Protocol (SLP) 2.3 Service Location Protocol (SLP)
2.3.1 Introduction 2.3.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 user's Agents (SA) and Directory Agents (DA). User agents work on the user's
behalf to contact a service. The UA retrieves service information behalf to contact a service. The UA retrieves service information
from service agents or directory agents. A service agent works on from service agents or directory agents. A service agent works on
behalf of one or more services to advertise services. A directory behalf of one or more services to advertise services. A directory
skipping to change at page 12, line 16 skipping to change at page 12, line 16
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.
3. L4/L7 Switching 2.4 L4/L7 Switching
3.1 Introduction 2.4.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 detail these techniques in are highly proprietary, it is difficult to discuss these techniques
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 5 for a more detailed accounting requirements not met. See Section 3 for a more detailed accounting
of requirements compliance. of requirements compliance.
3.2 L4 Switching 2.4.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.
3.2.1 Example 2.4.2.1 Example
Web caching is an example of L4 switching. The topology requires the Web caching is an example of L4 switching. The topology requires the
introduction of an L4 capable switch in series with an existing introduction of an L4 capable switch in series with an existing
network connection and L2/L3 switch. This is of particular use to network connection and L2/L3 switch. This is of particular use to
web cache configurations where, for example, all traffic destined for web cache configurations where, for example, all traffic destined for
port 80 (HTTP) could be redirected to a web cache or distributed by 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 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 The L4 switch can react to a failed cache and cease to send traffic
to that device by automatically detecting that it is unreachable. to that device by automatically detecting that it is unreachable.
This is all accomplished without any configuration on a client This is all accomplished without any configuration on a client
skipping to change at page 13, line 24 skipping to change at page 13, line 24
which packets belong to which connection and see that all such which packets belong to which connection and see that all such
packets are switched to the same firewall. packets are switched to the same firewall.
An L4 switch is incapable of differentiating between packets An L4 switch is incapable of differentiating between packets
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.
3.2.2 Technical Issues 2.4.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 extended features of ASAP [6] and ENRP [7] are not met by Most of the features of ASAP [6] and ENRP [7] are not met by a device
a device employing L4 switching techniques. employing L4 switching techniques. See the comparison table in
Section 5.
3.2.3 Security Issues 2.4.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.
3.3 L7 Switching 2.4.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
determine what type of object is contained within. determine what type of object is contained within.
3.3.1 Example 2.4.3.1 Example
For an L7 switch to do this, it is necessary to intercept data 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 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 switch must break the TCP handshake when a new request is made to the
server attached to the switch. This process begins during the server attached to the switch. This process begins during the
initialization of the TCP connection and before the higher level initialization of the TCP connection and before the higher level
protocol, i.e., HTTP, sends its request. The switch acts as the protocol, i.e., HTTP, sends its request. The switch acts as the
server during the TCP SYN, SYN ACK, ACK handshake between that server 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 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 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 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 up a second connection with the actual server through an additional
three-way handshake. The switch will forward the client's request to three-way handshake. The switch will forward the client's request to
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.
3.3.2 Technical Issues 2.4.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
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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.
3.3.3 Security Issues 2.4.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.
3.4 Summary 2.4.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 L4/ register and deregister PEs in real-time. To accomplish this with L4/
L7 switching, one would need to define a standard protocol to allow L7 switching, one would need to define a standard protocol to allow
skipping to change at page 16, line 24 skipping to change at page 16, line 24
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.
4. ASAP and ENRP 2.5 ASAP and ENRP
ASAP [6] and ENRP [7] are being developed in the RSERPOOL working ASAP [6] and ENRP [7] 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.
4.1 ASAP 2.5.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. If multiple endpoints register under server-pooling and load sharing. If multiple endpoints register under
a the same name, a server pool is effectively created. It also allows a the same name, a server pool is effectively created. It also allows
dynamic system scalability - members of a server pool can be added or dynamic system scalability - members of a server pool can be added or
removed at any time without interrupting the service. removed at any time without interrupting the service.
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 fault provide fault tolerance. To support real-time or semi-real-time fault
detection and recovery, ASAP makes use of the peer reachability 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. And ASAP support is provided in ASAP at the message sender side. ASAP allows
allows extensions to be made in the future to accommodate new load extensions to be made in the future to accommodate new load sharing
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 name 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, and failover the remaining message in the "session" to the same pool. For some classes of service, ASAP can provide failover for the
alternate PE if the first PE fails. remaining message in the "session" to an alternate PE if the first PE
fails.
4.2 ENRP 2.5.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.
Another important aspect of ENRP is that itself is fully distributed Within the operational scope of RSERPOOL, ENRP defines the procedures
and replicated. This is to avoid the name service itself becoming a and message formats of a distributed, fault-tolerant registry service
single point of failure in the system. for storing, bookkeeping, retrieving, and distributing pool operation
and membership information. 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 ENRP itself is dynamically scalable, meaning that new ENRP servers
can be added and existing servers be removed as needed. This feature can be added and existing servers can be removed as needed. This
can be used to achieve zero planned downtime upgrade of a system - an feature can be used to achieve zero planned downtime upgrade of a
often found requirement in 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.
5. 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 protocols which have been suggested as applicable to the RSERPOOL
architecture. 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 |
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
skipping to change at page 18, line 32 skipping to change at page 18, line 35
-----------------------------+--------+-----+-----+------+-------+ -----------------------------+--------+-----+-----+------+-------+
Security - Name Space | P | P | P | P | N | 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
6. Security Concerns Table1: Comparison Against Requirements
4. 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.
7. 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, 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.
Normative References Normative References
[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
J. and M. Stillman, "Architecture for Reliable Server Pooling", "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-05 (work in progress), Feb 2003. draft-ietf-rserpool-arch-07 (work in progress), Oct 2003.
[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.
Non-Normative References 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 20, line 31 skipping to change at page 20, line 40
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 or other rights that might be claimed to intellectual property 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; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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