draft-ietf-rserpool-comp-01.txt   draft-ietf-rserpool-comp-02.txt 
skipping to change at page 2, line ? skipping to change at page 2, line ?
Nokia Nokia
M. Tuexen M. Tuexen
Siemens AG Siemens AG
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
Cisco Cisco
L. Ong L. Ong
Ciena Ciena
Expires January 18, 2001 July 18, 2001 Expires May 21, 2001 November 21, 2001
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
<draft-ietf-rserpool-comp-01.txt> <draft-ietf-rserpool-comp-02.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 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 ?
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document compares some related protocols, which overlap the This document compares some related protocols, which overlap the
Reliable Server Pooling problem space. This document discusses the Reliable Server Pooling problem space. This document discusses the
applicability of these protocols for Reliable Server Pooling. It applicability of these protocols for Reliable Server Pooling. It
intends to show why these protocols are not sufficient to accomplish intends to show why these protocols are not sufficient to accomplish
the task of reliable server pooling. the task of reliable server pooling.
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.............................................................5 2.2 DNS.............................................................5
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.......................................8 2.3 Service Location Protocol (SLP..................................8
3 Security Concerns...................................................9 2.3.1 mSLP.........................................................9
4 Acknowledgements....................................................9 3 Comparison Against Requirements....................................9
5 References..........................................................9 4 Security Concerns..................................................10
6 Authors' Addresses.................................................10 5 Acknowledgements...................................................10
6 References.........................................................10
7 Authors' Addresses.................................................11
Full Copyright Statement.............................................12
1. Introduction 1 Introduction
1.1. Overview 1.1 Overview
In creating a solution to provide reliable server pools [RSER-ARCH], In creating a solution to provide reliable server pools [RSER-ARCH],
there are a number of existing protocols, which appear to have there are a number of existing protocols, which appear to have
similar properties as to what RSerPool is trying to accomplish. similar properties as to what RSerPool is trying to accomplish.
This document discusses why these protocols are not sufficient to This document discusses why these protocols are not sufficient to
meet the requirements of Reliable Server Pooling [RSER-REQ]. meet the requirements of Reliable Server Pooling [RSER-REQ].
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.
skipping to change at page 8, line 22 skipping to change at page 8, line 19
addresses plus port numbers) for reaching a set of currently addresses plus port numbers) for reaching a set of currently
operational servers inside the pool. In other words, in RSerPool we operational servers inside the pool. In other words, in RSerPool we
have the following mapping: have the following mapping:
Name a handle to a server pool, which is often distributed Name a handle to a server pool, which is often distributed
across multiple host machines across multiple host machines
Address IP addresses and port numbers to reach a set of Address IP addresses and port numbers to reach a set of
functionally identical (software) server entities. functionally identical (software) server entities.
2.3 Service Location Protocol 2.3 Service Location Protocol (SLP
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 functions simply acts as a cache and is
passive in this regard. The directory agent is optional and SLP can passive in this regard. The directory agent is optional and SLP can
skipping to change at page 9, line 36 skipping to change at page 9, line 34
this function. this function.
SLP relies on multicast for some functionality and in RSerPool SLP relies on multicast for some functionality and in RSerPool
multicast is optional. multicast is optional.
In summary, SLP meets some of the requirements needed for the name In summary, SLP meets some of the requirements needed for the name
service portion of RSerPool, but would require modifications to service portion of RSerPool, but would require modifications to
fully support the requirements for the name service. SLP does not fully support the requirements for the name service. SLP does not
address the transport of user messages. address the transport of user messages.
3 Security Concerns 2.3.1 mSLP
SLP alone does not fulfill RSERPOOL update requirements for
timeliness. This is achieved through mesh-enhancements to the
Service Location Protocol (mSLP) [MSLP].
These enhancements make it possible for SAs to know of only a subset
of all DAs. Mesh-enhanced SAs need only forward their registrations
to only one mesh-enhanced DA. The mesh takes care of forwarding the
message to the other DAs.
3 Comparison Against Requirements
This section attempts to create a comparison table to compare the
protocols which have been suggested as applicable to the RserPool
architecture.
| CORBA | DNS | SLP | ASAP | ENRP |
-----------------------------+-------+-----+-----+------+------+
Robustness | Y | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Failover Support | Y | P | P | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Communication Model | N | P | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Processing Power | N | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Support of RSerPool | N | Y | N | N | N |
Unaware Clients | | | | | |
-----------------------------+-------+-----+-----+------+------+
Registering and | N | P | P | Y | Y |
Deregistering | | | | | |
-----------------------------+-------+-----+-----+------+------+
Naming | Y | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Name Resolution only to | Y | N | Y | Y | Y |
Active Elements | | | | | |
-----------------------------+-------+-----+-----+------+------+
Server Selection Policies | Y | P | P | P | P |
-----------------------------+-------+-----+-----+------+------+
Timing Requirements and | N | N | Y | Y | Y |
Scaling | | | | | |
-----------------------------+-------+-----+-----+------+------+
Scalability | N | Y | Y | Y | Y |
-----------------------------+-------+-----+-----+------+------+
Security - General | N | P | P | P | P |
-----------------------------+-------+-----+-----+------+------+
Security - Name Space | N | P | P | P | P |
Services | | | | | |
-----------------------------+-------+-----+-----+------+------+
Y = Yes, meets requirement
P = Partially meets requirement
N = No, does not meet requirement
N/A = Not applicable
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.
4 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, Christopher Ross and Werner Vogels for their invaluable Holdrege, Christopher Ross and Werner Vogels for their invaluable
comments and suggestions. comments and suggestions.
5 References 6 References
[ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access
Protocol (ASAP)", draft-ietf-rserpool-asap-00.txt,
June, 2001. A work in progress.
[ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-00.txt,
June, 2001. A work inprogress.
[MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location
Protocol", draft-zhao-slp-da-interaction-12.txt,
July, 2001. A work in progress.
[RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server [RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server
Pooling" <draft-ietf-rserpool-arch-00.txt>, Work in Pooling" <draft-ietf-rserpool-arch-00.txt>, Work in
Progress, April 2001. Progress, April 2001.
[RSER-REQ] Tuexen, M. et al., "Requirements for Reliable Server [RSER-REQ] Tuexen, M. et al., "Requirements for Reliable Server
Pooling" <draft-ietf-rserpool-reqts-03.txt>, Work in Pooling" <draft-ietf-rserpool-reqts-03.txt>, Work in
Progress, May 2001. Progress, May 2001.
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC [RFC793] J. B. Postel, "Transmission Control Protocol", RFC
skipping to change at page 10, line 31 skipping to change at page 11, line 46
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [RFC2719] L. Ong et al., "Framework Architecture for Signaling
Transport", RFC 2719, October 1999. Transport", RFC 2719, October 1999.
[RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the [RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February location of services (DNS SRV)", RFC 2782, February
2000. 2000.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [RFC2960] R. R. Stewart et al., "Stream Control Transmission
Protocol", RFC 2960, November 2000. Protocol", RFC 2960, November 2000.
6 Authors' Addresses 7 Authors' Addresses
John Loughney John Loughney
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: john.loughney@nokia.com Email: john.loughney@nokia.com
Maureen Stillman Maureen Stillman
Nokia Nokia
skipping to change at line 490 skipping to change at page 12, line 37
Crystal Lake, Il 60012 Crystal Lake, Il 60012
USA USA
Email: rrs@cisco.com Email: rrs@cisco.com
Lyndon Ong Lyndon Ong
Ciena Ciena
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Email: lyong@ciena.com Email: lyong@ciena.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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