draft-ietf-rserpool-comp-09.txt   draft-ietf-rserpool-comp-10.txt 
Network Working Group J. Loughney, Ed. Network Working Group J. Loughney, Ed.
Internet-Draft M. Stillman Internet-Draft Nokia
Expires: August 25, 2005 Nokia Expires: January 7, 2006 A. Silverton, Ed.
Motorola
M. Stillman
Nokia
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
A. Silverton July 6, 2005
Motorola
February 21, 2005
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
draft-ietf-rserpool-comp-09.txt draft-ietf-rserpool-comp-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
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-
Internet-Drafts. 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 August 25, 2005. This Internet-Draft will expire on January 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 21 skipping to change at page 2, line 20
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 Technologies . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . 12
2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 11 2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . 14 2.5 L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 20
3. Comparison Against Requirements . . . . . . . . . . . . . . . 20 3. Comparison Against Requirements . . . . . . . . . . . . . . . 20
4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
6.1 Normative References . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 7.2 Non-Normative References . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
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].
skipping to change at page 7, line 14 skipping to change at page 7, line 17
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-
de-registered by an ENRP server that believes the server entity is no 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 ENRP 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
skipping to change at page 9, line 37 skipping to change at page 9, line 48
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 handle-space). 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-
application-unique string. DDDS has been found useful for URI unique string. DDDS has been found useful for URI Resolution, ENUM
Resolution, ENUM telephone number to URI resolution, and the NAPTR telephone number to URI resolution, and the NAPTR DNS resource
DNS resource record. 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.
skipping to change at page 10, line 49 skipping to change at page 11, line 10
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 2. RSerPool handles have no need for supporting any structure/
structure/syntax. 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.
skipping to change at page 19, line 22 skipping to change at page 19, line 32
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
destination as a pool, providing full transparent support for destination as a pool, providing full transparent support for server-
server-pooling and load sharing. If multiple endpoints register pooling and load sharing. If multiple endpoints register under a the
under a the same name, a server pool is effectively created. It also same name, a server pool is effectively created. It also allows
allows dynamic system scalability - members of a server pool can be dynamic system scalability - members of a server pool can be added or
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 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.
skipping to change at page 21, line 23 skipping to change at page 21, line 47
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
Table1: Comparison Against Requirements Table1: Comparison Against Requirements
4. Security Concerns 4. Security Considerations
This type of non-protocol document does not directly affect the This type of non-protocol document does not directly affect the
security of the Internet. security of the Internet.
5. Acknowledgements 5. IANA Considerations
This document creates no considerations for IANA.
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, 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 7. References
6.1 Normative References 7.1 Normative References
[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J. and A. [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and
Silverton, "Architecture for Reliable Server Pooling", A. Silverton, "Architecture for Reliable Server Pooling",
Internet-Draft draft-ietf-rserpool-arch-09, February 2005. draft-ietf-rserpool-arch-09 (work in progress), 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 7.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.
[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
Location Protocol (mSLP)", RFC 3528, April 2003. Service 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)", Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09
Internet-Draft draft-ietf-rserpool-asap-09, June 2004. (work in progress), 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)", Internet-Draft draft-ietf-rserpool-enrp-09, Protocol (ENRP)", draft-ietf-rserpool-enrp-09 (work in
July 2004. progress), July 2004.
[9] Bradner, S., "The Internet Standards Process -- Revision 3", [9] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 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
Aron J. Silverton (editor)
Motorola, Inc.
1301 East Algonquin Road
Mail Drop 2246
Schaumburg, IL 60196
USA
Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.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
Motorola, Inc.
1301 East Algonquin Road
Mail Drop 2246
Schaumburg, IL 60196
USA
Phone: +1-847-576-8747
Email: aron.j.silverton@motorola.com
Intellectual Property Statement 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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