One document matched: draft-zhao-slp-da-interaction-00.txt
Interaction of SLP Directory Agents for Reliability and Scalability
draft-zhao-slp-da-interaction-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes a scheme for the interaction of Directory
Agents (DA) in SLPv2 (Service Location Protocol, Version 2). It aims
to provide a reliable and scalable directory service by maintaining a
peer relationship among a fully meshed DA set. Peer DAs exchange SLP
update messages (SrvReg and SrvDeReg), and keep the same consistent
data for each scope. This scheme is entirely backward compatible with
SLPv2. It simplifies Service Agent (SA) registrations and supports
User Agent (UA) query load balancing.
1. Introduction
In the Service Location Protocol (RFC 2068 [1]), Directory Agents
(DA) are introduced for caching service advertisements from Service
Agents (SA), and answering queries from User Agents (UA). They exist
to enhance the performance and scalability of SLP.
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 1]
Internet Draft DA Interaction November 15, 1999
When multiple DAs present, how should they interact with each other?
This is an open issue in SLPv2. With the goals of reliability,
scalability and compatibility with SLPv2, we propose that DAs within
one administrative domain maintain a fully meshed peer relationship
similar to IBGP [3]. Peer DAs exchange their data for the shared
scopes when they set up a peer relationship, and continue to exchange
new SLP update messages (SrvReg and SrvDeReg) during the entire
peering period.
In Section 2, we define the peer relationship for DAs, and describe
the steps for setting up, keeping and tearing down it. A persistent
TCP connection is used for this purpose between each pair of peers.
In Section 3, we present a simple data forwarding scheme among DAs by
using the REQUEST MCAST (R) bit in the flag field of the SLPv2
message header. In Section 4, we analyze our design for its
reliability, scalability and compatibility. We give recommendations
for implementation and deployment in Section 5. We outline and
compare other alternative designs in Section 6. Finally, we give
security considerations in Section 7.
2. Peer Relationship
We define the SLP DA peer relationship as follows: If two DAs have
one or more scopes in common within one administrative domain, they
are peers. Peer DAs store the same consistent data for the shared
scopes.
We use a set of fully meshed TCP connections among peer DAs. These
peering TCP connections are introduced for two reasons:
(1) They provide a reliable communication channel for each pair of
peer DAs to exchange messages. Therefore, a DA implementation
is not burdened by managing message retransmissions.
(2) A peering TCP connection is kept for the entire peering period
(persistent). The closing of it can be an indication of the
peer being down.
We call a DA is mesh-enhanced if it is in a mirrored DA set for each
of its scopes and maintains a persistent TCP connection to each of
its peers. A mesh-enhanced DA SHOULD add a "mesh-enhanced" keyword to
the attribute list in its DAAdvert messages.
A peer relationship includes three stages: setting up, keeping and
tearing down. We discuss each stage in detail next.
2.1. Setting Up a Peer Relationship
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 2]
Internet Draft DA Interaction November 15, 1999
In SLP, each DA periodically sends DA Advertisement messages
(DAAdvert) to the Administratively Scoped SLP Multicast [2] address
239.255.255.253. All DAs listen to this address.
When a DA receives a DAAdvert message from another DA, it checks the
<scope list> field in the message. If it shares some scopes with the
sender DA, they are peers.
A DA treats a new peer and an old peer differently.
(1) For a new peer, a DA needs to forward all its data for the shared
scopes to the peer.
(2) For an old peer, A DA only needs to forward the new SrvReg and
SrvDeReg messages to the peer.
Each DA maintains a peer list. It adds an entry to the list whenever
it discovers a new peer, and removes an entry when it finds the
corresponding peer is down. Each entry in this list includes peer
URL, boot timestamp, shared scopes, and peering TCP connection id.
A rebooted peer is treated as a new peer. If its URL is already in
the peer list, it should carry a boot timestamp that differs from its
previous one, so the DA needs to update its boot timestamp and close
the previous TCP connection to it.
When a DA learns about a new peer from a multicast DAAdvert message,
it replies with a unicast DAAdvert message to the sender DA
immediately. In this way, the first DA may know the second DA
quickly, and synchronize accordingly. The first DA may not need to
wait for the next multicast DAAdvert message from the second DA which
may delay a long period.
For a new peer, the DA creates a TCP connection to the peer at the
SLP reserved port 427, and sends a copy of its data belonging to the
shared scopes to the peer. Each data record is transferred as a
SrvReg message, with a re-calculated new lifetime: new lifetime =
old lifetime - elapsed time. For each SrvReg message, the DA sets the
(R) flag bit in the message header. The reason for doing this is
given in Section 3. After they exchange their data in both
directions, these two peers have the same consistent data for the
shared scopes.
2.2. Keeping a Peer Relationship
According to SLPv2, a DA could close an idle TCP connection after
CONFIG_CLOSE_CONN seconds (5 minutes at least). To keep a peering TCP
connection alive, a DA sends a SrvReg message for itself every
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 3]
Internet Draft DA Interaction November 15, 1999
CONFIG_CLOSE_CONN - 10 seconds.
We propose to define a new service type called service:da. Under this
service type, each DA sends its own SrvReg message (the (R) flag bit
in the message header needs to be set, see Section 3 for details) to
all its peers as well as put this information to its own database. As
an additional benefit of this, a UA can get a URL list of all DAs by
a SrvRqst message with service:da as service type.
To maintain a consistent data among the mirrored DA set for a scope,
a DA should forward each SLP update message (SrvReg or SrvDeReg) it
received from an SA to each of its peers in the registration scope.
For each forwarded message, the DA sets the (R) flag bit in the
message header. More details are given in Section 3.
2.3. Tearing Down a Peer Relationship
A DA should tear down a peer relationship when it receives an EOF
from this peer along the peering TCP connection, or when it gets an
exception while it tries to forward messages to this peer.
To tear down a peer relationship, a DA stops forwarding any SLP
update messages to this peer, closes TCP connection with this peer,
and removes this peer from its peer list.
3. Message Forwarding
When a DA receives an SLP update message (SrvReg or SrvDeReg) from an
SA, it forwards the message to all its peers, and replies with a
SrvAck message to the SA.
However, when a DA receives a forwarded message, it neither forwards
nor replies the message. There is no need to reply since the message
is forwarded via TCP, a reliable communication channel. The forwarded
message does not need to be further forwarded because the mirrored
DAs are in a fully connected mesh.
To decide that an SLP update message (SrvReg or SrvDeReg) is
forwarded or not, a DA works as follows:
(1) The sending DA sets the REQUEST MCAST (R) flag bit in the
message head when it forwards an SLP update message to a peer.
(2) The receiving DA checks the (R) flag bit in the message header
whenever it receives an SLP update message. If this bit is set,
the message is forwarded from a peer DA, otherwise it is from
an SA.
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 4]
Internet Draft DA Interaction November 15, 1999
Since in SLPv2, a SrvReg or SrvDeReg message is always unicasted from
an SA to a DA, the (R) flag bit in the message head is never used. So
a DA can use this bit for the message forwarding purpose. This bit is
only manipulated by DAs. SAs and UAs do not need to know about it.
However, an SA can intentionally set this bit to prevent message
forwarding among DAs if it wants to register to each DA separately.
Only SrvReg and SrvDeReg messages from SAs are forwarded by DAs. The
query messages from UAs are NOT forwarded. Figure 1 summarizes the
message exchanging and forwarding:
+----+ SrvDeReg +-----+
| | --- Unicast SrvReg --> | | SrvDeReg +-----+
| SA | | DA1 | -- Forward SrvReg --> | DA2 |
| | <-- Unicast SrvAck --- | | +-----+
+----+ +-----+
| SrvDeReg +-----+
+------ Forward SrvReg --> | DA3 |
+-----+
+----+ +----+
| | --- Unicast SrvRqst/SrvTypeRqst/AttrRqst --> | |
| UA | | DA |
| | <-- Unicast SrvRply/SrvTypeRply/AttrRply --- | |
+----+ +----+
Figure 1. Message Exchanging and Forwarding
4. Analysis
In this section, we demonstrate how our design can achieve
reliability, scalability, and compatibility with SLPv2.
4.1 Reliability
We propose that in each administration domain, at least two DAs
should be present for each scope to store the same consistent data of
SA advertisements. This is mainly for reliability, i.e., when one DA
is down, at least one other DA can continue to provide directory
service for the scope.
4.2 Scalability
The mesh-enhanced DAs also simplify SA registrations and support UA
load balancing, and thus improve the system performance and
scalability.
(1) An SA only needs to register its advertisements with one mesh-
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 5]
Internet Draft DA Interaction November 15, 1999
enhanced DA in the registration scope. The information will be
propagated automatically within the mirrored DA set.
An SA does not need to implement the complicated algorithm
for registrations with all existing DAs and re-registrations
when new DAs are discovered, or old DAs are found to have
rebooted.
(2) A UA can get the same query results from any DA in the query
scope. When there are a lot of UAs in the system, multiple
mesh-enhanced DAs support query load balancing for UAs.
Since we use fully meshed TCP connections among DAs, 2-3 DAs is the
recommended value for each scope. As an example, 3 TCP connections
are needed for a mirrored set of 3 DAs. This should not be a problem.
You do not need to have separate DA for each scope. A DA can serve
multiple scopes. And a peering TCP connection is used for all shared
scopes between each pair of peer DAs.
4.3 Compatibility
The scheme is fully backward compatible with SLPv2, It does not
introduce any new protocol elements. Only DAs are modified with the
mesh-enhanced function, and the changes are almost transparent to UAs
and SAs. UAs can be kept unchanged, or can be enhanced with load
balancing function as to which DA to query. SAs can be simplified as
described in Section 4.2.
5. Implementation and Deployment
A mesh-enhanced DA needs to implement the following functions:
(1) The functions to set up, keep, and tear down a peer relationship
with a peer DA. It needs to maintain a peer list for each scope
the DA supports.
(2) The mechanism to distinguish the forwarded messages from the
messages from SAs, and forward messages whenever needed.
(3) Adding "mesh-enhanced" keyword to the attribute list in DAAdvert
message to indicate the mesh-enhanced capability.
An SA SHOULD understand the "mesh-enhanced" attribute keyword in the
DAAdvert message, and ONLY register with one mesh-enhanced DA in the
registration scope.
A UA MAY understand the "mesh-enhanced" attribute keyword in the
DAAdvert message. It can get a URL list of all DAs by sending a
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 6]
Internet Draft DA Interaction November 15, 1999
SrvRqst message with service:da as service type, and use this
information to select a desired DA from the list.
For the deployment of mesh-enhanced DAs, we recommend that either ALL
or NONE DAs should be mesh-enhanced for a scope within one
administrative domain. Uniformly mesh-enhanced DAs provide a much
easy job for SAs and UAs.
6. Alternative Designs
We outline two alternative designs for the interaction of DAs here,
and discuss why we did not adopt them.
6.1 Inference-Message Forwarding
Intuitively, it seems we may not need a flag bit in the SLPv2 message
header for the message forwarding purpose since a DA can infer that
an SLP update message source is an SA or a DA. The inference works
like this: each time a DA receives an SLP update message, it checks
the source address of the message. If the source address is in its
peer list, the message is from a DA, otherwise, the message is from
an SA.
There are two problems with this design:
(1) If an SA and a DA are in the same host, the source-address-based
distinction fails.
(2) It might cause unnecessary copying if the DA sending the
forwarded message is not known to the DA receiving the message.
For example: DA1 receives a SrvReg message from an SA and
forwards it to DA2. DA2 does not know about DA1, so it forwards
the message to all the DAs in its peer list. This leads to
duplication since these DAs have already received the same
forwarded message from DA1.
Comparison: The unnecessary copying does not happen in our scheme
using a forwarding flag bit, i.e., REQUEST MCAST (R) bit in SLPv2
message header. A DA only forwards a message when the forwarding flag
bit in the message header is not set, and the DA set this bit before
forwarding the message.
6.2 Forwarding UA Queries
A further extension for the interaction of SLP DAs is to forward UA
queries as well as SA registrations. It works as follows: When a DA
receives a UA query which is not in its scope, it forwards the query
to another (appropriate) DA which supports the scope.
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 7]
Internet Draft DA Interaction November 15, 1999
This scheme can simplify UA implementation since UAs do not need to
keep track of DA scopes. A UA can send its queries to any mesh-
enhanced DA. But it adds much complexity to DA implementation:
(1) A mesh-enhanced DA needs to keep track of all DAs of all scopes,
not only the DAs share some scopes with it.
(2) A mesh-enhanced DA not only needs to forward the query to another
DA, but also needs to forward the reply from another DA back to
the UA.
Remarks: We did not adopt this extension due to its complexity.
However, if we want to have a thin-client implementation for UA, it
might deserve further consideration.
7. Security Considerations
We emphasis that it needs authentication for DAs to set up peer
relationship. SLPv2 already provides mechanism for doing this through
<SLP SPI List> and authentication blocks in the DAAdvert message.
8. References
[1] E. Guttman, C. Perkins, J. Veizades, M. Day,
"Service Location Protocol Version 2", RFC 2608, June 1999.
[2] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365,
July 1998
[3] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995
9. Acknowledgments
Erik Guttman provided valuable comments and suggestions for this
draft. Jonathan Lennox helped with the presentation.
10. Authors' Addresses
Weibin Zhao
Columbia University
Department of Computer Science
1214 Amsterdam Ave.
New York, NY 10027-7003
email: zwb@cs.columbia.edu
Henning Schulzrinne
Columbia University
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 8]
Internet Draft DA Interaction November 15, 1999
Department of Computer Science
1214 Amsterdam Ave.
New York, NY 10027-7003
email: hgs@cs.columbia.edu
W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:11 |