draft-ietf-rserpool-comp-00.txt   draft-ietf-rserpool-comp-01.txt 
Network Working Group J. Loughney (ed.) RserPool Working Group J. Loughney (ed.)
INTERNET DRAFT M. Stillman INTERNET DRAFT M. Stillman
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
Cienna Ciena
Expires October 1, 2001 May 1, 2001 Expires January 18, 2001 July 18, 2001
Comparison of Protocols for Reliable Server Pooling Comparison of Protocols for Reliable Server Pooling
<draft-ietf-rserpool-comp-00.txt> <draft-ietf-rserpool-comp-01.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 10, line ? skipping to change at page 2, line ?
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.
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. It intends to show why these Reliable Server Pooling problem space. This document discusses the
protocols are not sufficient to accomplish the task of reliable applicability of these protocols for Reliable Server Pooling. It
server pooling. intends to show why these protocols are not sufficient to accomplish
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 Introduction .................................................5 2.2.1 Requirements.................................................5
2.2.2 Requirements .................................................5 2.2.2 Technical Issues.............................................5
2.2.3 Technical Issues .............................................5 2.2.3 Name/Address Resolution......................................7
2.2.4 Name/Address Resolution ......................................7 2.3 Service Location Protocol.......................................8
2.3 Service Location Protocol .......................................7 3 Security Concerns...................................................9
3 Security Concerns...................................................8
4 Acknowledgements....................................................9 4 Acknowledgements....................................................9
5 References..........................................................9 5 References..........................................................9
6 Authors' Addresses..................................................9 6 Authors' Addresses.................................................10
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
In creating a solution to provide reliable server pools, there are a In creating a solution to provide reliable server pools [RSER-ARCH],
number of existing protocols which appear to have similar properties there are a number of existing protocols, which appear to have
as to what RSerPool is trying to accomplish. This document shows similar properties as to what RSerPool is trying to accomplish.
why these protocols are not sufficient to meet the requirements of This document discusses why these protocols are not sufficient to
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 work group members have suggested. highlight several protocols which working group members have
suggested.
1.2 Terminology 1.2 Terminology
This document uses the following terms: This document uses the following terms:
Operation scope: Operation scope - The part of the network visible to pool users
by a specific instance of the reliable server
The part of the network visible to pool users by a specific instance pooling protocols.
of the reliable server pooling protocols.
Pool (or server pool):
A collection of servers providing the same application
functionality.
Pool handle (or pool name):
A logical pointer to a pool. Each server pool will be identifiable
in the operation scope of the system by a unique pool handle or
"name".
Pool element: Pool - A collection of servers providing the same
application functionality. Also called a Server
Pool.
A server entity having registered to a pool. 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 handle or "name".
Also called a Pool Name.
Pool User: Pool element - A server entity having registered to a pool.
A server pool user. Pool User - A server pool user.
Pool Element Handle (or endpoint handle): Pool Element Handle - A logical pointer to a particular pool element
in a pool, consisting of the name of the pool
and a destination transport address of the pool
element. Also called an Endpoint Handle.
A logical pointer to a particular pool element in a pool, Name Space - A cohesive structure of pool names and
consisting of the name of the pool and a destination transport relations that may be queried by an internal or
address of the pool element. external agent.
Name Space: Name Server - Entity which the responsible for managing and
maintaining the name space within the RSerPool
operation scope.
A cohesive structure of pool names and relations that may be queried 1.3 Abbreviations
by an internal or external agent.
Name Server: DA: Directory Agent in SLP.
Entity which the responsible for managing and maintaining the name DPE: Distributed Processing Environment
space within the RSerPool operation scope.
1.3 Abbreviations CORBA: Common Object Request Broker Architecture.
DPE: Distributed Processing Environment OMG: Object Management Group
PE: Pool element PE: Pool element
PU: Pool user PU: Pool user
SLP: Service Location Protocol SA: Service Agent in SLP.
SLP: Service Location Protocol.
UA: User Agent in SLP.
2 Relation to Other Solutions 2 Relation to Other Solutions
This section is intended to cover some existing solutions which This section is intended to discuss the applicability of some
overlap somewhat with the problems space of RSerPool. existing solutions with regards to Reliable Server Pooling
requirements [RSER-REQ]. The protocols discussed have been
suggested as possibly overlapping with the problems space of
RSerPool.
2.1 CORBA 2.1 CORBA
Often referred to as a Distributed Processing Environment (DPE), Often referred to as a Distributed Processing Environment (DPE),
CORBA was mainly designed to provide location transparency for CORBA was mainly designed to provide location transparency for
distributed applications. However, the following limitations may distributed applications. However, the following limitations may
exist when applying CORBA to the design of real time fault-tolerant exist when applying CORBA to the design of real time fault-tolerant
system: system:
1.CORBA has not been focused on high availability. The recent CORBA has not been focused on high availability. The recent
development of a high availability version of CORBA by OMG may be a development of a high availability version of CORBA by OMG may be a
step in the right direction towards improving this situation. step in the right direction towards improving this situation.
Nevertheless, the maturity, implementability, and real-time Nevertheless, the maturity, implementability, and real-time
performance of the design is yet to be proven. performance of the design is yet to be proven.
2.CORBA's distribution model encourages an object-based view, i.e., CORBA's distribution model encourages an object-based view, i.e.,
each communication endpoint is normally an object. This level of each communication endpoint is normally an object. This level of
granularity is likely to be somewhat inefficient for designing real- granularity is likely to be somewhat inefficient for designing real-
time fault-tolerant applications. time fault-tolerant applications.
3.CORBA, in general, has a large signature that makes the use of it CORBA, in general, has a large signature that makes the use of it a
a challenge in real-time environments. Small devices with limited challenge in real-time environments. Small devices with limited
memory and CPU resource (e.g., H.323 or SIP terminals) will find memory and CPU resource (e.g., H.323 or SIP terminals) will find
CORBA hard to fit in. CORBA hard to fit in.
4.CORBA has lacked easily usable support for the asynchronous CORBA has lacked easily usable support for the asynchronous
communication model, and this may be an issue in many applications. communication model, and this may be an issue in many applications.
An improved API for asynchronous communication has been added to the An improved API for asynchronous communication has been added to the
CORBA standards recently, but many, if not most, CORBA CORBA standards recently, but many, if not most, CORBA
implementations do not yet support it. There is as yet insufficient implementations do not yet support it. There is as yet insufficient
user experience with it to make conclusions regarding this feature's user experience with it to make conclusions regarding this feature's
usability. usability.
2.2 DNS 2.2 DNS
2.2.1 Introduction
This section will answer the question why DNS is not appropriate as This section will answer the question why DNS is not appropriate as
the sole solution for RSerPool. In addition, it highlights specific the sole solution for RSerPool. In addition, it highlights specific
technical differences between RSerPool and DNS. technical differences between RSerPool and DNS.
During the 49th IETF December 13, 2000 plenary meeting Randy Bush During the 49th IETF December 13, 2000 plenary meeting Randy Bush
presented a talk entitled "The DNS Today: Are we Overloading the presented a talk entitled "The DNS Today: Are we overloading the
Saddlebags on an Old Horse?" This talk underlined the issue that DNS Saddlebags on an Old Horse?" This talk underlined the issue that DNS
is currently overloaded with extraneous tasks and has the potential is currently overloaded with extraneous tasks and has the potential
to break down entirely due to a growing number of feature to break down entirely due to a growing number of feature
enhancements. enhancements.
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.2 Requirements 2.2.1 Requirements
Any solution for RSerPool should meet certain requirements [RSER- Any solution for RSerPool should meet certain requirements [RSER-
REQ]. These requirements are related to DNS. REQ]. 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 deregister
from a server pool transparently without an interruption in from a server pool transparently without an interruption in
service. service.
The RSerPool mechanisms must be able to support different server The RSerPool mechanisms must be able to support different server
selection mechanisms. These are called server pool policies. selection mechanisms. These are called server pool policies.
The RSerPool architecture must be able to detect server failure The RSerPool architecture must be able to detect server failure
quickly and be able to perform failover without service quickly and be able to perform failover without service
interruption. interruption.
Server pools are identified by pool handles. These pool handles Server pools are identified by pool handles. These pool handles
are only valid inside the operation scope. Interoperability are only valid inside the operation scope. Interoperability
between different namespaces has to be provided by other between different namespaces has to be provided by other
mechanisms. mechanisms.
2.2.3 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.3.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
stub resolvers - which means that they require their local DNS stub resolvers - which means that they require their local DNS
servers to do recursion for them. servers to do recursion for them.
In turn, this implies that setting TTL low or 0 will dramatically In turn, this implies that setting TTL low or 0 will dramatically
increase the load not only on the authoritative DNS servers - but increase the load not only on the authoritative DNS servers - but
also on these third party servers. also on these third party servers.
A secondary effect of this is that the authoritative DNS will not A secondary effect of this is that the authoritative DNS will not
skipping to change at page 10, line ? skipping to change at page 6, line 30
sufficient because the issues would still exist for all the legacy sufficient because the issues would still exist for all the legacy
systems, which will form the bulk of the host population for years systems, which will form the bulk of the host population for years
to come. The solution is not to use third party servers. 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.
2.2.3.2 Dynamic Registration Finally, DNS is based on a recursion. This recursion presents
certain difficulties for RSerPool. Even if a host resolver is not a
stub resolver, it has to go to another full resolver where 2
possibilities exists: either the mapping name-IP address is found or
it has to do another recursive resolution of the name, staring from
that intermediate resolver, until there is a cache hit in one of the
intermediate resolvers or it is resolved by its root resolver (or
home DNS server).
This process of recursion means that there is no end-to-end
communication between the host and its server where the name-to-IP
mapping resides. That also means that a lot of timers are running in
intermediate systems. Any updating of the transient status of the
pool element or of the pool may need to be propagated through the
DNS.
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 to register themselves RSerPool MUST allow software server entities 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 de-registered by for purposes of preventative maintenance or can be de-registered by
a name server that believes the server entity is no longer a name server that believes the server entity is no longer
operational. This is a dynamic approach, which is coordinated operational. This is a dynamic approach, which is coordinated
through servers in the pool and among RSerPool name servers. through servers in the pool and among RSerPool name servers.
2.2.3.2 Load Balancing 2.2.2.3 Load Balancing
RFC 2782 itself points out some of the limitations of using DNS SRV RFC 2782 itself points out some of the limitations of using DNS SRV
for load balancing between servers. for load balancing between servers.
Weight is only intended for static, not dynamic, server Weight is only intended for static, not dynamic, server
selection. Using SRV weight for dynamic server selection would selection. Using SRV weight for dynamic server selection would
require assigning unreasonably short TTLs to the SRV RRs, require assigning unreasonably short TTLs to the SRV RRs,
which would limit the usefulness of the DNS caching mechanism, which would limit the usefulness of the DNS caching mechanism,
thus increasing overall network load and decreasing overall thus increasing overall network load and decreasing overall
reliability. reliability.
skipping to change at page 10, line ? skipping to change at page 7, line 24
Weight is only intended for static, not dynamic, server Weight is only intended for static, not dynamic, server
selection. Using SRV weight for dynamic server selection would selection. Using SRV weight for dynamic server selection would
require assigning unreasonably short TTLs to the SRV RRs, require assigning unreasonably short TTLs to the SRV RRs,
which would limit the usefulness of the DNS caching mechanism, which would limit the usefulness of the DNS caching mechanism,
thus increasing overall network load and decreasing overall thus increasing overall network load and decreasing overall
reliability. reliability.
Based on this, DNS can only really support stochastic load Based on this, DNS can only really support stochastic load
balancing, redirecting clients to servers randomly as various caches balancing, redirecting clients to servers randomly as various caches
in various resolvers expire at random (although small) intervals. in various resolvers expire at random (although small) intervals.
DNS offers excellent network scalability but poor control over load DNS offers excellent network scalability but poor control over load
balance. balance.
As mentioned previously, the issue of doing DNS-based dynamic load As mentioned previously, the issue of doing DNS-based dynamic load
balancing on short time scales will have impacts on third parties, balancing on short time scales will have impacts on third parties,
due to the presence of stub resolvers. due to the presence of stub resolvers.
2.2.3.5 Heartbeating / Status Monitoring 2.2.2.4 Heartbeating / Status Monitoring
DNS does not incorporate an application layer heartbeat. DNS does not incorporate an application layer heartbeat.
Heartbeating would dramatically boost traffic levels, and given the Heartbeating would dramatically boost traffic levels, and given the
unavoidable third party dependencies of DNS, the resulting loading unavoidable third party dependencies of DNS, the resulting loading
would be unacceptable. It is passive in the sense that it does not would be unacceptable. It is passive in the sense that it does not
monitor or store information on the state of the host such as monitor or store information on the state of the host such as
whether the host is up or down or what kind of load it is currently whether the host is up or down or what kind of load it is currently
experiencing. experiencing.
RSerPool SHOULD monitor the state of each server entity on various RSerPool SHOULD monitor the state of each server entity on various
hosts on a continual basis and can collect several state variables hosts on a continual basis and can collect several state variables
including up/down state and current load. If a server is no longer including up/down state and current load. If a server is no longer
operational, eventually it will be dropped from the list of operational, eventually it will be dropped from the list of
available servers maintained by the name server, so that subsequent available servers maintained by the name server, so that subsequent
application name queries will not resolve to this server address. application name queries will not resolve to this server address.
2.2.4 Name/Address Resolution 2.2.3 Name/Address Resolution
The technical requirement for DNS name/address resolution is that The technical requirement for DNS name/address resolution is that
given a name, find a host associated with this name and return its given a name, find a host associated with this name and return its
IP address(es). In other words, in DNS we have the following IP address(es). In other words, in DNS we have the following
mapping: mapping:
- name -> a host machine Name a host machine
- address(es) -> IP address(es) to reach that (hardware) host
machine Address(es) IP address(es) to reach a (hardware) host machine
The technical requirement for RSerPool name/address resolution is The technical requirement for RSerPool name/address resolution is
that given a name (or pool handle), find a server pool associated that given a name (or pool handle), find a server pool associated
with this name and return a list of transport addresses (i.e., IP with this name and return a list of transport addresses (i.e., IP
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 is comprised of three components: User agent, service agents and SLP is comprised of three components: User Agents (UA), Service
directory agents. User agents work on the user's behalf to contact a Agents (SA) and Directory Agents (DA). User agents work on the
service. The UA retrieves service information from service agents or user's behalf to contact a service. The UA retrieves service
directory agents. A service agent works on behalf of one or more information from service agents or directory agents. A service agent
services to advertise services. A directory agent collects service works on behalf of one or more services to advertise services. A
advertisements. directory agent collects service advertisements.
The directory agent of SLP functions simply as a cache and is The directory agent of SLP functions simply acts as a cache and is
passive in this regard. Also, the directory agent is optional and passive in this regard. The directory agent is optional and SLP can
SLP can function without it. It is incumbent upon the servers to function without it. It is incumbent upon the servers to update the
update the cache as necessary by reregistering. The directory server cache as necessary by reregistering. The directory server is not
is not required in small networks as the user agents can contact required in small networks as the user agents can contact service
service agents directly using multicast. User agents are encouraged agents directly using multicast. Unicast queries to SAs are possible
to locate a directory at regular intervals if they can't find one subsequent to the UA having discovered them. User agents are
initially. encouraged to locate a directory at regular intervals if they can't
find one initially, otherwise they can detect DAs by listening
passively for DA advertisements.
The most fundamental difference between SLP and RSerPool is that SLP The most fundamental difference between SLP and RSerPool is that SLP
is service-oriented while RSerPool is communication-oriented. More is service-oriented while RSerPool is communication-oriented. More
specifically, what SLP provides to its user is a mapping function specifically, what SLP provides to its user is a mapping function
from a name of a service to the location of the service provider, in from a name of a service to the location of the service provider, in
the form of a URL string. Whether the service provider is reachable the form of a URL string. The availability of the service provider
and how to access it by the URL are out of the scope of SLP. is outside of the scope of SLP. How a service is accessable can be
described by the SLP attribute list associated with the service URL.
SLP is essentially a discovery protocol, not a transport protocol.
Therefore, the granularity of SLP operation is at application Therefore, the granularity of SLP operation is at application
service level. service level.
In contrast, what RSerPool provides to its user is a mapping In contrast, RSerPool provides to its user is a mapping function
function from a communication destination name to a set of routable from a communication destination name to a set of routable and
and reachable transport addresses that leads to a group of reachable transport addresses that leads to a group of distributed
distributed software server entities registered under that name that software server entities registered under that name that
collectively represent the named communication destination. RSerPool collectively represent the named communication destination. With
also takes the responsibility of reliably delivering a user message respect to SLP, this information could be represented in SLP
to one of these server entities. What service(s) this group of attributes. RserPool, however, also has the responsibility of
servers are providing at the application level or whether the group reliably delivering a user message to one of these server entities.
is just a component of an application service provider is out of the
scope of RSerPool. In other words, the granularity of RSerPool
operation is at communication server entity level.
Moreover, RSerPool is designed to be a distributed fault-tolerant What service(s) a group of servers are providing at the application
and real time translation service. SLP does not state either of level or whether the group is just a component of an application
these as design requirements and thus does not attempt to fulfill service provider is out of the scope of RSerPool. In other words,
them. In addition, SLP defines optional security features which the granularity of RSerPool operation is at communication server
support authentication and integrity. These are mandatory to entity level.
implement but optional in terms of use. RSerPool has stronger
security requirements. Moreover, RSerPool requires a distributed fault-tolerance and real-
time translation services. SLP does not state either of these as
design requirements and thus does not attempt to fulfill them. In
addition, SLP defines optional security features, which support
authentication and integrity. SLP requires IPSec to fully meet the
Security Requirements of RserPool.
The SLP directory agent does not support fault tolerance or The SLP directory agent does not support fault tolerance or
robustness in contrast to the name servers which do support it. The robustness in contrast to the name servers, which do support it.
name servers also monitor the state of the servers which are The name servers also monitor the state of the servers, which are
registered in the pool but the SLP directory agents do not perform registered in the pool, but the SLP directory agents do not perform
this function. SLP uses multicast and in RSerPool multicast is this function.
optional.
SLP relies on multicast for some functionality and in RSerPool
multicast is optional.
In summary, SLP meets some of the requirements needed for the name
service portion of RSerPool, but would require modifications to
fully support the requirements for the name service. SLP does not
address the transport of user messages.
3 Security Concerns 3 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 4 Acknowledgements
The authors would like to thank Bernard Aboba, Matt Holdrege, The authors would like to thank Bernard Aboba, Erik Guttman, Matt
Christopher Ross, Werner Vogels and many others for their Holdrege, Christopher Ross and Werner Vogels for their invaluable
invaluable comments and suggestions. comments and suggestions.
5 References 5 References
[RSER-REQ] Tuexen, M. et. al, "Requirements for Reliable Server [RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server
Pooling" <draft-ietf-rserpool-reqts-02.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
Pooling" <draft-ietf-rserpool-reqts-03.txt>, Work in
Progress, May 2001.
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC [RFC793] J. B. Postel, "Transmission Control Protocol", RFC
793, September 1981. 793, September 1981.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol
(FTP)", RFC 959, October 1985. (FTP)", RFC 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process - [RFC2026] S. Bradner, "The Internet Standards Process -
Revision 3", RFC 2026, October 1996. Revision 3", RFC 2026, October 1996.
[RFC2608] E. Guttman et al., "Service Location Protocol, [RFC2608] E. Guttman et al., "Service Location Protocol,
skipping to change at page 10, line ? skipping to change at page 10, line 33
[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 6 Authors' Addresses
John Loughney Tel.: +358 40 749 9122 John Loughney
Nokia Research Center e-mail: john.loughney@nokia.com Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: john.loughney@nokia.com
Maureen Stillman Tel.: +1 607 273 0724 62 Maureen Stillman
Nokia e-mail: maureen.stillman@nokia.com Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Email: maureen.stillman@nokia.com
Michael Tuexen Tel.: +49 89 722 47210 Michael Tuexen
Siemens AG e-mail: Michael.Tuexen@icn.siemens.de Siemens AG
ICN WN CS SE 51 ICN WN CS SE 51
D-81359 Munich D-81359 Munich
Germany Germany
Email: Michael.Tuexen@icn.siemens.de
Qiaobing Xie Tel.: +1 847 632 3028 Qiaobing Xie
Motorola, Inc. e-mail: qxie1@email.mot.com Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, Il 60004 Arlington Heights, Il 60004
USA USA
Email: qxie1@email.mot.com
Randall Stewart Tel.: +1 815 477 2127 Randall Stewart
Cisco Systems, Inc. e-mail: rrs@cisco.com Cisco Systems, Inc.
24 Burning Bush Trail 24 Burning Bush Trail
Crystal Lake, Il 60012 Crystal Lake, Il 60012
USA USA
Email: rrs@cisco.com
Lyndon Ong Lyndon Ong
Cienna Ciena
10480 Ridgeview Court
Cupertino, CA 95014
USA
Email: lyong@ciena.com
 End of changes. 

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