One document matched: draft-zhao-slp-da-interaction-03.txt
Differences from draft-zhao-slp-da-interaction-02.txt
INTERNET DRAFT Weibin Zhao
Service Location Group Henning Schulzrinne
draft-zhao-slp-da-interaction-03.txt Columbia University
Expires: November 5, 2000 May 5, 2000
Interaction of SLP Directory Agents for Reliability and Scalability
draft-zhao-slp-da-interaction-03.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 presents a scheme for the interaction of Directory
Agents (DAs) in SLPv2 (Service Location Protocol, Version 2). It
proposes to use a fully meshed peering DA architecture. Peer DAs
exchange service registration information, and maintain the same
consistent data for the shared scopes. This scheme provides a
reliable directory service for an SLP system. It also greatly
simplifies SLP service registration leading to a thin-client Service
Agent (SA) implementation. It is backward compatible with SLPv2, and
incremental deployment is supported.
1. Introduction
In the Service Location Protocol (RFC 2608 [1]), Directory Agents
(DAs) are introduced for caching service advertisements from Service
Agents (SAs), and answering queries from User Agents (UAs). They
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 1]
Internet Draft DA Interaction May 5, 2000
exist to enhance the performance and scalability of SLP.
When multiple DAs are present, how should they interact with each
other? This is an open issue in SLPv2. This document presents a
scheme for the interaction of SLP DAs to provide a reliable directory
service. We propose that if DAs are needed in an SLP system, a fully
meshed peering DA architecture should be used, i.e., more than one DA
should be present for each scope, and they should maintain a fully
meshed peer relationship (similar to IBGP [2]). Peer DAs exchange
their data for the shared scopes when they set up a peer
relationship, and continue to exchange new service registration
information during the entire peering period. As a result, they
maintain the same consistent data for the shared scopes. This scheme
also greatly simplifies SLP service registration leading to a thin-
client Service Agent (SA) implementation. Therefore, the scalability
of an SLP system can also be enhanced. It is entirely backward
compatible with SLPv2, and incremental deployment is supported.
The remainder of this document is organized as follows: Section 2
defines the terminology. Section 3 reviews the current DA message
flows in SLPv2. In Section 4, we describe the DA peer relationship.
In Section 5, we present the message forwarding control among DAs. We
discuss our design in Section 6, and give security considerations in
Section 7.
2. Terminology
Peer DAs
If two DAs have one or more scopes in common within one
administrative domain, they are peers. Peer DAs
coordinate with each other and store the same consistent
data for the shared scopes.
Peering TCP connection
A persistent TCP connection that is kept between a pair
of peer DAs for the entire peering period. It provides
a reliable communication channel for the peer DAs to
exchange messages. Therefore, a DA implementation is not
burdened by managing message retransmissions. Its
closing can be an indication of the termination of the
peer relationship.
Mesh-enhanced DA
A DA who maintains a peering TCP connection to each of
its peers and forwards service registration information
to its peers according to the rules given in this
document. A mesh-enhanced DA MUST carry the "mesh-
enhanced" attribute in its DAAdvert messages.
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 2]
Internet Draft DA Interaction May 5, 2000
Mesh-aware SA
An SA who understands the "mesh-enhanced" attribute in a
DAAdvert message and uses the mesh-enhanced DA
capability accordingly.
3. DA Message Flows in SLPv2
This section reviews the current DA message flows in SLPv2. Figure 1
illustrates SA registrations with DAs. For each service registration
(SrvReg) and deregistration (SrvDeReg) message, a DA replies with a
service acknowledgment (SrvAck) message.
+----+ +----+
| | --- SrvReg/SrvDeReg --> | |
| SA | | DA |
| | <------- SrvAck ------- | |
+----+ +----+
Figure 1. SA Registrations
Figure 2 shows UA queries with DAs. A DA replies with a service reply
(SrvRply) message to a service request (SrvRqst) message, a service
type reply (SrvTypeRply) message to a service type request
(SrvTypeRqst) message, and an attribute reply (AttrRply) message to
an attribute request (AttrRqst) message.
+----+ +----+
| | ----- SrvTypeRqst/SrvRqst/AttrRqst ----> | |
| UA | | DA |
| | <---- SrvTypeRply/SrvRply/AttrRply ----- | |
+----+ +----+
Figure 2. UA Queries
Figure 3 depicts DA discovery. A DA replies with a unicast DA
advertisement (DAAdvert) message to a multicast SrvRqst message which
has "service:directory-agent" as service type.
+-------+ Multicast SrvRqst +----+
| | ----- (service:directory-agent) ----> | |
| UA/SA | | DA |
| | <-------- Unicast DAAdvert ---------- | |
+-------+ +----+
Figure 3. DA Discovery
Figure 4 shows DA advertisements which are multicast periodically.
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 3]
Internet Draft DA Interaction May 5, 2000
+----+ +-------+
| | | |
| DA | ---- Multicast DAAdvert ---> | UA/SA |
| | | |
+----+ +-------+
Figure 4. DA Advertisement
From Figure 1 to 4, we can see that SLPv2 does not define the message
flows among DAs. We will define these flows for the interaction of
DAs and refine above flows in the following sections.
4. Peer Relationship
We use a set of fully meshed TCP connections among peer DAs. A peer
relationship has three stages: setting up, keeping and tearing down.
We describe each stage in detail next.
4.1. Setting Up a Peer Relationship
In SLP, each DA periodically sends DA Advertisement (DAAdvert)
messages to the administratively scoped SLP multicast [3] address
(239.255.255.253). All DAs listen to this address. Figure 5
illustrates the DAAdvert messages from mesh-enhanced DAs.
+-----+ +-----------+
| | | |
| DA1 | ------- Multicast DAAdvert ------> | DA2/UA/SA |
| | [attr = mesh-enhanced] | |
+-----+ +-----------+
Figure 5. Mesh-enhanced DA Advertisement
A mesh-enhanced DA MUST maintain 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 peer
list SHOULD include peer URL, shared scopes, boot timestamp, and
peering TCP connection ID. The boot timestamp is to identify a
rebooted peer. The peering TCP connection is used for message
forwarding.
When a mesh-enhanced DA learns about a new peer, it MUST create a
peering TCP connection to the peer at the SLP reserved port 427 if
such connection does not yet exist. Then it sends a DAAdvert message
with the "peering-connection-indication" attribute through this
channel to notify the peer that this is a peering TCP connection
(Figure 6). Thus, the peer can also use this channel to forward
messages in opposite direction.
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 4]
Internet Draft DA Interaction May 5, 2000
+-----+ +-----+
| | [attr = peering-connection-indication] | |
| DA1 | <------------ DAAdvert (TCP) ------------- | DA2 |
| | | |
+-----+ +-----+
Figure 6. Peering Connection Indication
After the peering TCP connection is established or identified, peer
DAs begin to forward new service registration information to each
other via this channel. At the same time, a mesh-enhanced DA SHOULD
decide whether it needs to get the data from its new peers. For
example, when a newly booted DA joins a peering DA set of three DAs,
it needs to get a copy of the existing registration data from one of
the three DAs, but not from all of them, which incurs a lot of
redundant transmissions. To do this, it sends a DAAdvert message with
the "data-copy-request" attribute to the chosen peer (Figure 7). On
the other end, when a mesh-enhanced DA receives the "data-copy-
request" in a DAAdvert message, it dumps all the data of the shared
scopes to the requesting DA. Each data record is sent as a SrvReg
message, with a re-calculated new lifetime (= old lifetime - elapsed
time). After exchanging their data in both directions, peer DAs have
the same consistent data for the shared scopes.
+-----+ [attr = data-copy-request] +-----+
| | --------- DAAdvert (TCP) --------> | |
| DA1 | | DA2 |
| | <--------- SrvReg (TCP) ---------- | |
+-----+ (data of shared scopes) +-----+
Figure 7. Dumping Data
4.2. Keeping a Peer Relationship
In 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 mesh-enhanced DA SHOULD send a DAAdvert message
with the "keepalive" attribute via the channel every
CONFIG_DA_KEEPALIVE (< CONFIG_CLOSE_CONN) seconds (Figure 8).
+-----+ +-----+
| | | |
| DA1 | ------------ DAAdvert (TCP) ------------> | DA2 |
| | [attr = keepalive] | |
+-----+ +-----+
Figure 8. DA Keepalive
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 5]
Internet Draft DA Interaction May 5, 2000
4.3. Tearing Down a Peer Relationship
A mesh-enhanced DA SHOULD tear down a peer relationship when it finds
that the peer has closed the peering TCP connection; when it receives
a multicast DAAdvert message from the peer with a DA stateless boot
timestamp set to 0 meaning the peer is going to shutdown; or when it
has not received the keepalive DAAdvert message from the peer for
more than CONFIG_DA_KEEPALIVE seconds. In the last case, there may be
a network partition and peer DA states get inconsistent.
To tear down a peer relationship, a DA stops forwarding any service
registration information to this peer, closes TCP connection with
this peer, and removes this peer from its peer list.
5. Message Forwarding Control
During the peering period, peer DAs forward new service registration
information from SAs to each other. We define a new SLP extension -
"mesh-forwarding extension" for the message forwarding purpose. This
extension is always six bytes long: five-byte extension header and
one-byte extension data denoted as "Action" field. The "Action" field
is used to specify forwarding actions: TO_BE_FORWARDED marks the
message needs to be forwarded; HAS_BEEN_FORWARDED means the message
has already been forwarded, and there is no need to be forwarded
again. Figure 9 illustrates its format. The message forwarding rules
are as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mesh-Forwarding Extension ID | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, contd. | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Mesh-Forwarding Extension
(1) Explicit Forwarding: A message is forwarded only when it
explicitely requests to be forwarded. A mesh-aware SA needs to
attach the mesh-forwarding extension to a Srv(De)Reg message and set
the "Action" field to TO_BE_FORWARDED if it wants the message to be
forwarded by a mesh-enhanced DA. This is for the compatibility with
SLPv2, where SAs need to register with all existing DAs. To avoid
unnecessary forwarding, the explicit forwarding rule is used.
(2) One-hop Forwarding: A Srv(De)Reg message is forwarded only once
by a mesh-enhanced DA to all its peers in the registration scope.
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 6]
Internet Draft DA Interaction May 5, 2000
Before forwarding a message, a mesh-enhanced DA sets the "Action"
field in the mesh-forwarding extension to HAS_BEEN_FORWARDED. In
this way, a forwarded message will never be forwarded again. Since
the peering DA set is in a fully connected mesh, one-hop forwarding
is enough to ensure that a message can reach all peer DAs. Figure 10
shows how a Srv(De)Reg message is forwarded.
+----+ (TO_BE_FORWARDED) +-----+ (HAS_BEEN_FORWARDED) +-----+
| | -- SrvReg/SrvDeReg -> | | -- SrvReg/SrvDeReg -> | |
| SA | | DA1 | | DA2 |
| | <------ SrvAck ------ | | <------ SrvAck ------ | |
+----+ +-----+ +-----+
Figure 10. Forwarding Registration
(3) Handling SrvAck: A DA always replies with a SrvAck message when
it receives a Srv(De)Reg message. So a mesh-enhanced DA SHOULD
process SrvAck messages from other DAs.
6. Design Discussion
In this section, we discuss several important design issues, i.e.,
identifying forwarded messages, simplifying SA registrations, and
forwarding UA queries. We also give comments on reliability,
scalability, compatibility, and deployment for our design.
6.1 Identifying Forwarded Messages
Since a forwarded message has the mesh-forwarding extension and its
"Action" field is HAS_BEEN_FORWARDED, it can be easily identified. A
forwarded Srv(De)Reg message SHOULD not be forwarded again.
6.2 Simplifying SA Registrations
A mesh-aware SA only needs to register with one mesh-enhanced DA in
the registration scope. The information will be propagated
automatically within the peering DA set. Thus, a mesh-aware SA does
not need to implement the complicated algorithm to register with all
existing DAs and to re-register when new mesh-enhanced DAs are
discovered, or old mesh-enhanced DAs are found to have rebooted.
6.3 Forwarding UA Queries
A further extension to the interaction of SLP DAs is to forward UA
queries besides SA registrations. It works as follows: When a mesh-
enhanced DA receives a UA query which is not in its scope, it
forwards the query to another DA which supports the scope. This can
simplify UA implementation since UAs do not need to keep track of DA
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 7]
Internet Draft DA Interaction May 5, 2000
scopes. A UA can send its queries to any mesh-enhanced DA. However,
this adds much complexity to the mesh-enhanced DA implementation.
First, a mesh-enhanced DA needs to keep track of all DAs of all
scopes, not only the DAs that share some scopes with it. Second, a
mesh-enhanced DA needs to forward the query to another DA, and it
also needs to forward the reply from another DA back to the UA. We
did not include this extension in our scheme mainly due to its
complexity. However, for a thin-client UA implementation, it might
deserve further considerations.
6.4 Reliability
The fully meshed peering DA architecture provides maximum robustness.
It ensures that no single failure point exists in the SLP directory
service. All service registrations are kept by at least two DAs. If
one DA is down, at least one other peer DA can continue to provide
the service information for the scope. Moreover, the peering DA
architecture ensures the data consistency among peer DAs
automatically. It also enables a DA to recover from crash with much
less effort since a rebooted DA can get the existing data from its
peering DA set. This is done through DA coordination, no SA
involvement is needed.
6.5 Scalability
With mesh-enhanced DAs and simplified SAs, the overall SLP system
scalability can be enhanced. However, since we use a set of fully
meshed TCP connections among peer DAs, 2-4 is the recommended number
of DAs for each scope. There is no 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.
6.6 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. SAs can be simplified as
described in Section 6.2.
6.7 Deployment
Our design supports incremental deployment of mesh-enhanced DAs. A
mesh-enhanced DA can set up peer relationships with both mesh-
enhanced DAs and non-mesh-enhanced DAs. In the latter case, the
message forwarding only goes in uni-direction from the mesh-enhanced
DA to a non-mesh-enhanced DA. As we indicate in Section 6.2, a
mesh-aware SA only needs to register with one mesh-enhanced DA by
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 8]
Internet Draft DA Interaction May 5, 2000
using the mesh-forwarding extension. However, a mesh-aware SA SHOULD
take care of newly found non-mesh-enhanced DAs and rebooted non-
mesh-enhanced DAs since these non-mesh-enhanced DAs can not get the
existing data from other DAs. Therefore, uniformly mesh-enhanced DAs
can provide a much easier job for mesh-aware SAs.
7 Security Considerations
The DA authentication is more important in this scheme, since SAs
will have to trust the DA they are sending the Srv(De)Reg messages to
forward them. DAs can use standard SLPv2 DA authentication to
authenticate other DAs in the mesh.
8. References
[1] E. Guttman, C. Perkins, J. Veizades, M. Day,
"Service Location Protocol Version 2", RFC 2608, June 1999.
[2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995
[3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365,
July 1998
9. Acknowledgments
Erik Guttman provided valuable comments and suggestions for this
draft.
10. Authors' Addresses
Weibin Zhao
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
email: zwb@cs.columbia.edu
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
email: hgs@cs.columbia.edu
W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:24 |