One document matched: draft-zhao-slp-da-interaction-05.txt
Differences from draft-zhao-slp-da-interaction-04.txt
mSLP - Mesh-enhanced Service Location Protocol
draft-zhao-slp-da-interaction-05.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 mSLP - Mesh-enhanced Service Location
Protocol, which enhances SLPv2 with a scheme for the interaction of
Directory Agents (DAs). mSLP 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. mSLP
provides a reliable directory service for an SLP system. It also
greatly simplifies Service Agent (SA) registrations. mSLP 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
exist to enhance the performance and scalability of SLP.
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 1]
Internet Draft DA Interaction June 19, 2000
When multiple DAs are present, how should they interact with each
other? This is an open issue in SLPv2. This document presents mSLP -
Mesh-enhanced Service Location Protocol, which enhances SLPv2 with a
scheme for the interaction of 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 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. mSLP provides a reliable directory service for an SLP
system. It also greatly simplifies the implementation of service
registration for a thin-client SA. The scalability of SLP is thereby
enhanced. mSLP is backward compatible with SLPv2, and incremental
deployment is supported.
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-enhancement 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
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: December 19, 2000 [Page 2]
Internet Draft DA Interaction June 19, 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: December 19, 2000 [Page 3]
Internet Draft DA Interaction June 19, 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. Mesh-enhancement Extension
We define a new SLP extension - "mesh-enhancement extension" for
specifying the interaction operations of mesh-enhanced DAs. This
extension has a five-byte extension header, a one-byte field denoted
as "Action-ID", and an optional DA list in the form of IP addresses.
Figure 5 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-Enhancement Extension ID | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, contd. | Action-ID | <DA-1 IP> ... <DA-N IP> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Mesh-Enhancement Extension
The Action-ID is used to specify the requested operations from the
receiving DA or to indicate the status information to the receiving
DA. Table 1 lists the defined Action-IDs.
Action-ID Abbreviation
0 No_Action
1 Mesh_Forward_Rqst
2 Data_Dump_Rqst
3 Peer_Conn_Indication
4 Peer_DA_Indication
5 Peer_Conn_Keepalive
Table 1. Actions in Mesh-Enhancement Extension
No_Action: null operation. It is used to turn off other operations.
Mesh_Forward_Rqst: mesh forwarding request. It requests that the
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 4]
Internet Draft DA Interaction June 19, 2000
receiving DA forward the message to all DAs (both mesh-enhanced and
non-mesh-enhanced) in the registration scope.
Data_Dump_Rqst: data dump request. It requests that the receiving DA
dump all the service registration data in the shared scopes to the
requesting DA.
Peer_Conn_Indication: peer connection indication. It informs the
receiving DA that this is a peering TCP connection.
Peer_DA_Indication: peer DAs indication. It carries a DA list that
the receiving DA SHOULD peer with.
Peer_Conn_Keepalive: peer connection keepalive. It indicates that
this peering TCP connection is alive. The receiving DA SHOULD not
close it.
5. Peer Relationship
We use a set of fully meshed peering TCP connections among peer DAs.
A peer relationship has three stages: setting up, keeping and tearing
down. We describe each stage in detail next.
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. Figure 6 illustrates the DAAdvert
messages from mesh-enhanced DAs.
+-----+ +-----------+
| | | |
| DA1 | ------- Multicast DAAdvert ------> | DA2/UA/SA |
| | [attr = mesh-enhanced] | |
+-----+ +-----------+
Figure 6. 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
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 5]
Internet Draft DA Interaction June 19, 2000
peering TCP connection to the peer at the port 427 if such connection
does not yet exist. Then it sends a "Peer_Conn_Indication" DAAdvert
message (We mean the message has the mesh-enhancement extension with
Action-ID = Peer_Conn_Indication. Similar notation is used in the
rest of this document.) through this channel to inform the receiving
DA that this is a peering TCP connection (Figure 7). Thus, the
receiving DA can also use this channel to forward messages in the
opposite direction.
+-----+ +-----+
| | [Action-ID = Peer_Conn_Indication] | |
| DA1 | <------------ DAAdvert (TCP) ------------- | DA2 |
| | | |
+-----+ +-----+
Figure 7. Peering Connection Indication
When a mesh-enhanced DA receives a "Peer_Conn_Indication" DAAdvert
message, it sends a "Peer_DA_Indication" DAAdvert message carrying a
DA list that the receiving DA SHOULD peer with (Figure 8). This DA
list is constructed based on the sending DA's peer information and
the receiving DA's service scopes. More precisely, this list
includes the DAs in the sending DA's peer list that share some
service scopes with the receiving DA. Similarly, when a mesh-
enhanced DA receives a "Peer_DA_Indication" DAAdvert message, it
replies with a "Peer_DA_Indication" DAAdvert message if it has NOT
sent this type of message to this peer. In other words, a mesh-
enhanced DA sends a "Peer_DA_Indication" DAAdvert message to each of
its peers once and only once. By exchanging the peer information
through "Peer_DA_Indication" DAAdvert messages, mesh-enhanced DAs can
learn about other DAs in the shared scopes even if multicast is not
supported (The initial peer relationships can be configured by hand
or through DHCP). Upon receiving a "Peer_DA_Indication" DAAdvert
message, a mesh-enhanced DA checks the DA list in the message. This
DA list can be empty. The number of IP addresses in the list can be
determined by (Extension_Length - 6)/4 for IPv4. If a new peer is
found in the list, the mesh-enhanced DA will set up a peer
relationship with it.
+-----+ [Action-ID = Peer_DA_Indication] +-----+
| | ------------- DAAdvert (TCP) ------------> | |
| DA1 | | DA2 |
| | <------------ DAAdvert (TCP) ------------- | |
+-----+ [Action-ID = Peer_DA_Indication] +-----+
Figure 8. Exchanging Peer DA Information
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 6]
Internet Draft DA Interaction June 19, 2000
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. (Note: How to choose a DA from the peering
DA set is implementation dependent. There are a variety of choices
for doing this. The new DA can randomly choose one DA from the
peering DA set or just use the first DA it found. Other criteria can
also be used for the selection such as the nearest DA or the most
lightly loaded DA. The choice only affects performance.) To obtain
the existing data, the new DA sends a "Data_Dump_Rqst" DAAdvert
message to the chosen peer (Figure 9). At the other end, when a
mesh-enhanced DA receives a "Data_Dump_Rqst" 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.
+-----+ [Action-ID = Data_Dump_Rqst] +-----+
| | --------- DAAdvert (TCP) --------> | |
| DA1 | | DA2 |
| | <--------- SrvReg (TCP) ---------- | |
+-----+ (data of shared scopes) +-----+
Figure 9. Dumping Data
5.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
"Peer_Conn_Keepalive" DAAdvert message via the channel every
CONFIG_DA_KEEPALIVE (see Section 9) seconds (Figure 10).
+-----+ +-----+
| | | |
| DA1 | ------------ DAAdvert (TCP) ------------> | DA2 |
| | [Action-ID = Peer_Conn_Keepalive] | |
+-----+ +-----+
Figure 10. DA Keepalive
5.3. Tearing Down a Peer Relationship
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 7]
Internet Draft DA Interaction June 19, 2000
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.
6. Message Forwarding Control
During the peering period, peer DAs forward new service registration
information from SAs to each other. The message forwarding rules are
as follows:
(1) Explicit Forwarding: A message is forwarded only when it
explicitely requests to be forwarded. A mesh-aware SA needs to
attach the mesh-enhancement extension to a SrvReg or SrvDeReg message
and set the Action-ID to Mesh_Forward_Rqst 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 SrvReg or SrvDeReg message is forwarded
only once by a mesh-enhanced DA to all its peers (both mesh-enhanced
and non-mesh-enhanced) in the registration scope. Before forwarding
a message, a mesh-enhanced DA sets the Action-ID in the mesh-
enhancement extension to No_Action. 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 11 shows how a SrvReg/SrvDeReg
message is forwarded.
[Action-ID =
+----+ Mesh_Forward_Rqst] +-----+ [Action-ID = No_Action] +-----+
| | -- SrvReg/SrvDeReg -> | | --- SrvReg/SrvDeReg --> | |
| SA | | DA1 | | DA2 |
| | <------ SrvAck ------ | | <------- SrvAck ------- | |
+----+ +-----+ +-----+
Figure 11. Forwarding Registration
(3) Handling SrvAck: A DA always replies with a SrvAck message when
it receives a SrvReg or SrvDeReg message. So a mesh-enhanced DA
SHOULD process SrvAck messages from other DAs.
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 8]
Internet Draft DA Interaction June 19, 2000
7. Design Discussion
In this section, we discuss several important design issues.
7.1 Meshed Peering TCP Connections
The fully meshed peering DA architecture is built on top of a set of
fully meshed peering TCP connections. We choose to use this set of
fully meshed peering TCP connections mainly because it greatly
facilitates message forwarding control. Any service registration
information received by a DA only needs one-hop forwarding to reach
all other DAs in the peering DA set. We anticipate a small number of
DAs for each service scope, and 2-4 is the recommended value. 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.
7.2 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.
7.3 Simplifying SA Registrations and Scalability
The fully meshed peering DA architecture greatly simplifies 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. With mesh-enhanced DAs and simplified SAs, the overall
SLP system scalability can be enhanced.
7.4 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
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 9]
Internet Draft DA Interaction June 19, 2000
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 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 consideration.
7.5 Compatibility
mSLP is backward compatible with SLPv2. It only defines a new
attribute ("mesh-enhanced") for the DAAdvert message and a new SLP
extension (mesh-enhancement extension) which is used by DAAdvert,
SrvReg and SrvDeReg messages. In mSLP, DAs are enhanced with very
little added complexity, and the changes are almost transparent to
UAs and SAs. UAs can be kept unchanged. SAs can be greatly simplified
by using the mesh-forwarding capability for the service
registrations.
mSLP 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. A mesh-aware SA only needs to register with one mesh-
enhanced DA. However, it still needs to 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.
We summarize the operations for mesh-aware SAs, non-mesh-aware SAs,
mesh-enhanced DAs and non-mesh-enhanced DAs as follows:
Non-mesh-aware SA
It needs to discover all DAs in its scope and register with all
of them. It does NOT use the mesh-enhancement extension.
Mesh-aware SA
It identifies mesh-enhanced DAs from the "mesh-enhanced"
attribute in the DAAdvert messages. It only needs to discover
one mesh-enhanced DA and register with it using the mesh-
enhancement extension (Action-ID = 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.
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 10]
Internet Draft DA Interaction June 19, 2000
Non-mesh-enhanced DA
It accepts SrvReg and SrvDeReg messages from SAs and mesh-
enhanced DAs normally. It dose NOT forward them.
Mesh-enhanced DA
It carries the "mesh-enhanced" attribute in its DAAdvert
messages. It accepts SrvReg and SrvDeReg messages from SAs and
mesh-enhanced DAs. It forwards the messages from mesh-aware SAs
to all peer DAs (both mesh-enhanced and non-mesh-enhanced) in the
registration scope. It also processes SrvAck messages from
mesh-enhanced DAs.
8. Constants
Mesh-enhancement Extension ID 0x0006 (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 authentication is more important in mSLP, since mesh-aware SAs
will have to trust the mesh-enhanced DA they are sending the SrvReg
and SrvDeReg messages to forward them. DAs SHOULD use standard SLPv2
authentication to authenticate other DAs in the mesh. DAs SHOULD also
perform authentication before accepting SrvReg and SrvDeReg messages
to prevent illegitimate modification or elimination of legitimate
service registrations. mSLP is just as secure as SLPv2.
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
11. Acknowledgments
Erik Guttman provided valuable comments and suggestions for this
draft.
12. Authors' Addresses
W. Zhao, H. Schulzrinne Expires: December 19, 2000 [Page 11]
Internet Draft DA Interaction June 19, 2000
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: December 19, 2000 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:54 |