INTERNET DRAFT Weibin Zhao
Service Location Group Henning Schulzrinne
draft-zhao-slp-da-interaction-11.txt Columbia University
Expires: December 13, 2001 Erik Guttman
Sun Microsystems
June 13, 2001
mSLP - Mesh-enhanced Service Location Protocol
draft-zhao-slp-da-interaction-11.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 (2001). All Rights Reserved.
Abstract
This document presents the Mesh-enhanced Service Location Protocol
(mSLP). mSLP 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: December 13, 2001 [Page 1]
Internet Draft DA Interaction June 13, 2001
1. Introduction
In the Service Location Protocol (SLPv2 [1]), Directory Agents (DAs)
are used for caching service advertisements from Service Agents (SAs)
and answering queries from User Agents (UAs). They enhance the
performance and scalability of SLP. However, when multiple DAs are
present, how should they interact with each other? This is an open
issue in SLPv2. In this document, we presents the Mesh-enhanced
Service Location Protocol (mSLP), which defines a scheme for the
interaction of SLP DAs.
mSLP proposes that if DAs are needed in an SLP deployment, 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 service registration states for shared scopes when they set up
a peer relationship and continue to exchange new service registration
updates 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: we first review
the existing SLPv2 DA message flows in Section 2, then define
terminology in Section 3. Section 4 presents a design overview.
Section 5 defines the Data Request message and the Mesh Forwarding
extension. We describe registration update propagation control and
peer relationship management in Section 6 and 7. We discuss
compatibility in Section 8, summarize in Section 9, list constants in
Section 10 and give security considerations in Section 11.
2. Existing SLPv2 DA Message Flows
Currently, there are three types of DA message flows in SLPv2:
acknowledging SA registrations, answering UA queries and enabling DA
discovery. Figure 1 illustrates how an SA registers with a DA. 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 Registration
Zhao, et al. Expires: December 13, 2001 [Page 2]
Internet Draft DA Interaction June 13, 2001
Figure 2 shows how a UA queries a DA. 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 Query
Figure 3 depicts DA discovery. A DA can be discovered in two ways:
actively and passively. For active DA discovery (Figure 3-a), a DA
replies with a unicast DA advertisement (DAAdvert) message to a
multicast "service:directory-agent" SrvRqst message. For passive DA
discovery (Figure 3-b), a DA periodically multicast its DAAdvert
message.
+-------+ Multicast "service:directory-agent" SrvRqst +----+
| | --------------------------------------------> | |
(a) | UA/SA | | DA |
| | <-------------------------------------------- | |
+-------+ Unicast DAAdvert +----+
+-------+ +----+
| | | |
(b) | UA/SA | <-------------------------------------------- | DA |
| | Multicast DAAdvert | |
+-------+ +----+
Figure 3. DA Discovery
SLPv2 does not explicitly define message flows among DAs. The only
message that a DA may receive from other DAs is DAAdvert. We will
define a set of message flows for DA interactions in this document.
3. Terminology
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 [3].
Peer DAs
DAs that have one or more scopes in common are peers.
Peer DAs coordinate with each other and maintain the
same consistent data for shared scopes.
Zhao, et al. Expires: December 13, 2001 [Page 3]
Internet Draft DA Interaction June 13, 2001
Peering Connection
A peering connection is a persistent TCP connection
between two peer DAs for reliable FIFO message exchange.
The closing of it terminates the peer relationship.
Mesh-enhanced DA
A mesh-enhanced DA MUST carry the "mesh-enhanced"
attribute keyword in its DAAdvert, maintain peering
connections to all peers and properly interact with
peers.
Mesh-aware SA
A mesh-aware SA understands the "mesh-enhanced"
attribute keyword in the DAAdvert and uses the Mesh
Forwarding extension for its registrations.
Original DAAdvert
The advertised DA in an original DAAdvert is the same as
the sending DA.
Registration Update
A registration update refers to a SrvReg/SrvDeReg
message. A SrvReg can be a fresh registration or an
incremental update to a previous registration. A
SrvDeReg can remove a registration completely or only
some attributes of it [1].
Registration State
A registration state refers to an entry in the
registration database.
4. Design Overview
This section gives an overview of the mSLP design, including its
fully-meshed peering DA architecture, the simplified SA registration
scheme, the registration update propagation, the registration version
resolution and the handling of deleted registration states.
4.1. Fully-meshed Peering DA Architecture
In SLPv2, there is a many-to-many relationship between DAs and
service scopes, i.e., a DA can serve multiple scopes and a scope can
be served by multiple DAs. The mSLP fully-meshed peering DA
architecture can be summarized as follows. First, DAs that share
service scopes are peers. Peer DAs may have exactly the same service
scopes or only one scope in common. Second, there is a single
persistent peering connection between each pair of peer DAs, which
provides a reliable FIFO channel for their message exchange. Third,
Zhao, et al. Expires: December 13, 2001 [Page 4]
Internet Draft DA Interaction June 13, 2001
service registration updates received by one DA are properly
propagated to its peers, thus peer DAs maintain the same consistent
registration states for their common scopes. In the example given in
Figure 4, DA3 shares service scopes with DA1, DA2 and DA4, so it
maintains peering connections with all of them and exchanges
registration updates with them in the corresponding common scopes.
DA1 and DA2 have exactly the same service scopes, they exchange
registration updates in all scopes (x and y) using a single peering
connection.
+-----------+ (x,y) +-----------+
| DA1 (x,y) | <---------------------------------> | DA2 (x,y) |
+-----------+ +-----------+
^ ^
| (y) +-----------+ (y) |
+----------------> | DA3 (y,z) | <----------------+
+-----------+
^
| (z)
v
+-----------+
| DA4 (z) |
+-----------+
Figure 4. Fully-meshed Peering Relationships among DAs
The fully-meshed peering DA architecture provides several advantages.
First, it avoids a single point of failure by replicating data among
at least two peer DAs, automatically synchronizing data among these
DAs. The full mesh topology provides maximum robustness. We
anticipate that a small number of DAs for each service scope is
sufficient to achieve high reliability; peer sets that are too large
are not desirable as they significantly increase management overhead.
Second, it enables a DA to recover from a crash with much less effort
since a rebooted DA can get the existing registrations from its
peering DA set purely through DA coordination, without involving SAs.
Third, it greatly simplifies SA registrations.
4.2. Simplifying SA Registrations
In SLPv2, an SA needs to register with all existing DAs in its 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. mSLP provides an alternate and more efficient way for
distributing registrations, which moves the burden from many SAs to a
few DAs. By simplifying SAs, the overall SLP system scalability can
be improved.
Zhao, et al. Expires: December 13, 2001 [Page 5]
Internet Draft DA Interaction June 13, 2001
In mSLP, a mesh-aware SA only needs to register with sufficient
number of mesh-enhanced DAs such that the union of their service
scopes covers its scopes. The registration will then be propagated
automatically to other DAs in its scopes. In Figure 5, SA1 may choose
to register with DA2 only or to register with both DA1 and DA3. For
compatibility reason, mSLP supports both registration models: the
original SLPv2 registration model in which an SA registers with all
DAs and the new mSLP registration model in which a mesh-aware SA uses
the Mesh Forwarding extension to request that mesh-enhanced DAs
distribute its registrations.
+---------+ (x) +-----------+ (y) +---------+
| DA1 (x) | <---------> | DA2 (x,y) | <---------> | DA3 (y) |
+---------+ +-----------+ +---------+
^ (option2) ^ (option1) ^ (option2)
| | |
| | (x,y) |
| (x) +-----------+ (y) |
+----------------- | SA1 (x,y) | -----------------+
+-----------+
Figure 5. Options for Registration with Mesh-enhanced DAs
4.3. Registration Update Propagation
Mesh-enhanced DAs are responsible for propagating registration
updates that have the Mesh Forwarding extension.
4.3.1. Accept ID
To properly control the registration update propagation among peer
DAs, mSLP defined a data structure: Accept ID [6]. An Accept ID has
two components: Accept DA and Accept Timestamp. The Accept DA of a
registration update is the first DA that accepts the update from an
SA. The Accept Timestamp of a registration update is its arrival
timestamp at its Accept DA, which is the wall clock in millisecond
resolution to ensure that any two updates accepted by the same DA
will have different timestamps.
Each registration update is assigned a unique Accept ID by its Accept
DA. Thus, the Accept ID defines a total order for all updates
accepted by the same DA and a partial order for all updates in the
system. A registration state has the same Accept ID as that of the
latest update applied to it. The Accept ID is used in the Mesh
Forwarding extension and the Data Request message.
4.3.2. Propagation Order and State Summary
Zhao, et al. Expires: December 13, 2001 [Page 6]
Internet Draft DA Interaction June 13, 2001
The motivation to define and use the Accept ID is to avoid
unnecessary data exchange among peer DAs. mSLP propagates
registration updates in the increasing order of their Accept IDs,
thus a mesh-enhanced DA can represent its observed registration
updates using a State Summary, which includes all the latest Accept
IDs it has received. For example, if DAi has a State Summary of
((DA1, T1), (DA2, T2), ..., (DAn, Tn)), then DAi has observed all
registration updates prior to timestamp Tj accepted by DAj, where
1<=i,j<=n. By using the State Summary, peer DAs can easily determine
the difference of their observed updates, and they only need to
exchange the difference to synchronize their registration states.
Otherwise, two peer DAs need to exchange their whole registration
states whenever they need to catch up registration updates with each
other, which may iccur a lot of unnecessary data transfers.
4.3.3. Propagation Mode
A mesh-enhanced DA propagates registration updates to each of its
peers in two ways: anti-entropy [5,6] and direct forwarding.
The initial propagation mode to a new peer is anti-entropy. It works
in a pull fashion. DA1 sends a Data Request message to DA2 to request
new registration updates after the accept ID specified in the
message. The anti-entropy is used for the initial population exchange
among peer DAs. It is also used after failure conditions have been
fixed (DA crashes and network partitions) to enable peer DAs to catch
up the difference of their observed registration updates.
After DA1 has sent all previous registration updates accepted by
itself to DA2 (via anti-entropy), it performs direct forwarding to
DA2 in a push fashion. DA1 directly forwards a newly received
registration update from an SA to DA2. Note that the direct
forwarding of a registration update only goes one-hop the accept DA
to its peers. As peer DAs are in a fully connected mesh, the one-hop
forwarding is sufficient to distribute registration updates rapidly
among peer DAs when there is no failure. If a failure happens, the
anti-entropy MUST be used.
4.4. Registration Version Resolution
When registrations are propagated among DAs, their arrival timestamps
at DAs cannot be used for version resolution. For example, assume SA1
sends a registration (R1) to DA1 first and a new version of the same
registration (R2) to DA2 later. When R1 and R2 are propagated, the
arrival timestamp of R1 at DA2 is later than that of R2, but R1
SHOULD NOT overwrite R2 at DA2 as R2 is a newer version. In order to
always install the new version of a registration, a Version Timestamp
from the SA is needed for each propagated registration update. mSLP
Zhao, et al. Expires: December 13, 2001 [Page 7]
Internet Draft DA Interaction June 13, 2001
assumes that each registration is updated only by one SA, thus it
doesn't need to compare Version Timestamps from two SAs.
The Version Timestamp is carried in the Mesh Forwarding extension. It
is the wall clock in millisecond resolution to ensure that any two
registration updates from the same SA will have different version
timestamps. A registration update is installed only if it has a newer
version timestamp (from a mesh-aware SA) or it doesn't have the Mesh
Forwarding extension (from a non-mesh-aware SA). Note that when a
mesh-aware SA uses a new DA for a registration, it SHOULD perform a
fresh SrvReg first since the new DA may not have the latest version
for the registration yet. Blindly using incremental registrations may
result in incomplete registration states.
4.5. Handling Deleted Registration States
While a registration can be deleted by an SA via a SrvDeReg, a mesh-
enhanced DA SHOULD NOT remove a deleted state from its registration
database right away, otherwise if an old version of the deleted
registration is propagated back, it will be installed again. mSLP
sets a deletion flag for deleted states (similar to death certificate
[5]). A deleted state MUST NOT be included in any query reply. As
registrations in SLP are soft states, a state (whether deleted or
not) will be removed when it expires. Thus, no special process is
needed for purging deleted states.
5. Definitions for Mesh Enhancement
A mesh-enhanced DA MUST support the Data Request message and the Mesh
Forwarding extension. They are used to specify extended operations
for mesh-enhanced DAs.
5.1. Accept ID
As the Accept ID appears in both the Data Request message and the
Mesh Forwarding extension, we first give its format in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept Timestamp, contd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Accept DA URL | Accept DA URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Accept ID
Zhao, et al. Expires: December 13, 2001 [Page 8]
Internet Draft DA Interaction June 13, 2001
5.2. Data Request Message
The Data Request (DataRqst) message carries an Accept ID. This
message is used by a mesh-enhanced DA to request new registration
states after the specified Accept ID from the receiving DA. Its
Function-ID is 12. Figure 7 gives 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = DataRqst = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept ID \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. DataRqst Message
5.3. Mesh Forwarding Extension
The Mesh Forwarding (MeshFwd) extension carries a Version Timestamp
and an Accept ID. It is used in the SrvReg/SrvDeReg message. Its
extension ID is 6. Figure 8 shows its format and two defined Forward
IDs (Fwd-IDs). A mesh-aware SA appends this extension (Fwd-ID =
RqstFwd, Accept Timestamp = 0) to a SrvReg/SrvDeReg to request a
mesh-enhanced DA (the Accept DA) forward the message. A mesh-enhanced
DA uses this extension (Fwd-ID = Fwded) in a forwarded
SrvReg/SrvDeReg message sent from it to another 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MeshFwd Extension ID = 6 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, contd. | Fwd-ID | Version Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp, contd. | Accept ID \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fwd-ID Abbreviation
1 RqstFwd
2 Fwded
Figure 8. MeshFwd Extension and its Fwd-IDs
6. Registration Update Propagation Control
Zhao, et al. Expires: December 13, 2001 [Page 9]
Internet Draft DA Interaction June 13, 2001
The propagation of registration updates in mSLP is controlled via the
MeshFwd extension, i.e., a SrvReg/SrvDeReg is propagated if and only
if it has the MeshFwd extension. As a DA always replies with a SrvAck
to a SrvReg/SrvDeReg, a mesh-enhanced DA SHOULD handle SrvAck
messages properly.
6.1. Direct Forwarding
To directly forward a SrvReg/SrvDeReg from a mesh-aware SA, a mesh-
enhanced DA set its Fwd-ID to Fwded and its Accept Timestamp to its
arrival timestamp. A direct forwarding is performed asynchronously,
as shown in Figure 9, DA1 can send a SrvAck to SA1 before it gets the
SrvAck from DA2.
+-----+ RqstFwd Srv(De)Reg +-----+ Fwded Srv(De)Reg +-----+
| | ---------------------> | | ---------------------> | |
| SA1 | (Peering Connection) | DA1 | (Peering Connection) | DA2 |
| | <--------------------- | | <--------------------- | |
+-----+ SrvAck +-----+ SrvAck +-----+
Figure 9. Direct Forwarding of a SrvReg/SrvDeReg
6.2. Anti-Entropy
When a mesh-enhanced DA receives a DataRqst from a peer, it SHOULD
check its State Summary and send the requested new registration
states it has to the peer (Figure 10) in the increasing order of
their Accept Timestamps. A new registration state is sent as a fresh
SrvReg with a re-calculated new lifetime computed as its old lifetime
minus the elapsed time. A newly deleted registration state is
propagated as a fresh SrvReg first and then as a SrvDeReg.
+-----+ DataRqst +-----+
| | -------------------------------------------> | |
| DA1 | (Peering Connection) | DA2 |
| | <------------------------------------------- | |
+-----+ New Registration States via Srv(De)Reg(s) +-----+
Figure 10. One-way Anti-Entropy
6.3. State Summary
When a SrvReg/SrvDeReg is received from an SA or from its Accept DA,
a mesh-enhanced DA updates its State Summary directly, otherwise, it
MUST update its State Summary on scope basis. The State Summary for
an Accept DA is the minimum of all its latest scope-based Accept
Timestamps. As mSLP uses the fully-meshed peering DA architecture,
normally a mesh-enhanced DA only needs to request new registration
Zhao, et al. Expires: December 13, 2001 [Page 10]
Internet Draft DA Interaction June 13, 2001
states from their Accept DAs. However, sometimes it needs to request
new registration states from their Non-Accept DAs. For examples, a
new peer may need to get registrations accepted by a DA that has
crashed. In Figure 11, if DA1 crashes, a new peer DA4 can get DA1
accepted registrations in scope x from DA2 and those in scope y from
DA3, but DA4 needs to summarize DA1 accepted registrations on scope
basis.
+-----------+ (x) +---------+ (x) +-----------+
| DA1 (x,y) | <---------> | DA2 (x) | <---------> | DA4 (x,y) |
+-----------+ +---------+ +-----------+
^ ^ ^ ^
| | (x,y) | |
| +-----------------------------------------------+ |
(y) | +---------+ | (y)
+------------------> | DA3 (y) | <------------------+
+---------+
Figure 11. Requesting States from Non-Accept DAs
7. Peer Relationship Management
A mesh-enhanced DA maintains a peer table to record information for
each of its peers, which includes the peer DAAdvert and a reference
to the peering connection.
Peering with a non-mesh-enhanced DA is simple; the DA only needs to
establish a peering connection, forward newly received registration
updates and send its DAAdvert at a regular interval. Next we focus on
the peer relationship management between two mesh-enhanced DAs.
+-----+ +-----+
| | Multicast DAAdvert | |
(a) | DA1 | <------------------------------------------ | DA2 |
| | | |
+-----+ +-----+
+-----+ +-----+
| | Original or Forwarded DAAdvert | |
(b) | DA1 | <------------------------------------------ | DA2 |
| | (Peering Connection) | |
+-----+ +-----+
+-----+ +-----+
| | "service:directory-agent" SrvRqst | |
(c) | DA1 | ------------------------------------------> | DA2 |
| | <------------------------------------------ | |
+-----+ Unicast DAAdvert (UDP) +-----+
Figure 12. Getting a DAAdvert from a New Peer
Zhao, et al. Expires: December 13, 2001 [Page 11]
Internet Draft DA Interaction June 13, 2001
7.1. Learning about a New Peer
A mesh-enhanced DA can learn about a new peer via static
configuration, DHCP [4], DAAdvert multicast (Figure 12-a), an
unsolicited original or forwarded DAAdvert (Figure 12-b), and a
solicited DAAdvert that answers its "service:directory-agent" SrvRqst
(Figure 12-c). In any case, a mesh-enhanced DA SHOULD get a DAAdvert
from a new peer before establishing the peer relationship to it.
7.2. Establishing a Peering Connection
After a mesh-enhanced DA gets a DAAdvert from a new peer, if there
does not exist a peering connection initiated by the peer, then it
MUST create such a connection and send its DAAdvert via the
connection (Figure 13). A mesh-enhanced DA can identify a peering
connection initiated by a peer by receiving an original DAAdvert from
the connection. Normally, only a single peering connection SHOULD be
set up between two peers. However, there is a small possibility that
a pair of such connections might be created if two peers try to
initiate a connection to each other almost at the same time. That is
inefficient, but it does not affect the correctness.
+-----+ (1) DA2 DAAdvert | +-----+
| | <--------------------+ | |
| DA1 | (2) Create a Peering Connection | DA2 |
| | ---------------------------------------> | |
+-----+ (3) DA1 DAAdvert +-----+
Figure 13. Establishing a Peering Connection
7.3. Forwarding DAAdvert Messages
+-----+ DAAdvert(s) of DA1's Peers +-----+
| | ---------------------------------------> | |
| DA1 | (Peering Connection) | DA2 |
| | <--------------------------------------- | |
+-----+ DAAdvert(s) of DA2's Peers +-----+
| |
| DA2 DAAdvert DA1 DAAdvert |
V V
+----------------------+ +----------------------+
| DA1's Existing Peers | | DA2's Existing Peers |
+----------------------+ +----------------------+
Figure 14. Forwarding DAAdvert Messages
After establishing a new peering connection, a mesh-enhanced DA forwards
the new peer DAAdvert to its existing peers, and sends a DAAdvert for each
Zhao, et al. Expires: December 13, 2001 [Page 12]
Internet Draft DA Interaction June 13, 2001
of its existing peers and the accept DAs in its state summary to the new
peer (Figure 14). The DAAdvert forwarding enables a DA to learn peers
incrementally from its known peers, and to know the accept DA set of
the new peer.
7.4. Maintaining a Peer Relationship
To detect failures (network partitions and peer crashes), mSLP uses a
heat-beat mechanism. A mesh-enhanced DA SHOULD send its DAAdvert to
peers (Figure 15) every CONFIG_DA_KEEPALIVE seconds (Section 10). The timeout
value for this message is CONFIG_DA_TIMEOUT seconds (Section 10).
+-----+ DA1 DAAdvert +-----+
| | ---------------------------------------> | |
| DA1 | (Peering Connection) | DA2 |
| | <--------------------------------------- | |
+-----+ DA2 DAAdvert +-----+
Figure 15. Maintaining a Peer Relationship
7.5. 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
the peer DAAdvert is timeout. To tear down a peer relationship, a
mesh-enhanced DA removes the peer from its peer table and closes the
peering connection.
8. Compatibility
mSLP is fully backward compatible with SLPv2. It defines a new
attribute ("mesh-enhanced"), a new message type (DataRqst) and a new
extension (MeshFwd). A mesh-enhanced DA supports 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
the RqstFwd MeshFwd extension.
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
still needs to take care of newly found and rebooted non-mesh-
enhanced DAs as these DAs cannot get existing registrations from
other DAs, uniform deployment of mesh-enhanced DAs is much more
desirable than partial deployment.
Zhao, et al. Expires: December 13, 2001 [Page 13]
Internet Draft DA Interaction June 13, 2001
9. Summary
UA
It 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 scopes.
Non-mesh-aware SA
It needs to discover and register with all DAs in its
scopes. It does not use the MeshFwd extension.
Mesh-aware SA
First, it only needs to discover sufficient number of
mesh-enhanced DAs that cover its scopes and register
with them using the MeshFwd extension (Section 4.2).
Second, when it uses a new DA for its registrations, it
SHOULD first sends a fresh SrvReg for a registration,
then can it perform incremental updates on the
registration (Section 4.4). Third, if there are no
mesh-enhanced DAs in its scopes, it operates in the same
way as a non-mesh-aware SA [1].
Non-mesh-enhanced DA
It accepts SrvReg/SrvDeReg messages from SAs and mesh-
enhanced DAs normally. It does not forward them.
Mesh-enhanced DA
First, it MUST carry the "mesh-enhanced" attribute
keyword in its DAAdvert (Section 3). Second, it MUST
maintain a peer table and have peering connections to
all peers. For each mesh-enhanced peer, the DataRqst
message MUST be sent AND processed (Section 6). Third,
it accepts registrations from SAs and mesh-enhanced DAs,
propagates registrations using direct forwarding and
anti-entropy and processes SrvAck messages from mesh-
enhanced DAs (Section 6). Fourth, it SHOULD forward the
DAAdvert message from a new peer to its existing peers
and vice versa (Section 7.3).
10. Constants
Data Request Message Type 12 (Section 5.2)
Mesh Forwarding Extension ID 6 (Section 5.3)
CONFIG_DA_KEEPALIVE 200 seconds (Section 7.4)
CONFIG_DA_TIMEOUT 300 seconds (Section 7.4)
Zhao, et al. Expires: December 13, 2001 [Page 14]
Internet Draft DA Interaction June 13, 2001
11. Security Considerations
mSLP uses standard SLPv2 authentication. However, 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.
12. References
[1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location
protocol, version 2", RFC 2608, June 1999.
[2] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)",
RFC 1771, March 1995.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[4] C. Perkins and E. Guttman, "DHCP options for service location
protocol", RFC 2610, June, 1999.
[5] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker,
H. Sturgis, D. Swinehart and D. Terry, "Epidemic algorithms for
replicated database maintenance", the sixth ACM symposium on
principles of distributed computing, Vancouver, Canada, 1987.
[6] K. Petersen, M. Spreizer, D. Terry, M. Theimer and A. Demers,
"Flexible update propagation for weakly consistent replication",
the sixteenth ACM symposium on operating systems principles,
Saint Malo, France, 1997.
13. 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
Zhao, et al. Expires: December 13, 2001 [Page 15]
Internet Draft DA Interaction June 13, 2001
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Email: Erik.Guttman@sun.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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: December 13, 2001 [Page 16]