One document matched: draft-zhao-slp-da-interaction-09.txt
Differences from draft-zhao-slp-da-interaction-08.txt
INTERNET DRAFT Weibin Zhao
Service Location Group Henning Schulzrinne
draft-zhao-slp-da-interaction-09.txt Columbia University
Expires: April 9, 2001 Erik Guttman
Sun Microsystems
October 9, 2000
mSLP - Mesh-enhanced Service Location Protocol
draft-zhao-slp-da-interaction-09.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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document presents mSLP - the Mesh-enhanced Service Location
Protocol, which enhances SLP with a fully-meshed peering Directory
Agent (DA) architecture. Peer DAs exchange service registration
information and maintain the same consistent data for shared scopes.
mSLP improves the reliability and consistency of SLP directory
services. It also greatly simplifies Service Agent (SA) registrations
in systems with multiple DAs. mSLP is backward compatible with SLPv2
and can be deployed incrementally.
Zhao, et al. Expires: April 9, 2001 [Page 1]
Internet Draft DA Interaction October 9, 2000
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
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 mSLP -
the Mesh-enhanced Service Location Protocol, which defines a scheme
for the interaction of SLP DAs. mSLP proposes 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 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 shared scopes.
mSLP improves the reliability and consistency of SLP directory
services. It also greatly simplifies SA registrations in systems with
multiple DAs. mSLP is backward compatible with SLPv2 and can be
deployed incrementally.
The rest of this document is organized as follows: Section 2 defines
the terminology. Section 3 reviews the current DA message flows in
SLPv2. Section 4 defines the mesh-control message type and the mesh-
forwarding extension. In Section 5, we describe the DA peer
relationship. In Section 6, we present the message forwarding control
among DAs. We discuss our design in Section 7, list constants in
Section 8, and give security considerations in Section 9.
2. Terminology
Peer DAs: They have one or more scopes in common within one
administrative domain. Peer DAs coordinate with each other and
maintain the same consistent data for shared scopes.
Peering Connection: It is a persistent TCP connection kept by 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. The closing of the connection terminates the peer
relationship.
Mesh-enhanced DA: It maintains a peering connection to each of its
peers and forwards messages to its peers according to the rules given
in Section 6. Such a DA MUST carry the "mesh-enhanced" attribute
keyword in its DAAdvert messages.
Zhao, et al. Expires: April 9, 2001 [Page 2]
Internet Draft DA Interaction October 9, 2000
Mesh-aware SA: It understands the "mesh-enhanced" attribute in
DAAdvert messages and uses the mesh-forwarding capability of mesh-
enhanced DAs for its service registrations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
3. DA Message Flows in SLPv2
This section reviews the DA message flows defined 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
Zhao, et al. Expires: April 9, 2001 [Page 3]
Internet Draft DA Interaction October 9, 2000
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 in this document.
4. Definitions for Mesh Enhancement
To facilitate the mesh-enhancement functionality, we define a new SLP
message type: mesh-control (MeshCtrl) and a new SLP extension:
mesh-forwarding. They are used to specify the extended operations of
mesh-enhanced DAs.
4.1 Mesh Control Message
Mesh-enhanced DAs support the MeshCtrl message, whose Function-ID is
12. The format of this message is given in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = MeshCtrl = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action-ID | Action-Data \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. MeshCtrl Message
Table 1 lists the six defined Action-IDs. The Action-Data can be
empty. Its format is determined by its preceding Action-ID.
Action-ID Abbreviation
1 Pconn_Indication
2 Peers_Indication
3 Data_Get_Rqst
4 Data_Put_Done
5 Peer_Keepalive
6 Peer_Busy
Table 1. Action-IDs in MeshCtrl Message
Zhao, et al. Expires: April 9, 2001 [Page 4]
Internet Draft DA Interaction October 9, 2000
Pconn_Indication (peering connection indication): This Action-ID does
not have an Action-Data part. It informs the receiving DA that the
connection from which the message is received is a peering
connection.
Peers_Indication (peers indication): This Action-ID has an Action-
Data part whose format is given in Figure 6. It carries a DA list
(called common peer list, or CPL) in the form of URLs, which includes
common peers between the sending DA and the receiving DA, and with
whom the sending DA has got synchronized (defined in Section 5.1.6).
The receiving DA SHOULD peer with all DAs in this CPL.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of DA URLs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of DA URL #1 | DA URL #1 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . . . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of DA URL #N | DA URL #N \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Action-Data for Peers_Indication
Data_Get_Rqst (request for getting data): This Action-ID has an
Action-Data part whose format is given in Figure 7. It requests that
the receiving DA send all data in the requested scopes (called RS) to
the requesting DA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Requested Scopes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String of Requested Scopes \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Action-Data for Data_Get_Rqst
Data_Put_Done (done with putting data): This Action-ID does not have
an Action-Data part. It informs the receiving DA that all data in the
requested scopes have been sent.
Peer_Keepalive (peer keepalive): This Action-ID has an Action-Data
part whose format is given in Figure 8. It indicates that the peering
connection from which the message is received is alive and SHOULD not
Zhao, et al. Expires: April 9, 2001 [Page 5]
Internet Draft DA Interaction October 9, 2000
be closed. It also indicates the current stateless boot timestamp of
the sending DA.
Peer_Busy (peer busy): This Action-ID does not have an Action-Data
part. It informs the receiving DA that the sending DA is
synchronizing with another peer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA Boot Timestamp, contd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Action-Data for Peer_Keepalive
4.2 Mesh-forwarding Extension
Mesh-enhanced DAs also support the mesh-forwarding extension, whose
extension ID is 6. Its format is illustrated in Figure 9.
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-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Mesh-forwarding Extension
Table 2 lists the two defined Action-IDs for the mesh-forwarding
extension.
Action-ID Abbreviation
0 No_Action
1 Mesh_Forward_Rqst
Table 2. Action-IDs in Mesh-forwarding Extension
No_Action (null operation): It is used by the sending DA to turn off
the "Mesh_Forward_Rqst" Action-ID in a message.
Mesh_Forward_Rqst (mesh forwarding request): It requests that the
receiving DA forward the message to all DAs (both mesh-enhanced and
non-mesh-enhanced) in the registration scope.
Zhao, et al. Expires: April 9, 2001 [Page 6]
Internet Draft DA Interaction October 9, 2000
5. Peer Relationship
Peer DAs maintain a fully-meshed peer relationship, which uses a set
of fully-meshed peering connections. A mesh-enhanced DA has a peer-
table. Each entry in this peer-table includes the peer URL, a list of
shared scopes, a boot timestamp for the peer to distinguish it from
its rebooted instance, a reference to the peering connection, and a
mesh flag indicating whether the peer is mesh-enhanced or not. A
mesh-enhanced DA adds an entry to its peer-table when it discovers a
new peer, removes an entry from its peer-table when it finds the
corresponding peer is down, and updates an entry when it detects the
corresponding peer has rebooted.
A peer relationship has three stages: setting up, maintaining and
tearing down. mSLP considers the situation where mesh-enhanced DAs,
non-mesh-enhanced DAs, mesh-aware SAs and non-mesh-aware SAs coexist.
It works even if multicast is not supported or a DA's multicast
DAAdvert messages cannot reach all of its peer DAs.
5.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 is the default address in the IPv4 local scope). All
DAs listen to this address. This enables a DA to discover other DAs.
A DAAdvert message from a mesh-enhanced DA MUST carry the "mesh-
enhanced" attribute keyword (Figure 10).
+------------------+ +----------+
| | | |
| Mesh-enhanced DA | ------- Multicast DAAdvert ------> | DA/UA/SA |
| | [attr = mesh-enhanced] | |
+------------------+ +----------+
Figure 10. Mesh-enhanced DA Advertisement
5.1.1 Initiating a Peer Relationship
When a mesh-enhanced DA (such as DA1 in Figure 11) learns about a new
peer (either mesh-enhanced or non-mesh-enhanced) by receiving a
DAAdvert message from the peer (if it knows the peer through a
configuration file or DHCP, it unicasts a SrvRqst message with
service type "service:directory-agent" to the peer to solicit a
DAAdvert), it creates a peering connection to the peer if such
connection does not exist. The mesh-enhanced DA uses this peering
connection to forward messages to the peer. The peer, if mesh-
enhanced, also uses the connection to forward messages in the
opposite direction. Therefore, a peering connection can be set up
Zhao, et al. Expires: April 9, 2001 [Page 7]
Internet Draft DA Interaction October 9, 2000
between two mesh-enhanced DAs or between a mesh-enhanced DA and a
non-mesh-enhanced DA. In the latter case, messages are only forwarded
from the mesh-enhanced DA to the non-mesh-enhanced DA.
+-----+ +-----+
| | | |
| DA1 | <------- Multicast DAAdvert --------- | DA2 |
| | | |
+-----+ +-----+
+-----+ Unicast SrvRqst +-----+
| | ----- (service:directory-agent) ----> | |
| DA1 | | DA2 |
| | <-------- Unicast DAAdvert ---------- | |
+-----+ +-----+
Figure 11. Learning about a New Peer
For a non-mesh-enhanced peer, the mesh-enhanced DA just creates a
peering connection with it and forwards messages to it. But for a
mesh-enhanced peer, the peer relationship setup needs additional
procedures described below.
5.1.2 Identifying a Peering Connection
After a peering connection is established, the DA who initiates the
connection (such as DA1 in Figure 12) sends the following two
messages over the connection: a "Pconn_Indication" MeshCtrl message
marking the connection as the peering connection, and an unsolicited
DAAdvert message enabling the peer to know it promptly (otherwise,
the peer cannot know it until its next multicast DAAdvert). On the
other hand, when a mesh-enhanced DA (such as DA2 in Figure 12)
receives a "Pconn_Indication" MeshCtrl message, it marks the TCP
connection from which the message is received as the peering
connection to the sending DA and uses it properly later. A mesh-
enhanced DA SHOULD not create a new peering connection to a peer if
there exists one already (initiated by the peer). Note that there is
a small possibility that a pair of peering connections might be
created between two peer DAs if they try to set up a peering
connection to each other almost at the same time. That is
inefficient, but it does not affect the correctness of mSLP.
+-----+ (1) "Pconn_Indication" MeshCtrl +-----+
| | (2) Unsolicited DAAdvert | |
| DA1 | ------------------ (TCP) ------------> | DA2 |
| | | |
+-----+ +-----+
Figure 12. Peering Connection Indication and DAAdvert
Zhao, et al. Expires: April 9, 2001 [Page 8]
Internet Draft DA Interaction October 9, 2000
5.1.3 Exchanging Information about Peers
After sending the "Pconn_Indication" MeshCtrl message and the
unsolicited DAAdvert message, or receiving the above two messages
from a peer, a mesh-enhanced DA sends a "Peers_Indication" MeshCtrl
message (Figure 13) to that peer. The CPL in this message can be
constructed using Algorithm 1.
+-----+ "Peers_Indication" MeshCtrl +-----+
| | ------------------ (TCP) --------------> | |
| DA1 | | DA2 |
| | <----------------- (TCP) --------------- | |
+-----+ "Peers_Indication" MeshCtrl +-----+
Figure 13. Exchanging Information about Peers
BUILD_COMMON_PEER_LIST( D ) {
L = empty
Sd = D's scopes
for each peer P in S's peer-table {
Sp = P's scopes
Sc = common scopes between Sd and Sp
if ( P <> D &&
Sc <> empty &&
S has got synchronized with P ) {
add P to L
}
}
return L
}
Algorithm 1. Building the CPL for "Peers_Indication" MeshCtrl
Sent from S to D
The exchange of "Peers_Indication" MeshCtrl messages among peer DAs
serves for two purposes. First, it enables a mesh-enhanced DA to
learn about other DAs that share some scopes with it from its known
peers (Section 5.1.7). This is useful in case multicast is not
supported or a DA's multicast DAAdvert messages cannot reach all of
its peer DAs. Initial peer relationships can be configured by hand or
through DHCP [4]. Second, a "Peers_Indication" MeshCtrl message
enables the receiving DA to know with whom the sending DA has got
synchronized and then decide which scopes of data are needed to
exchange with the sending DA (Section 5.1.6).
5.1.4 Handling "Peers_Indication" MeshCtrl
A mesh-enhanced DA handles the "Peers_Indication" MeshCtrl message it
Zhao, et al. Expires: April 9, 2001 [Page 9]
Internet Draft DA Interaction October 9, 2000
received from a peer as follows. First, if it is synchronizing with
another peer, it SHOULD reply with a "Peer-Busy" MeshCtrl message to
that peer (Section 5.1.5) and skip the next three steps. Second, it
MUST send a "Peers_Indication" MeshCtrl message to that peer if it
has not done this, or its previous "Peers_Indication" MeshCtrl
message has been nullified by a "Peer-Busy" MeshCtrl message from
that peer (Section 5.1.5). Third, it MUST exchange data with that
peer if needed (Section 5.1.6). Fourth, it SHOULD handle new peers
that it found in the CPL of this message (Section 5.1.7).
5.1.5 Peer Synchronization
To avoid race conditions that may arise in synchronizing with
multiple peers simultaneously, a mesh-enhanced DA SHOULD synchronize
with one peer at a time. First, when it receives a "Peers_Indication"
MeshCtrl message from a peer, it SHOULD reply with a "Peer-Busy"
MeshCtrl message to that peer if it is synchronizing with another
peer. Second, when it receives a "Peer-Busy" MeshCtrl message from a
peer, it SHOULD re-send its "Peers_Indication" MeshCtrl message to
that peer later using exponential back off plus a small random period
(to break global synchronization) until it succeeds.
Figure 14 illustrates the state transition for synchronizing with a
peer. S0 is the starting state where the "Peers_Indication" MeshCtrl
message has not been sent nor received from that peer, or has been
nullified by a "Peer-Busy" MeshCtrl message. S3 is the ending state
where the "Peers_Indication" MeshCtrl message has been sent and
received from that peer successfully. A mesh-enhanced DA SHOULD reach
state S3 in synchronizing with a peer before it exchanges data with
that peer.
+----+ send "Peer-Busy" MeshCtrl +----+
START | | <-------------------------------------- | |
------> | S0 | | S1 |
| | --------------------------------------> | |
+----+ receive "Peers_Indication" MeshCtrl +----+
^ | |
receive | | send send |
"Peer-Busy" | | "Peers_Indication" "Peers_Indication" |
MeshCtrl | | MeshCtrl MeshCtrl |
| V V
+----+ +----+
| | receive "Peers_Indication" MeshCtrl | |
| S2 | --------------------------------------> | S3 |
| | | |
+----+ +----+
Figure 14. State Transition for Synchronizing with a Peer
Zhao, et al. Expires: April 9, 2001 [Page 10]
Internet Draft DA Interaction October 9, 2000
The using of "Peer-Busy" MeshCtrl messages can help to break a
deadlock if it occurs in this synchronization procedure. Consider an
example that DA1 tries to synchronize with DA2 (DA1 sends a
"Peers_Indication" MeshCtrl message to DA2), DA2 does this with DA3,
and DA3 does this with DA1 (Figure 15). As all three DAs are busy,
each of them replies with a "Peer-Busy" MeshCtrl message. They try
the above synchronization later using randomized exponential back
off. Thus, the deadlock condition can be broken. If a network
partition happens when the above deadlock occurs, the peer keepalive
mechanism (Section 5.2) can finally break the deadlock.
+-----+
"Peers_Indication" | | "Peers_Indication"
+-------------------- | DA1 | <-------------------+
| +-----------------> | | ------------------+ |
| | "Peer-Busy" +-----+ "Peer-Busy" | |
V | V |
+-----+ "Peers_Indication" +-----+
| | ---------------------------------------> | |
| DA2 | <--------------------------------------- | DA3 |
| | "Peer-Busy" | |
+-----+ +-----+
Figure 15. Breaking a Deadlock in Peer Synchronization
5.1.6 Exchanging Data
Based on the CPL it received from a peer, a mesh-enhanced DA uses
Algorithm 2 to build the RS for which it needs to get data from that
peer. This RS includes those scopes that this DA and that peer have
in common but they do not have a common peer yet (if they have a
common peer for a scope, they should have already had the same data
for that scope). If the resulting RS (after applying Algorithm 2) is
not empty, this DA sends a "Data_Get_Rqst" MeshCtrl message to that
peer to request its data in the RS (Figure 16).
+-----+ "Data_Get_Rqst" MeshCtrl +-----+
| | ----------------- (TCP) --------------> | |
| DA1 | | DA2 |
| | <---------------- (TCP) --------------- | |
+-----+ (1) SrvReg (data of RS) +-----+
(2) "Data_Put_Done" MeshCtrl
Figure 16. Getting Data from a Peer
Zhao, et al. Expires: April 9, 2001 [Page 11]
Internet Draft DA Interaction October 9, 2000
BUILD_REQUESTED_SCOPES( D, L ) {
R = empty
Sd = D's scopes
Ss = S's scopes
Sc = common scopes between Ss and Sd
for each scope T in Sc {
P = S's peers for scope T
Pc = common peers between P and L
if ( Pc == empty ) {
add T to R
}
}
return R
}
Algorithm 2. Building the RS for "Data_Get_Rqst" MeshCtrl sent from
S to D. L is the CPL in D's "Peers_Indication" MeshCtrl
When a mesh-enhanced DA receives a "Data_Get_Rqst" MeshCtrl message,
it sends data in the RS to the requesting DA, and a "Data_Put_Done"
MeshCtrl message at the end of this data transfer. Each data record
is sent as a SrvReg message, with a re-calculated new lifetime
computed as old lifetime minus elapsed time. Also, each SrvReg
message SHOULD have a "mesh-forwarding" extension to request the
receiving DA forward the message to its existing synchronized peers
(Section 6). A mesh-enhanced DA can assume that it has done with
getting data from a peer for their common scopes (thus, that peer is
regarded as a "synchronized peer" by this DA, or this DA is said to
"have got synchronized" with that peer) when it receives a
"Data_Put_Done" MeshCtrl message from that peer, or it gets an empty
RS after applying Algorithm 2. After exchanging data in both
directions, peer DAs share the same consistent data for their common
scopes.
Note that a mesh-enhanced DA may not need to exchange data with all
of its peers, or exchange data of all shared scopes with a peer. Each
implementation can decide the criteria to select a DA (or DAs) from a
peering DA set to exchange data with, such as using the first one it
found, choosing one randomly, using the nearest one or the least
loaded one. As an example, consider that DA4 with scope "a,b,c" joins
a peering DA set of three DAs: DA1 with scope "a,b", DA2 with scope
"a,c" and DA3 with scope "b,c" (Figure 17). DA4 can choose to
exchange data in scope "a,b" with DA1 and data in scope "c" with DA2
(or other suitable combinations). At the same time, DA1 forwards data
in scope "a" and "b" it received from DA4 to D2 and D3, respectively,
and D2 forwards data in scope "c" it received from DA4 to DA3. As a
result of these message exchanging and forwarding, DA4 doesn't need
to exchange data with DA3 directly.
Zhao, et al. Expires: April 9, 2001 [Page 12]
Internet Draft DA Interaction October 9, 2000
+-----------+ (a) +-----------+
| DA1 (a,b) | ------------------------------------> | DA2 (a,c) |
+-----------+ +-----------+
^ | | ^
| | (b) +-----------+ (c) | |
| +---------------> | DA3 (b,c) | <---------------+ |
| +-----------+ |
| | |
| (a,b) +-------------+ (c) |
+------------------> | DA4 (a,b,c) | <------------------+
+-------------+
Figure 17. An Example of Exchanging Data with a Peering DA Set
5.1.7 Handling New Peers
When a mesh-enhanced DA checks the CPL it received from a peer, if
any URL is not in its peer-table, it solicits a DAAdvert message from
the DA corresponding to the URL by unicasting a SrvRqst message with
service type "service:directory-agent" to that DA. In Figure 13, if
DA1 gets a CPL = { D3 } from DA2, and DA3 is not in DA1's peer-table,
DA1 MUST then acquire a DAAdvert message from DA3 (Figure 18). Upon
receiving the DAAdvert message from DA3, DA1 can go through the whole
process to set up a peer relationship with DA3.
+-----+ Unicast SrvRqst +-----+
| | ----- (service:directory-agent) ----> | |
| DA1 | | DA3 |
| | <-------- Unicast DAAdvert ---------- | |
+-----+ +-----+
Figure 18. Soliciting DAAdvert from a Peer
5.2. Maintaining a Peer Relationship
To maintain a peer relationship, a mesh-enhanced DA SHOULD send a
"Peer_Keepalive" MeshCtrl message over the peering connection (Figure
19) every CONFIG_DA_KEEPALIVE seconds (Section 8). This message
serves for three purposes. First, it carries the current stateless
boot timestamp of the sending DA. This enables the receiving DA to
know whether the sending DA has rebooted or not and take
corresponding actions if needed. Second, it keeps a peering
connection alive. In SLPv2, idle connections could be closed by DAs
after CONFIG_CLOSE_CONN seconds [1]. The closing a peering connection
terminates the peer relationship and setting up a peer relationship
has overhead, so it is more efficient to keep a peering connection
alive between two peer DAs than to establish it on demand. Third, it
helps peer DAs to stay synchronized with each other. If no message
Zhao, et al. Expires: April 9, 2001 [Page 13]
Internet Draft DA Interaction October 9, 2000
has been received from a peering connection for too long, there may
be a network partition and the two peer DAs may have inconsistent
data for shared scopes. In that case, they should tear down the
existing peer relationship and set up a new one which enables them to
exchange data and get synchronized.
+-----+ +-----+
| | | |
| DA1 | ---------------- (TCP) ----------------> | DA2 |
| | "Peer_Keepalive" MeshCtrl | |
+-----+ +-----+
Figure 19. Peer Keepalive
5.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 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 any message from the peer for more than
CONFIG_DA_KEEPALIVE seconds. To tear down a peer relationship, a
mesh-enhanced DA removes the peer from its peer list and closes the
peering connection.
6. Message Forwarding Control
Two types of messages are forwarded by mesh-enhanced DAs:
SrvReg/SrvDeReg messages with "mesh-forwarding" extension and
DAAdvert messages from non-mesh-enhanced peers. The message
forwarding rules are as follows.
6.1. Forwarding SrvReg/SrvDeReg Messages
(1) Explicit Forwarding: A mesh-enhanced DA forwards a
SrvReg/SrvDeReg message when the message has a mesh-forwarding
extension and the Action-ID is "Mesh_Forward_Rqst". A mesh-aware SA
needs to use this extension to explicitly specify its mesh-forwarding
request for messages that are intended to be forwarded by a mesh-
enhanced DA. This explicit forwarding rule avoids unnecessary
forwarding and it is fully compatible with SLPv2, where SAs need to
register with all existing DAs. In the peering setup stage, if a
mesh-enhanced DA receives a "Data_Get_Rqst" MeshCtrl message from a
peer, it needs to send data in the RS to that peer. The requested
data are sent as SrvReg messages, which need to use this mesh-
forwarding extension to explicitly request the receiving DA forward
those messages to its existing synchronized peers.
Zhao, et al. Expires: April 9, 2001 [Page 14]
Internet Draft DA Interaction October 9, 2000
(2) One-hop Forwarding: A SrvReg/SrvDeReg message is forwarded only
once by a mesh-enhanced DA to all of its peers (both mesh-enhanced
and non-mesh-enhanced, not including the source DA if the message is
received from a peering connection) in the registration scope. Since
the peering DA set is in a fully connected mesh, this one-hop
forwarding rule ensures that a message can reach all peer DAs. Figure
20 shows how a SrvReg/SrvDeReg message is forwarded. Before
forwarding a message, a mesh-enhanced DA sets the Action-ID in the
mesh-forwarding extension to "No_Action". That way, a forwarded
message will never be forwarded again.
+----+ "Mesh_Forward_Rqst" +-----+ "No_Action" +-----+
| | -- SrvReg/SrvDeReg -> | | --- SrvReg/SrvDeReg --> | |
| SA | | DA1 | | DA2 |
| | <------ SrvAck ------ | | <------- SrvAck ------- | |
+----+ +-----+ +-----+
Figure 20. Forwarding SrvReg/SrvDeReg
(3) Handling SrvAck: As a DA always replies with a SrvAck message
when it receives a SrvReg/SrvDeReg message, a mesh-enhanced DA SHOULD
handle SrvAck messages from other DAs. In Figure 20, DA1 returns a
SrvAck message to SA upon receiving and processing a SrvReg/SrvDeReg
message. As DA1 also forwards the message to DA2, it SHOULD properly
handle the SrvAck message from DA2.
6.2. Forwarding DAAdvert Messages
First, a DAAdvert message is forwarded only when it comes from a new
or rebooted non-mesh-enhanced peer. Second, a mesh-enhanced DA
forwards a DAAdvert message to all of its mesh-enhanced peers that
share some scopes with the advertised DA. Third, a forwarded DAAdvert
message SHOULD not be forwarded again. It can be identified easily
since the sending DA and the advertised DA are different for a
forwarded DAAdvert message.
Forwarding the DAAdvert message from a new or rebooted non-mesh-
enhanced peer can ensure that the DA is known to all of its mesh-
enhanced peers even if multicast is not supported or its multicast
DAAdvert messages cannot reach all of its mesh-enhanced peers. With
the peering procedure described in Section 5.1 and the forwarding
rules given in this section, a DA, whether mesh-enhanced or not,
known to one mesh-enhanced peer can be known to all of its mesh-
enhanced peers. Thus, a mesh-enhanced DA can know all of its peers
and forward service registration information to them properly.
7. Design Discussion
Zhao, et al. Expires: April 9, 2001 [Page 15]
Internet Draft DA Interaction October 9, 2000
7.1 Fully-meshed Peering Connections
The fully-meshed peering DA architecture is built on top of a set of
fully-meshed peering connections. Any message received by a DA only
needs one-hop forwarding to reach all other DAs in the peering DA
set. We anticipate that two to four DAs are sufficient to achieve
very high reliability; larger peer sets significantly increase
maintenance overhead. There is no need to have a separate DA for each
scope. A DA can serve multiple scopes, and a single peering
connection is used across all shared scopes between each pair of peer
DAs.
7.2 Reliability
The fully-meshed peering DA architecture avoids a single point of
failure by replicating data among at least two peer DAs,
automatically synchronizing data among these DAs. It also enables a
DA to recover from a crash with much less effort since a rebooted DA
can get the existing registration data from its peering DA set. This
is done through DA coordination, without involving SAs.
7.3 Simplifying SA Registrations and Improving Scalability
SLPv2 requires that SAs register with all existing DAs in their
scopes and re-register when new DAs are discovered or old DAs are
found to have rebooted. This places a substantial burden on an SA
implementation. With mSLP, a mesh-aware SA only needs to register
with one mesh-enhanced DA in the registration scope; the registration
information will then be propagated automatically within the meshed
DA set. The overall SLP system scalability can be improved by using
mesh-enhanced DAs and simplified SAs.
7.4 Compatibility
mSLP is backward compatible with SLPv2. It defines a new attribute, a
new SLP message type and a new SLP extension. The new attribute
called "mesh-enhanced" is used in DAAdvert messages to identify
mesh-enhanced DAs. The new SLP extension called "mesh-forwarding" is
used by SrvReg and SrvDeReg messages to specify the mesh-forwarding
request. The new SLP message type called MeshCtrl is used by mesh-
enhanced DAs to interact with each other. A mesh-enhanced DA supports
these extended operations without affecting its original functions.
Moreover, the changes at mesh-enhanced DAs are mostly transparent to
UAs and SAs. UAs can be kept unchanged. SAs can simplify their
service registrations by using mesh-forwarding.
mSLP supports incremental deployment of mesh-enhanced DAs, e.g., they
can be deployed one scope at a time. However, since a mesh-aware SA
Zhao, et al. Expires: April 9, 2001 [Page 16]
Internet Draft DA Interaction October 9, 2000
still needs to take care of newly found and rebooted non-mesh-
enhanced DAs as these DAs cannot get existing data from other DAs,
uniform deployment of mesh-enhanced DAs is much more desirable than
partial deployment.
7.5 Summary
Below, we summarize the operations for UAs, mesh-aware SAs, non-
mesh-aware SAs, mesh-enhanced DAs and non-mesh-enhanced DAs.
7.5.1 UA
A UA MAY prefer to use a mesh-enhanced DA to a non-mesh-enhanced DA
since a mesh-enhanced DA is more likely to reliably contain the
complete set of current service registration data for the UA's scope.
7.5.2 Non-mesh-aware SA
A non-mesh-aware SA needs to discover and register with all DAs in
its scope. It does not use the mesh-forwarding extension.
7.5.3 Mesh-aware SA
A mesh-aware SA can identify mesh-enhanced DAs from the "mesh-
enhanced" attribute in their DAAdvert messages. It only needs to
discover one mesh-enhanced DA and register with it using the mesh-
forwarding extension with the Action-ID set to "Mesh_Forward_Rqst".
If there are no mesh-enhanced DAs in its scope, it operates in the
same way as a non-mesh-aware SA [1].
7.5.4 Non-mesh-enhanced DA
A non-mesh-enhanced DA accepts SrvReg/SrvDeReg messages from SAs and
mesh-enhanced DAs normally. It does not forward them.
7.5.5 Mesh-enhanced DA
(1) A mesh-enhanced DA MUST carry the "mesh-enhanced" attribute
keyword in its DAAdvert messages (Section 2).
(2) A mesh-enhanced DA MUST keep a list of peer DAs (mesh-enhanced
and non-mesh-enhanced) and maintain a peering connection to each of
them. For each mesh-enhanced peer, a "Pconn_Indication" MeshCtrl
message SHOULD be sent OR processed, "Peers_Indication" MeshCtrl
messages SHOULD be sent AND processed, "Peer-Busy" MeshCtrl messages
MAY be sent AND processed, a "Data_Get_Rqst" MeshCtrl message MAY be
sent AND processed, and a "Data_Put_Done" MeshCtrl message MUST be
sent if a "Data_Get_Rqst" MeshCtrl message is received (Section 5).
Zhao, et al. Expires: April 9, 2001 [Page 17]
Internet Draft DA Interaction October 9, 2000
(3) A mesh-enhanced DA accepts SrvReg/SrvDeReg messages from SAs and
mesh-enhanced DAs. It MUST forward the "Mesh_Forward_Rqst"
SrvReg/SrvDeReg messages to all of its peers (both mesh-enhanced and
non-mesh-enhanced) in the registration scope and process SrvAck
messages from mesh-enhanced DAs (Section 6.1).
(4) Upon receiving a DAAdvert message from a new or rebooted non-
mesh-enhanced peer, a mesh-enhanced DA MUST forward the message to
all of its mesh-enhanced peers that share some scopes with the
advertised DA (Section 6.2).
8. Constants
Mesh Control (MeshCtrl) Message Type 12 (Section 4)
Mesh-forwarding Extension ID 6 (Section 4)
CONFIG_DA_KEEPALIVE 290 seconds (Section 5.2)
Note: CONFIG_DA_KEEPALIVE < CONFIG_CLOSE_CONN, which has a default
value of 300 seconds [1].
9. Security Considerations
The DA and SA authentications are more important in mSLP than in
original SLP. First, a mesh-enhanced DA SHOULD authenticate other DAs
before setting up a peer relationship with them to prevent any
malicious DA from joining the meshed DA set. Second, as a security
attack at a mesh-enhanced DA may affect all DAs in the meshed DA set,
a mesh-enhanced DA SHOULD authenticate SAs before accepting and
forwarding their SrvReg/SrvDeReg messages to prevent illegitimate
modification or elimination of service registrations. On the other
hand, as a mesh-aware SA depends on the mesh-enhanced DA it registers
with to forward its SrvReg/SrvDeReg messages, it SHOULD authenticate
the DA to avoid using a faked mesh-enhanced DA. mSLP uses standard
SLPv2 authentication.
10. 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.
[4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
Zhao, et al. Expires: April 9, 2001 [Page 18]
Internet Draft DA Interaction October 9, 2000
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
11. Authors' Addresses
Weibin Zhao
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
Email: {zwb,hgs}@cs.columbia.edu
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Email: Erik.Guttman@sun.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhao, et al. Expires: April 9, 2001 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:16 |