One document matched: draft-zhao-slp-da-interaction-02.txt
Differences from draft-zhao-slp-da-interaction-01.txt
INTERNET DRAFT Weibin Zhao
Service Location Group Henning Schulzrinne
draft-zhao-slp-da-interaction-02.txt Columbia University
Expires: October 10, 2000 April 10, 2000
Interaction of SLP Directory Agents for Reliability and Scalability
draft-zhao-slp-da-interaction-02.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
service (de)registration messages, and keep the same consistent data
for each scope. This scheme can simplify Service Agent (SA)
registrations, and it is entirely backward compatible with SLPv2.
1. Introduction
In the Service Location Protocol (RFC 2608 [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: October 10, 2000 [Page 1]
Internet Draft DA Interaction April 10, 2000
When multiple DAs present, how should they interact with each other?
This is an open issue in SLPv2. To enhance the reliability and
scalability of SLP DAs while keeping compatible with SLPv2, we
propose that DAs within one administrative domain 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 (de)registration (Srv(De)Reg)
messages during the entire peering period.
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 our message forwarding rules among DAs. We
discuss our design in Section 6. And finally, we 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 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. The closing
of it 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 Srv(De)Reg messages to its peers
according to the rules given in this document. A mesh-
enhanced DA MUST carry a "mesh-enhanced" attribute in
its DAAdvert messages.
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
(de)registration (Srv(De)Reg) message, a DA replies with a service
acknowledge (SrvAck) message.
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 2]
Internet Draft DA Interaction April 10, 2000
+----+ +----+
| | --- SrvReg/SrvDeReg --> | |
| SA | | DA |
| | <------- SrvAck ------- | |
+----+ +----+
Figure 1. SA Registrations
Figure 2 shows UA queries to 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.
+----+ +-------+
| | | |
| 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.
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 3]
Internet Draft DA Interaction April 10, 2000
4. Peer Relationship
We use a set of fully meshed TCP connections among peer DAs. These
peering TCP connections provide reliable communication channels for
peer DAs to exchange messages. Therefore, a DA implementation is not
burdened by managing message retransmissions. A peer relationship
includes three stages: setting up, keeping and tearing down. We
describe each stage in details 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 of 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. And 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 exist yet. Then it sends a DAAdvert message
with a "peering-connection-indication" attribute through the TCP
channel to notify the peer that this is a peering connection (Figure
6). So that the peer, if it is also mesh-enhanced, can use this
peering connection to forward messages in opposite direction.
+-----+ +-----+
| | [attr = peering-connection-indication] | |
| DA1 | ------------- DAAdvert (TCP) ------------> | DA2 |
| | | |
+-----+ +-----+
Figure 6. Peering Connection Indication
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 4]
Internet Draft DA Interaction April 10, 2000
After peering TCP connection is established or identified, peer DAs
begin to forward new Srv(De)Reg messages to each other. At the same
time, a mesh-enhanced DA SHOULD decide whether it needs to get old
registration data from its peers. For example, when a newly booted
DA joins a mirrored DA set of five DAs, it needs to get a copy of the
existing registration data from one of the five DAs. However, it does
not need to download the old registration data from all five DAs,
which will bring a lot of redundant transmissions. To download the
shared data from a peer (must be mesh-enhanced), a mesh-enhanced DA
sends a DAAdvert message with a "data-copy-request" attribute to the
peer (Figure 7). The peer dumps the data of shared scopes as SrvReg
messages, with a re-calculated new lifetime (= old lifetime - elapsed
time). After they exchange their data in both directions, these two
peers 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 the peering
TCP connections alive, a mesh-enhanced DA SHOULD send a DAAdvert
message with a "keepalive" attribute to each of its peers via the
peering channel every CONFIG_DA_KEEPALIVE (< CONFIG_CLOSE_CONN)
seconds (Figure 8).
+-----+ +-----+
| | | |
| DA1 | ------------ DAAdvert (TCP) ------------> | DA2 |
| | [attr = keepalive] | |
+-----+ +-----+
Figure 8. DA Keepalive
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; or when it
receives a multicast DAAdvert message from the peer with a DA
Stateless Boot Timestamp set to 0; 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
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 5]
Internet Draft DA Interaction April 10, 2000
partition and peer DA states get inconsistent.
To tear down a peer relationship, a DA stops forwarding any
Srv(De)Reg messages to this peer, closes TCP connection with this
peer, and removes this peer from its peer list.
5. Message Forwarding Rules
(1) A Srv(De)Reg message MUST have a "Mesh Forward Extension" (MF-
extension) if it is aimed to be forwarded by a mesh-enhanced DA. The
MF-extension is always six bytes long. The one-byte Extension Data 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, no need to be forwarded again. Figure 9
illustrates its format. So, only when a Srv(De)Reg has an MF-
extension and its Action field is TO_BE_FORWARDED, it SHOULD be
forwarded.
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 Forward Extension = TBD | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, contd. | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Mesh Forward Extension
(2) A Srv(De)Reg message is forwarded from a mesh-enhanced DA to all
the peers in the registration scope. Before a message is forwarded,
its Action field in the MF-extension is changed from TO_BE_FORWARDED
to HAS_BEEN_FORWARDED. In this way, a message can only be forwarded
once. As the mirrored DAs are 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) 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.
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 6]
Internet Draft DA Interaction April 10, 2000
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
A forwarded message can be identified easily since it is received via
a peering TCP channel whose connection id is in the DA's peer list. A
forwarded Srv(De)Reg message MUST not be forwarded again.
6.2 Simplifying SA Registrations
A mesh-aware SA only needs to send its Srv(De)Reg messages to one
mesh-enhanced DA in the registration scope. The information will be
propagated automatically within the domain. 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.
A mesh-aware SA MUST include an MF-extension in its Srv(De)DeReg
messages in order for the messages to be forwarded by a mesh-enhanced
DA. The added MF-extension ensures that the Srv(De)Reg messages from
non-mesh-aware SAs are not forwarded by mesh-enhanced DAs.
6.3 Forwarding UA Queries
A further extension for 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
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 share some scopes with it. Second, 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.
We did not include this extension in our scheme mainly due to its
complexity. However, for thin-client UA implementation, it might
deserve further consideration.
6.4 Reliability
Adding more DAs increases reliability. For example, if you had more
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 7]
Internet Draft DA Interaction April 10, 2000
than one DA in each scope, when one DA is down, at least one other DA
can continue to provide the service for the scope. Mesh-enhanced DAs
ensure the data consistency among peer DAs automatically.
6.5 Scalability
With mesh-enhanced DAs and simplified SAs, the overall SLP system
scalability can be enhanced. However, since we use fully meshed TCP
connections among DAs, 2-4 DAs is the recommended value for each
scope. It does 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.
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 can only register with one mesh-enhanced DA by adding
an MF-extension to the messages. 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 old
data from other DAs. So uniformly mesh-enhanced DAs can provide a
much easy 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
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)",
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 8]
Internet Draft DA Interaction April 10, 2000
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
Columbia University
Department of Computer Science
1214 Amsterdam Ave.
New York, NY 10027-7003
email: zwb@cs.columbia.edu
Henning Schulzrinne
Columbia University
Department of Computer Science
1214 Amsterdam Ave.
New York, NY 10027-7003
email: hgs@cs.columbia.edu
W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:55 |