INTERNET DRAFT Weibin Zhao
draft-zhao-slp-da-interaction-15.txt Henning Schulzrinne
[Target Category: Standards Track] Columbia University
August 27, 2002 Erik Guttman
Expires: February 27, 2003 Sun Microsystems
Mesh-enhanced Service Location Protocol
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 (2002). All Rights Reserved.
Abstract
This document presents the Mesh-enhanced Service Location Protocol
(mSLP). mSLP enhances SLP with a scope-based fully-meshed peering
Directory Agent (DA) architecture. Peer DAs exchange new service
registrations in shared scopes via anti-entropy and direct
forwarding. mSLP improves the reliability and consistency of SLP DA
services, and 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: February 27, 2003 [Page 1]
Internet Draft DA Interaction August 27, 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation Conventions . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Applicability Statement and Compatibility . . . . . . . . 4
2. Scope-based Fully-meshed Peering DA Architecture . . . . . 4
3. Peer Relationship Management . . . . . . . . . . . . . . . 5
3.1. Learning about New Peers . . . . . . . . . . . . . . . . . 5
3.2. Establishing a Peering Connection . . . . . . . . . . . . 5
3.3. Exchanging Information about Existing Peers . . . . . . . 6
3.4. Maintaining a Peer Relationship . . . . . . . . . . . . . 6
3.5. Tearing Down a Peer Relationship . . . . . . . . . . . . . 7
4. Registration Propagation Control . . . . . . . . . . . . . 7
4.1. Accept ID and Propagation Order . . . . . . . . . . . . . 7
4.2. Version Timestamp and Registration Version Resolution . . 7
4.3. Mesh Forwarding Extension . . . . . . . . . . . . . . . . 8
4.4. Summary Vector . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Service Deregistration . . . . . . . . . . . . . . . . . . 9
4.6. Anti-entropy Request Message . . . . . . . . . . . . . . . 9
4.7. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . . 10
4.8. Direct Forwarding . . . . . . . . . . . . . . . . . . . . 10
4.9. SrvAck Message . . . . . . . . . . . . . . . . . . . . . . 11
4.10. Control Information . . . . . . . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . 12
10. Non-normative References . . . . . . . . . . . . . . . . . 12
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . 13
1. Introduction
In the Service Location Protocol (SLPv2 [RFC2608]), Directory Agents
(DAs) accept service registrations from Service Agents (SAs) and
answer queries from User Agents (UAs); they enhance the performance
and scalability of SLPv2. The use of scopes in SLPv2 further improves
its scalability. In general, a DA can serve multiple scopes, and a
scope can be served by multiple DAs. When multiple DAs are present
for a scope, how should they interact with each other? To address
this open issue in SLPv2, we present the Mesh-enhanced Service
Location Protocol (mSLP).
mSLP defines a scope-based fully-meshed peering DA architecture: for
each scope, all DAs serving the scope form a fully-meshed peer
relationship (similar to IBGP [RFC1771]). Peer DAs exchange new
Zhao, et al. Expires: February 27, 2003 [Page 2]
Internet Draft DA Interaction August 27, 2002
service registrations in shared scopes via anti-entropy [EPID-
ALGO,UPDA-PROP] and direct forwarding. mSLP improves the reliability
and consistency of SLP DA services, and simplifies SA registrations
in systems with multiple DAs.
1.1. Notation Conventions
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 [RFC2119].
1.2. Terminology
Peer DAs (or Peers)
DAs that share one or multiple scopes are peers.
Peering Connection
A persistent connection (e.g., TCP) that provides reliable and
ordered transfers between two peers. The closing of a peering
connection terminates the peer relationship.
Mesh-enhanced DA (MDA)
An MDA carries the "mesh-enhanced" attribute keyword in its DA
Advertisement (DAAdvert) message, maintains peering connections
to all peers, and properly interacts with peers.
Mesh-enhanced SA (MSA)
An MSA uses the Mesh Forwarding extension (Section 4.3) when it
registers with MDAs.
Registration Update
A registration update refers to a Service Registration (SrvReg)
or Service Deregistration (SrvDeReg) message.
Registration State
A registration state refers to an entry in the registration
database.
Accept DA
When a DA accepts a registration update from an SA, the DA is
the accept DA for the update.
Accept Timestamp
The arrival timestamp of a registration update at its accept DA
is the accept timestamp of the update. All accept timestamps
assigned by the same DA MUST be monotonically increasing.
Version Timestamp
Zhao, et al. Expires: February 27, 2003 [Page 3]
Internet Draft DA Interaction August 27, 2002
When an MSA sends a registration update to an MDA, the MSA
assigns a version timestamp to the update. All version
timestamps assigned by the same MSA MUST be monotonically
increasing.
1.3. Applicability Statement and Compatibility
mSLP is designed as a lightweight enhancement to SLPv2. It is
backward compatible with SLPv2. mSLP defines two enhanced entities:
MDA and MSA. MDAs and MSAs can be deployed incrementally. An enhanced
entity supports extended operations without affecting its original
functionality as defined in RFC 2608 [RFC2608]. For simplicity and
compatibility, an enhanced entity works as a non-enhanced entity to
interact with non-enhanced entities. Table 1 summarizes all
interactions involving an MDA or MSA.
Interaction Equivalent To Defined In
----------------------------------------------
MDA <--> MDA mSLP
MDA <--> MSA mSLP
MDA <--> DA DA <--> DA RFC 2608
MDA <--> SA DA <--> SA RFC 2608
MDA <--> UA DA <--> UA RFC 2608
MSA <--> DA SA <--> DA RFC 2608
MSA <--> UA SA <--> UA RFC 2608
Table 1. Interactions involving an MDA or MSA
2. Scope-based Fully-meshed Peering DA Architecture
mSLP employs a scope-based fully-meshed peering DA architecture. For
each scope, all MDAs that serve the scope form a fully-meshed peer
relationship. Figure 1 shows an example for four MDAs and three
scopes (x, y, and z). Note that a single peering connection is needed
between two peers for exchanging all service registrations in their
shared scopes.
(x,y)
+--------------------------------------------------+
| +------------+ |
| | MDA4 (z) | |
| +------------+ |
| | (z) |
+------------+ (y) +------------+ (y) +------------+
| MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) |
+------------+ +------------+ +------------+
Figure 1. A scope-based fully-meshed peering DA architecture
Zhao, et al. Expires: February 27, 2003 [Page 4]
Internet Draft DA Interaction August 27, 2002
This architecture improves SLP DA services. It avoids a single point
of failure by replicating registrations among at least two peers,
automatically reconciling inconsistent states among these peers. It
also enables an MDA to recover from a crash with much less effort,
since a rebooted MDA can get the existing registrations from its
peers purely through DA interaction, without involving SAs.
This architecture also simplifies 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. In mSLP, for all MDAs, an MSA only needs to register with
sufficient number of them such that the union of their scopes covers
its scopes; the registrations will then be propagated automatically
to other MDAs in the registration scopes. In Figure 2, MSA1 may
register with MDA2, or with both MDA1 and MDA3.
(option2) +------------+ (option2)
+----------------- | MSA1 (x,y) | -----------------+
| +------------+ |
| | (option1) |
V V V
+----------+ +------------+ +----------+
| MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) |
+----------+ +------------+ +----------+
Figure 2. Options for registering with MDAs
3. Peer Relationship Management
3.1. Learning about New Peers
An MDA can learn about new peers via static configuration, DHCP
[RFC2610], and DAAdvert multicast and unicast. In any case, an MDA
MUST get a peer's DAAdvert before establishing a peer relationship to
the peer.
3.2. Establishing a Peering Connection
After getting a new peer's DAAdvert, an MDA establishes a peering
connection (if such a connection does not exist yet) to the peer, and
sends its DAAdvert via the connection (Figure 3). An MDA can identify
a peering connection initiated by a peer by receiving the peer's
DAAdvert from the connection. Normally, a single peering connection
is set up between two peers, but there is a small possibility that a
pair of peering connections might be created between two peers if
they try to initiate a connection to each other almost at the same
time. Thus, when an MDA identifies a new peering connection initiated
by a peer, it SHOULD check whether it has initiated another peering
Zhao, et al. Expires: February 27, 2003 [Page 5]
Internet Draft DA Interaction August 27, 2002
connection to the peer. If this is the case, and it has a lower-
numbered IP address than the peer, then the MDA SHOULD terminate the
connection it has initiated.
+------+ (1) MDA2's DAAdvert | +------+
| | <----------------------+ | |
| MDA1 | (2) Create a Peering Connection | MDA2 |
| | ---------------------------------------> | |
+------+ (3) MDA1's DAAdvert +------+
Figure 3. Establishing a peering connection
3.3. Exchanging Information about Existing Peers
After establishing a peering connection, two peers (say MDA1 and
MDA2) exchange information about their existing peers by forwarding
peers' DAAdverts via the peering connection (Figure 4). MDA1 will
forward the DAAdvert of a peer (say MDA3) to MDA2 if
(1) MDA3 shares scopes with MDA2, and
(2) MDA3 is an active peer of MDA1 (there is a peering connection
between MDA3 and MDA1) or an accept DA of MDA1 (MDA1 has
registrations originally accepted by MDA3).
MDA2 operates similarly. Note that all DAAdverts can be sent as one
TCP stream for efficiency. Exchanging information about existing
peers enables an MDA to learn about new peers incrementally.
+------+ DAAdverts of MDA1's existing peers +------+
| | ------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------ | |
+------+ DAAdverts of MDA2's existing peers +------+
Figure 4. Exchanging information about existing peers
3.4. Maintaining a Peer Relationship
+------+ MDA1's DAAdvert +------+
| | ---------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <--------------------------------------- | |
+------+ MDA2's DAAdvert +------+
Figure 5. Maintaining a peer relationship
To detect failures (network partitions and peer crashes), mSLP uses a
heart-beat mechanism. An MDA sends its DAAdvert to peers (Figure 5)
Zhao, et al. Expires: February 27, 2003 [Page 6]
Internet Draft DA Interaction August 27, 2002
every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message
is CONFIG_DA_TIMEOUT seconds (Section 6).
3.5. Tearing Down a Peer Relationship
An MDA SHOULD tear down a peer relationship when it finds that the
peer has closed the peering connection, when it receives a DAAdvert
multicast from the peer with a DA stateless boot timestamp set to 0
(meaning that the peer is going to shutdown), or when it has not
received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds.
4. Registration Propagation Control
4.1. Accept ID and Propagation Order
When an MDA accepts a registration update from an MSA, the MDA
assigns a unique accept ID to the update. An accept ID has two
components: accept DA and accept timestamp. Figure 6 shows the format
for an accept ID entry. A registration state has the same accept ID
as that of the latest update applied to it.
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, cont'd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Accept DA URL | Accept DA URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Accept ID entry
An MDA MUST propagate registrations in the increasing order of their
accept IDs: (1) registrations having the same accept DA MUST be
propagated in the increasing order of their accept timestamps, and
(2) registrations having different accept DAs MAY be propagated in
any orders.
4.2. Version Timestamp and Registration Version Resolution
When registrations are propagated among MDAs, their arrival
timestamps at MDAs cannot be used for version resolution. For
example, assume that MSA1 sends a registration (R1) to MDA1 first,
and a new version of the same registration (R2) to MDA2 later. When
R1 and R2 are propagated, the arrival timestamp of R1 at MDA2 is
later than that of R2, but R1 SHOULD NOT overwrite R2 at MDA2 as R2
is a newer version.
Zhao, et al. Expires: February 27, 2003 [Page 7]
Internet Draft DA Interaction August 27, 2002
In mSLP, an MDA uses the version timestamp for registration version
resolution. mSLP assumes that each registration is updated only by
one SA, thus an MDA does not need to compare version timestamps from
different MSAs. An MDA installs a registration update if the update
has a newer version timestamp (from an MSA), or the update does not
have the Mesh Forwarding extension (from a non-MSA).
4.3. Mesh Forwarding Extension
The Mesh Forwarding (MeshFwd) extension carries a version timestamp
and an accept ID entry. Its extension ID is 6. Figure 7 shows its
format and two defined Forwarding IDs (Fwd-IDs).
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, cont'd. | Fwd-ID | Version Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp, cont'd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp, cont'd. | Accept ID Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fwd-ID Abbreviation
1 RqstFwd
2 Fwded
Figure 7. MeshFwd Extension and its Fwd-IDs
The MeshFwd extension is used with a Srv(De)Reg message, but it can
only be used with a fresh SrvReg, or a complete SrvDeReg.
An MSA uses the RqstFwd MeshFwd extension (Fwd-ID = RqstFwd, accept
timestamp = 0) in a Srv(De)Reg to explicitly request an MDA (the
accept DA) to forward the message.
An MDA uses the Fwded MeshFwd extension (Fwd-ID = Fwded, accept
timestamp != 0) in each Srv(De)Reg sent from it to another MDA:
either forwarding a Srv(De)Reg received from an MSA (if the message
has the RqstFwd MeshFwd extension), or propagating a registration
state in its database.
4.4. Summary Vector
An MDA uses a summary vector to represent its received Srv(De)Reg(s)
that have a MeshFwd extension. This summary vector records the latest
Zhao, et al. Expires: February 27, 2003 [Page 8]
Internet Draft DA Interaction August 27, 2002
accept timestamp for each accept DA that appears in the MeshFwd
extension. For example, consider n MDAs for a scope, if MDAi has a
summary vector as ((MDA1, T1), (MDA2, T2), ..., (MDAn, Tn)), then
MDAi has received all registrations originally accepted by MDAj up to
timestamp Tj, where 1<=i,j<=n.
An MDA updates its summary vector when it receives a Srv(De)Reg that
has a MeshFwd extension. The MDA adds a new accept ID to its summary
vector if the Srv(De)Reg has a new accept DA; the MDA updates the
accept timestamp of an existing accept ID in its summary vector if
the Srv(De)Reg has an existing accept DA.
4.5. Service Deregistration
When an MDA receives a SrvDeReg that has a MeshFwd extension, it
SHOULD retain the corresponding registration in the database, and
mark it as deleted. This way, the registration will not appear in any
query reply, and an earlier SrvReg will not mistakenly cause the
registration to reappear in the database. A registration state will
be purged from the database when it expires.
4.6. Anti-entropy Request Message
The Anti-entropy Request (AntiEtrpRqst) message carries an anti-
entropy type ID and a list of accept ID entries. Its Function-ID is
12. Figure 8 shows its format and two defined anti-entropy type IDs.
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 = AntiEtrpRqst = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anti-Entropy Type ID | Number of Accept ID Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept ID Entry 1 . . . Accept ID Entry k \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anti-Entropy Type Type ID
selective 1
complete 2
Figure 8. AntiEtrpRqst message and anti-entropy types
The AntiEtrpRqst message is used by an MDA to request new
registration states from a peer. The anti-entropy type is either
selective or complete. If the anti-entropy type is selective, only
registration states that have an accept ID greater than any specified
accept ID in the message are requested. If the anti-entropy type is
Zhao, et al. Expires: February 27, 2003 [Page 9]
Internet Draft DA Interaction August 27, 2002
complete, all registration states that have an accept ID greater than
any specified accept ID in the message or have an accept DA not
specified in the message are requested.
For example, consider three MDAs (MDA1, MDA2, and MDA3) for a scope.
MDA2 has registration states originally accepted by MDA1, MDA2, and
MDA3. If MDA1 sends a selective AntiEtrpRqst to MDA2 using an accept
ID list as ((MDA2, T2)), then MDA1 only requests registration states
that are originally accepted by MDA2, and have an accept timestamp
greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 using
an accept ID list as ((MDA2, T2)), then MDA1 requests all
registration states originally accepted by MDA1 and MDA3, plus those
originally accepted by MDA2 and having an accept timestamp greater
than T2.
4.7. Anti-entropy
Anti-entropy is used for exchanging initial registration states when
two peers know each other at the first time, and for catching up new
registration states after failures.
When an MDA receives an AntiEtrpRqst from a peer, it sends the
requested new registration states in the increasing order of their
accept IDs. At last a Service Acknowledgment (SrvAck) message is sent
to indicate that the processing of a corresponding AntiEtrpRqst has
been completed (Figure 9). A new registration state is sent as a
fresh SrvReg with its remaining lifetime. A newly deregistered state
is propagated as a SrvDeReg. Note that multiple Srv(De)Reg(s) can be
sent as one TCP stream for efficiency.
+------+ AntiEtrpRqst +------+
| | -------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------- | |
+------+ New States via Srv(De)Reg(s) + SrvAck +------+
Figure 9. Anti-entropy via AntiEtrpRqst, Srv(De)Reg(s) and SrvAck
4.8. Direct Forwarding
+------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+
| | ---------------------> | | --------------------> | |
| MSA1 | | MDA1 | | MDA2 |
| | <--------------------- | | | |
+------+ SrvAck +------+ +------+
Figure 10. Direct forwarding of a Srv(De)Reg
Zhao, et al. Expires: February 27, 2003 [Page 10]
Internet Draft DA Interaction August 27, 2002
After sending all new registration states accepted by itself to a
peer (via anti-entropy), an MDA directly forwards newly received
registration updates from MSAs to the peer until a failure occurs.
In Figure 10, when a Srv(De)Reg is directly forwarded from MDA1 to
MDA2, its Fwd-ID is set to Fwded, and its accept timestamp is set to
its arrival timestamp at MDA1. Note that a direct forwarding is
performed asynchronously: MDA1 can send a SrvAck to MSA1 before it
forwards the Srv(De)Reg to MDA2. Also note that the direct forwarding
of a Srv(De)Reg goes only one-hop from its accept DA to all peers.
4.9. SrvAck Message
According to [RFC2608], a DA MUST reply with a SrvAck to a Srv(De)Reg
when the message is received from an SA. However, an MDA SHOULD NOT
reply with a SrvAck to a Srv(De)Reg if the message is received from a
peer. This is for efficiency because peers exchange Srv(De)Reg
messages via reliable peering connections. Note that an MDA MUST
reply with a SrvAck to an AntiEtrpRqst.
4.10. Control Information
For each registration entry, an MDA maintains the following control
information: accept ID (for registration propagation), version
timestamp (for registration version resolution - rejecting previous
updates), and deletion flag (deregistered or not).
For all registration entries, an MDA maintains a summary vector to
reflect its received registrations so far.
5. Summary
mSLP extends SLPv2 with three new definitions: a new attribute -
"mesh-enhanced" for DAAdvert, a new message extension - MeshFwd, and
a new message type - AntiEtrpRqst.
A UA MAY prefer an MDA to a non-MDA since an MDA is more likely to
reliably contain the complete set of current service registrations
for the UA's scopes.
A non-MSA needs to discover and register with all DAs in its scopes.
It does not use the MeshFwd extension.
A non-MDA accepts Srv(De)Reg(s) from SAs normally. It does not
forward them.
For all MDAs, an MSA only needs to discover and register with
sufficient number of them such that they cover its scopes. It uses
Zhao, et al. Expires: February 27, 2003 [Page 11]
Internet Draft DA Interaction August 27, 2002
the MeshFwd extension when it registers with MDAs.
An MDA carries the "mesh-enhanced" attribute keyword in its DAAdvert.
It maintains a peer relationship to each peer. It accepts
registrations from SAs and peers, propagates registrations via anti-
entropy and direct forwarding to peers.
6. Constants
Mesh Forwarding Extension ID 6 (Section 4.3)
Anti-Entropy Request Message Type 12 (Section 4.6)
CONFIG_DA_KEEPALIVE 200 seconds (Section 3.4)
CONFIG_DA_TIMEOUT 300 seconds (Section 3.4)
7. Security Considerations
mSLP uses standard SLPv2 authentication. First, an MDA SHOULD
authenticate other MDAs before setting up a peer relationship with
them so as to prevent any malicious MDA from joining the DA mesh.
Second, as a successful attack at an MDA may affect all MDAs in the
DA mesh, an MDA SHOULD authenticate MSAs before accepting and
forwarding their Srv(De)Reg messages to prevent illegitimate
modification or elimination of service registrations. Third, as an
MSA depends on the MDA with which it registers to forward its
Srv(De)Reg messages, it SHOULD authenticate the MDA to avoid using a
malicious MDA.
8. Acknowledgments
James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and
Xingang Guo provided valuable comments for this document.
9. Normative References
[RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service
location protocol, version 2", RFC 2608, June 1999.
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
10. Non-normative References
[RFC1771] Y. Rekhter and T. Li, "A border gateway protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2610] C. Perkins and E. Guttman, "DHCP options for service
location protocol", RFC 2610, June, 1999.
Zhao, et al. Expires: February 27, 2003 [Page 12]
Internet Draft DA Interaction August 27, 2002
[EPID-ALGO] 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.
[UPDA-PROP] 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.
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 (2002). 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.
Zhao, et al. Expires: February 27, 2003 [Page 13]
Internet Draft DA Interaction August 27, 2002
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: February 27, 2003 [Page 14]