One document matched: draft-zhao-slp-da-interaction-01.txt
Differences from draft-zhao-slp-da-interaction-00.txt
INTERNET DRAFT Weibin Zhao
Service Location Group Henning Schulzrinne
draft-zhao-slp-da-interaction-01.txt Columbia University
Expires: September 10, 2000 March 10, 2000
Interaction of SLP Directory Agents for Reliability and Scalability
draft-zhao-slp-da-interaction-01.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: September 10, 2000 [Page 1]
Internet Draft DA Interaction March 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: September 10, 2000 [Page 2]
Internet Draft DA Interaction March 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: September 10, 2000 [Page 3]
Internet Draft DA Interaction March 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
When a mesh-enhanced DA (for example, DA2 in Figure 6) learns about a
new peer from a multicast DAAdvert message, it SHOULD wait a random
interval between 0 to 3 seconds and then replies with a unicast
DAAdvert message to indicate itself to the new peer.
+-----+ +-----+
| | ---- Multicast DAAdvert (UDP) ---> | |
| DA1 | | DA2 |
| | <---- Unicast DAAdvert (UDP) ----- | |
+-----+ (if DA1 is a new peer) +-----+
Figure 6. Peer Indication
The random delay introduced here is to ensure that all the DAs of the
same scope don't send their unicast replies at the same time. If they
did, the implosion of replies could potentially exceed the sending
DA's capacity to process incoming datagrams. To reply with a unicast
DAAdvert message when a new peer is discovered from a multicast
DAAdvert message can help peer DAs to know each other quickly, and
synchronize accordingly.
Each 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 list
W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 4]
Internet Draft DA Interaction March 10, 2000
includes peer URL, boot timestamp, shared scopes, and peering TCP
connection id. The boot timestamp is to identify a rebooted peer
whose URL is already in the peer list, but its DAAdvert message
carries a boot timestamp that differs from its previous one. A
rebooted peer should be treated as a new peer, its old entry in the
peer list should be replaced with the new entry. The peering TCP
connection id is initialized as NULL and will be filled in after the
peering TCP connection is established.
After replying with a unicast DAAdvert message to a new peer, a
mesh-enhanced DA creates a peering TCP connection to the peer at the
SLP reserved port 427. Then it sends a DAAdvert message with a
"peering-connection-indication" attribute through the TCP channel to
tell the peer that this is a peering connection (Figure 7) 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 7. Peering Connection Indication
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 8). 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 8. Dumping Data
W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 5]
Internet Draft DA Interaction March 10, 2000
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 9).
+-----+ +-----+
| | | |
| DA1 | ------------ DAAdvert (TCP) ------------> | DA2 |
| | [attr = keepalive] | |
+-----+ +-----+
Figure 9. 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
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) Only Srv(De)Reg messages with a "Mesh Forward Extension" (MF-
extension) trailer are forwarded by mesh-enhanced DAs. The MF-
extension includes no Extension Data; it is always five bytes long.
Figure 10 illustrates its format.
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, continued|
+-+-+-+-+-+-+-+-+
Figure 10. Mesh Forward Extension
W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 6]
Internet Draft DA Interaction March 10, 2000
(2) A Srv(De)Reg message is forwarded from a mesh-enhanced DA to all
its peers in the registration scope. The MF-extension is removed
from the forwarded message; and all the affected Next Extension
Offsets in the message MUST be adjusted. A message can only be
forwarded once since a forwarded message does not have an MF-
extension. 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 11 shows how a Srv(De)Reg message is forwarded.
+----+ (with MF-extension) +-----+ (no MF-extension) +-----+
| | -- SrvReg/SrvDeReg -> | | -- SrvReg/SrvDeReg -> | |
| SA | | DA1 | | DA2 |
| | <------ SrvAck ------ | | <------ SrvAck ------ | |
+----+ +-----+ +-----+
Figure 11. 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.
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.
W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 7]
Internet Draft DA Interaction March 10, 2000
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
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
W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 8]
Internet Draft DA Interaction March 10, 2000
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)",
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 the
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: September 10, 2000 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:34 |