draft-ietf-rserpool-comp-04.txt   draft-ietf-rserpool-comp-05.txt 
RserPool Working Group J. Loughney (ed.) RserPool Working Group J. Loughney (ed.)
INTERNET DRAFT M. Stillman INTERNET DRAFT M. Stillman
Nokia Nokia
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
Issued: June 30, 2002 Issued: November 4, 2002
Expires: December 30, 2002 Expires: May 4, 2003
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
<draft-ietf-rserpool-comp-04.txt> <draft-ietf-rserpool-comp-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2002. All Rights Reserved. Copyright (C) The Internet Society 2002. All Rights Reserved.
Abstract Abstract
This document compares protocols that may be applicable for Reliable This document compares protocols that may be applicable for the
Server Pooling problem space. This document discusses the usage and Reliable Server Pooling problem space. This document discusses the
applicability of these protocols for Reliable Server Pooling. usage and applicability of these protocols for the Reliable Server
Pooling architecture.
Abstract..............................................................1 Abstract.............................................................1
1 Introduction.......................................................3 1 Introduction.......................................................3
1.1 Overview........................................................3 1.1 Overview........................................................3
1.2 Terminology.....................................................3 1.2 Terminology.....................................................3
2 Relation to Other Solutions........................................4 2 Relation to Other Solutions........................................4
2.1 CORBA...........................................................4 2.1 CORBA...........................................................4
2.2 DNS.............................................................4 2.2 DNS.............................................................4
2.2.1 Requirements.................................................5 2.2.1 Requirements.................................................5
2.2.2 Technical Issues.............................................5 2.2.2 Technical Issues.............................................5
2.2.3 Name/Address Resolution......................................7 2.2.3 Name/Address Resolution......................................7
2.3 Service Location Protocol (SLP).................................8 2.3 Service Location Protocol (SLP).................................8
skipping to change at page 4, line 42 skipping to change at page 4, line 42
distributed applications. CORBA's distribution model encourages an distributed applications. CORBA's distribution model encourages an
object-based view, i.e., each communication endpoint is normally an object-based view, i.e., each communication endpoint is normally an
object. object.
CORBA has a number of variants, such as fault-tolerant CORBA, Real- CORBA has a number of variants, such as fault-tolerant CORBA, Real-
time CORBA, etc. CORBA has been used in a number of situations, for time CORBA, etc. CORBA has been used in a number of situations, for
example, Real-time CORBA has been used in fighter aircraft and example, Real-time CORBA has been used in fighter aircraft and
weapon systems. Additionally, CORBA has been implentented in a wide weapon systems. Additionally, CORBA has been implentented in a wide
range of devices, from attack submarines to Palm Pilots - the MICO range of devices, from attack submarines to Palm Pilots - the MICO
open source ORB has been ported to the Palm Pilot, and the client- open source ORB has been ported to the Palm Pilot, and the client-
only application is 45 KB. only application is 45 KB in size.
Currently, the applicability of CORBA is unclear, and interaction Currently, the applicability of CORBA for reliable server pooling is
with other Internet protocols, such as AAA, IPsec and IPv6 may be unclear, and interaction with other Internet protocols, such as AAA,
problematic. IPsec and IPv6 may be problematic.
2.2 DNS 2.2 DNS
This section will answer the question why DNS is not appropriate as This section will answer the question why DNS is not appropriate as
the sole solution for RSerPool. In addition, it highlights specific the sole solution for RSerPool. In addition, it highlights specific
technical differences between RSerPool and DNS. technical differences between RSerPool and DNS.
During the 49th IETF December 13, 2000 plenary meeting Randy Bush During the 49th IETF December 13, 2000 plenary meeting Randy Bush
presented a talk entitled "The DNS Today: Are we overloading the presented a talk entitled "The DNS Today: Are we overloading the
Saddlebags on an Old Horse?" This talk underlined the issue that DNS Saddlebags on an Old Horse?" This talk underlined the issue that DNS
skipping to change at page 5, line 18 skipping to change at page 5, line 18
One requirement to any solution proposed by RSerPool would be to One requirement to any solution proposed by RSerPool would be to
avoid any additional requirements for DNS in order to support avoid any additional requirements for DNS in order to support
Reliable Server Pooling. Interworking between DNS and RSerPool will Reliable Server Pooling. Interworking between DNS and RSerPool will
be considered so that additional burdens to DNS will not be added. be considered so that additional burdens to DNS will not be added.
2.2.1 Requirements 2.2.1 Requirements
Any solution for RSerPool should meet certain requirements Any solution for RSerPool should meet certain requirements
[RFC3237]. These requirements are related to DNS. [RFC3237]. These requirements are related to DNS.
Servers should be able to register to (become PEs) and deregister "Servers should be able to register to (become PEs) and
from a server pool transparently without an interruption in deregister from a server pool transparently without an
service. interruption in service.
The RSerPool mechanisms must be able to support different server The RSerPool mechanisms must be able to support different server
selection mechanisms. These are called server pool policies. selection mechanisms. These are called server pool policies.
The RSerPool architecture must be able to detect server failure The RSerPool architecture must be able to detect server failure
quickly and be able to perform failover without service quickly and be able to perform failover without service
interruption. interruption.
Server pools are identified by pool handles. These pool handles Server pools are identified by pool handles. These pool handles
are only valid inside the operation scope. Interoperability are only valid inside the operation scope. Interoperability
between different namespaces has to be provided by other between different namespaces has to be provided by other
mechanisms. mechanisms."
2.2.2 Technical Issues 2.2.2 Technical Issues
This section discusses the relationship between DNS and the This section discusses the relationship between DNS and the
requirements for RserPool. requirements for RserPool.
2.2.2.1 Host Resolver Problems 2.2.2.1 Host Resolver Problems
A major issue that prevents the use of DNS as part of the RSerPool A major issue that prevents the use of DNS as part of the RSerPool
solution the issue is the architecture of host resolvers. These are solution the issue is the architecture of host resolvers. These are
skipping to change at page 6, line 5 skipping to change at page 6, line 5
In turn, this implies that setting TTL low or 0 will dramatically In turn, this implies that setting TTL low or 0 will dramatically
increase the load not only on the authoritative DNS servers - but increase the load not only on the authoritative DNS servers - but
also on these third party servers. also on these third party servers.
A secondary effect of this is that the authoritative DNS will not A secondary effect of this is that the authoritative DNS will not
know the IP address of the DNS client - only the IP address of the know the IP address of the DNS client - only the IP address of the
local DNS. This affects the ability to do global load balancing local DNS. This affects the ability to do global load balancing
correctly. correctly.
There is no way to get around these issues unless you all hosts There is no way to get around these issues unless you require all
would be full resolvers. Putting full resolvers on newer hosts isn't hosts to be full resolvers. Putting full resolvers on newer hosts
sufficient because the issues would still exist for all the legacy isn't sufficient because the issues would still exist for all the
systems, which will form the bulk of the host population for years legacy systems, which will form the bulk of the host population for
to come. The solution is not to use third party servers. years to come. The solution is not to use third party servers.
Additionally, if the client can contact the server directly, then Additionally, if the client can contact the server directly, then
the server knows the real IP address of the client. Since there is the 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 no third party involved, the caching TTL can be set as low as
desired (even to zero). That will increase load on the server, but desired (even to zero). That will increase load on the server, but
nowhere else. nowhere 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
skipping to change at page 8, line 18 skipping to change at page 8, line 18
2.3.1 Introduction 2.3.1 Introduction
SLP is comprised of three components: User Agents (UA), Service SLP is comprised of three components: User Agents (UA), Service
Agents (SA) and Directory Agents (DA). User agents work on the Agents (SA) and Directory Agents (DA). User agents work on the
user's behalf to contact a service. The UA retrieves service user's behalf to contact a service. The UA retrieves service
information from service agents or directory agents. A service agent information from service agents or directory agents. A service agent
works on behalf of one or more services to advertise services. A works on behalf of one or more services to advertise services. A
directory agent collects service advertisements. directory agent collects service advertisements.
The directory agent of SLP functions simply acts as a cache and is The directory agent of SLP simply acts as a cache and is passive in
passive in this regard. The directory agent is optional and SLP can this regard. The directory agent is optional and SLP can function
function without it. It is incumbent upon the servers to update the without it. It is incumbent upon the servers to update the cache as
cache as necessary by reregistering. The directory server is not necessary by reregistering. The directory server is not required in
required in small networks as the user agents can contact service small networks as the user agents can contact service agents
agents directly using multicast. Unicast queries to SAs are possible directly using multicast. Unicast queries to SAs are possible
subsequent to the UA having discovered them. User agents are subsequent to the UA having discovered them. User agents are
encouraged to locate a directory at regular intervals if they can't encouraged to locate a directory at regular intervals if they can't
find one initially, otherwise they can detect DAs by listening find one initially, otherwise they can detect DAs by listening
passively for DA advertisements. passively for DA advertisements.
2.3.2 What to Use 2.3.2 What to Use
Figure 1 shows how SLP might be realized to provide ENR services: Figure 1 shows how SLP might be realized to provide ENR services:
Pool User (PU) ENR Service Pool Endpoint (PE) Pool User (PU) ENR Service Pool Endpoint (PE)
skipping to change at page 10, line 19 skipping to change at page 10, line 19
In contrast, RSerPool provides to its user is a mapping function In contrast, RSerPool provides to its user is a mapping function
from a communication destination name to a set of routable and from a communication destination name to a set of routable and
reachable transport addresses that leads to a group of distributed reachable transport addresses that leads to a group of distributed
software server entities registered under that name that software server entities registered under that name that
collectively represent the named communication destination. With collectively represent the named communication destination. With
respect to SLP, this information could be represented in SLP respect to SLP, this information could be represented in SLP
attributes. RserPool, however, also has the responsibility of attributes. RserPool, however, also has the responsibility of
reliably delivering a user message to one of these server entities. reliably delivering a user message to one of these server entities.
Currently, mSLP would need changes, for example it was designed to Currently, mSLP would need changes, for example it was designed to
scale to ~10 DAs not ~100 DAs. Additionally, SLP is currently to scale to ~10 DAs not ~100 DAs. Additionally, SLP is currently
run on top of UDP and TCP. If SCTP support was needed, some designed to run on top of UDP and TCP. If SCTP support is needed,
additional specification work would be needed. some additional specification work would be needed.
SLP security makes no attempt to address the confidentiality of data SLP security makes no attempt to address the confidentiality of data
transmitted between SLP agents. To properly address this concern, transmitted between SLP agents. To properly address this concern,
SLP 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 other. This would be achieved through the use of IPSec
Encapsulating Security Payload. Encapsulating 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.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
This type of non-protocol document does not directly affect the This type of non-protocol document does not directly affect the
security of the Internet. security of the Internet.
6 Acknowledgements 6 Acknowledgements
The authors would like to thank Bernard Aboba, Erik Guttman, Matt The authors would like to thank Bernard Aboba, Erik Guttman, Matt
Holdrege, Lyndon Ong, Christopher Ross, Micheal Tuexen and Werner Holdrege, Lyndon Ong, Christopher Ross, Micheal Tuexen and Werner
Vogels for their invaluable comments and suggestions. Vogels for their invaluable comments and suggestions.
7 References 7 Normative References
[ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access [ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access
Protocol (ASAP)", Work in progress. Protocol (ASAP)", Work in progress.
[ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution [ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution
Protocol (ENRP)", Work inprogress. Protocol (ENRP)", Work inprogress.
[MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location [MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location
Protocol" Work in progress. Protocol" Work in progress.
 End of changes. 

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