INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-10.txt Columbia University Expires: October 30, 2001 Erik Guttman Sun Microsystems April 30, 2001 mSLP - Mesh-enhanced Service Location Protocol draft-zhao-slp-da-interaction-10.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 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: October 30, 2001 [Page 1]
Internet Draft DA Interaction April 30, 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 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 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 we give terminology in Section 3. Section 4 defines the mesh-control message type and the mesh-forwarding extension. Section 5 presents design overview. We describe peer relationship management and registration propagation control 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, SLPv2 DA messages are used for three purposes: acknowledging SA registrations, answering UA queries and enabling DA discovery. 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 Zhao, et al. Expires: October 30, 2001 [Page 2]
Internet Draft DA Interaction April 30, 2001 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 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 We see that SLPv2 does not explicitly define message flows among DAs. The only message that a DA may receive from another DA is DAAdvert. To enable DAs to properly interact with each other, we need to design message flows among DAs. For which, some existing SLPv2 messages will be used (such as DAAdvert and "service:directory-agent" SrvRqst) and a new SLPv2 message type and extension will be defined (Section 4). 3. Terminology We first define our 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]. Zhao, et al. Expires: October 30, 2001 [Page 3]
Internet Draft DA Interaction April 30, 2001 Peer DAs Peer DAs have one or more scopes in common within one administrative domain. They coordinate with each other and maintain the same consistent data for shared scopes. Peering Connection A peering connection is a persistent TCP connection kept by a pair of peer DAs for the entire peering period. It provides a reliable FIFO communication channel for peer DAs to exchange messages. The closing of a peering connection terminates the peer relationship. Mesh-enhanced DA A mesh-enhanced DA maintains peering connections to all of its peers and properly interacts with them. Such a DA MUST carry the "mesh-enhanced" attribute keyword in its DAAdvert message (Figure 4). +------------------+ +----------+ | | DAAdvert | | | Mesh-enhanced DA | ----------------------------> | DA/UA/SA | | | [attr = mesh-enhanced] | | +------------------+ +----------+ Figure 4. DAAdvert from a Mesh-enhanced DA Mesh-aware SA A mesh-aware SA understands the "mesh-enhanced" attribute keyword in DAAdvert messages and uses the mesh-forwarding capability of mesh-enhanced DAs for its service 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 write request on a service registration, which is specified by a SrvReg or SrvDeReg message. Note that in SLPv2, a SrvReg can be a fresh registration or an incremental update to a previous registration while a SrvDeReg can remove a whole registration or only some attributes of it. Registration State A registration state refers to an entry in the service registration database. Zhao, et al. Expires: October 30, 2001 [Page 4]
Internet Draft DA Interaction April 30, 2001 RqstFwd Registration A SrvReg/SrvDeReg is a RqstFwd registration if it uses the MeshFwd extension (Section 4.2) to explicitly request it be distributed by mesh-enhanced DAs. Version Timestamp For each RqstFwd registration, the SA MUST provide a version timestamp in the MeshFwd extension, which is the wall clock in millisecond resolution to ensure that any two updates sent from the same SA will have different version timestamps. Accepting DA The DA that accepts a registration update from an SA is the accepting DA for the update. The accepting DA for a registration state is the accepting DA for the latest update that has been applied to the state. Accepting Timestamp Each registration update is assigned an accepting timestamp by its accepting DA, which is the wall clock in millisecond resolution to ensure that any two updates accepted by the same DA will have different accepting timestamps. The accepting timestamp of a registration state is the accepting timestamp of the latest update that has been applied to the state. Accepting ID Each registration update and state has an unique accepting ID which is the combination of its accepting DA and accepting timestamp. Accepting IDs define a total order over all registrations accepted by a DA and a partial order over all registrations in an SLP deployment. When a registration is propagated from one DA to another DA, its accepting ID is carried in the MeshFwd extension. 4. Definitions for Mesh Enhancement A mesh-enhanced DA MUST support the mesh-control (MeshCtrl) message type and the mesh-forwarding (MeshFwd) extension. They are used to specify extended operations for mesh-enhanced DAs. 4.1. Mesh-control Message The MeshCtrl message uses 12 as its Function-ID. Figure 5 gives its format and five defined control IDs (Ctrl-IDs). Zhao, et al. Expires: October 30, 2001 [Page 5]
Internet Draft DA Interaction April 30, 2001 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ctrl-ID | Number of DAs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of DA #1 URL | DA #1 URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA #1 Latest Accepting Timestamp (LAT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA #1 LAT, contd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ . . . \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of DA #N URL | DA #N URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA #N Latest Accepting Timestamp (LAT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA #N LAT, contd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ctrl-ID Abbreviation 1 KeepAlive 2 PeerList 3 StateReport 4 BatchBegin 5 BatchEnd Figure 5. MeshCtrl Message and its Ctrl-IDs KeepAlive, BatchBegin and BatchEnd For them, all fields after the Ctrl-ID are empty. BatchBegin and BatchEnd are optional (Section 7.1). PeerList It carries the common peers that the sending DA shares with the receiving DA (all timestamp fields are zeros). StateReport It carries the state summary (Section 5.3) of the sending DA. 4.2. Mesh-forwarding Extension The MeshFwd extension uses 6 as its extension ID. Figure 6 shows its format and two defined forward IDs (Fwd-IDs). Zhao, et al. Expires: October 30, 2001 [Page 6]
Internet Draft DA Interaction April 30, 2001 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, contd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Timestamp, contd. | Length of Accepting DA URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accepting DA URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accepting Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accepting Timestamp, contd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fwd-ID Abbreviation 1 RqstFwd 2 Fwded Figure 6. MeshFwd Extension and its Fwd-IDs RqstFwd It is used by a mesh-aware SA to request mesh-enhanced DAs propagate the registration. It carries a version timestamp, but without an accepting ID. Fwded It carries both the version timestamp and the accepting ID for a registration which is propagated from a DA to another DA. 5. Design Overview mSLP was designed to be simple, efficient and robust. In this section, we give an overview of its design. First we present its fully-meshed peering DA architecture, then we describe its simplified SA registration scheme, registration propagation model and registration version resolution, finally we discuss the handling of deleted registration states. 5.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 Zhao, et al. Expires: October 30, 2001 [Page 7]
Internet Draft DA Interaction April 30, 2001 be served by multiple DAs. For DA interaction, mSLP employs a fully- meshed peering DA architecture. First, DAs that share serving scopes are peers. Peer DAs may have exactly the same serving 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 communication channel for them to exchange data in all of their shared scopes. Third, service registrations received by one DA are properly propagated to all of its peers, thus peer DAs maintain the same consistent data for their common scopes. Figure 7 gives an example of fully-meshed peering relationships among DAs. Since DA3 shares serving scopes with DA1, DA2 and DA4, it maintains peering connections to all of them and exchanges service registrations with them in the corresponding common scopes. DA1 and DA2 have exactly the same serving scopes, they exchange service registrations 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 7. 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 the maximum robustness. We anticipate that a small number of DAs for each service scope is sufficient to achieve high reliability; too large peer sets are not desirable as they significantly increase maintenance 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. 5.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 Zhao, et al. Expires: October 30, 2001 [Page 8]
Internet Draft DA Interaction April 30, 2001 have rebooted. This requires an SA be responsible for distributing its registrations to DAs, which places a substantial burden on an SA implementation. mSLP provides an alternative but 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. In mSLP, a mesh-aware SA only needs to register with one mesh- enhanced DA that covers its scopes; the registration will then be propagated automatically to other DAs in its scopes. If there is no single mesh-enhanced DA that covers its scopes, a mesh-aware SA needs to register with several mesh-enhanced DAs such that the union of their serving scopes covers its scopes. In Figure 8, SA1 may choose to register with DA2 only or to register with both DA1 and DA3. +---------+ (x) +-----------+ (y) +---------+ | DA1 (x) | <---------> | DA2 (x,y) | <---------> | DA3 (y) | +---------+ +-----------+ +---------+ ^ (option2) ^ (option1) ^ (option2) | | | | | (x,y) | | (x) +-----------+ (y) | +----------------- | SA1 (x,y) | -----------------+ +-----------+ Figure 8. Options for Registration with Mesh-enhanced DAs For compatibility consideration, 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 MeshFwd extension to request mesh-enhanced DAs distribute its registrations. 5.3. Registration Propagations In mSLP, only RqstFwd registrations are propagated by mesh-enhanced DAs (non-RqstFwd registrations SHOULD not be propagated). mSLP propagates registrations according to their accepting ID orders: (1) registrations accepted by the same DA are propagated in the increasing order of their accepting timestamps; (2) registrations accepted by different DAs can be propagated in any orders. Based on this propagation ordering, a mesh-enhanced DA can accurately and compactly represent the registrations it has observed by using a state summary, which includes all the latest accepting IDs it has received. For example, if DAi has a state summary of ((DA1, T1), (DA2, T2), ..., (DAn, Tn)), then DAi has observed all registrations prior to Tj accepted by DAj, where 1<=i,j<=n. Zhao, et al. Expires: October 30, 2001 [Page 9]
Internet Draft DA Interaction April 30, 2001 mSLP propagates registrations in two ways: direct forwarding (push model) and anti-entropy (pull model). A mesh-enhanced DA uses direct forwarding to forward its newly received registration updates from SAs to its peers in the corresponding scopes. The direct forwarding of an update only goes one-hop from the accepting DA to its peers. As peer DAs are in a fully connected mesh, one-hop forwarding is sufficient to distribute an update to all DAs in the normal condition where there is no DA crashes and no network partitions. The direct forwarding aims to distribute registration updates rapidly. Anti-entropy [5,6] is used to exchange differences of registration states between two peers, which guarantees their eventual consistency. This process SHOULD be scheduled when a new peer relationship is established and when failure conditions are fixed (DA crashes and network partitions). It SHOULD also be scheduled at a regular interval if fully-meshed connections cannot be established among peer DAs. 5.4. Version Resolution If a DA only receives registrations from SAs, it can simply assume that a later arrival is a newer version of the registration. However, this is not true when registrations are propagated among DAs. For example, assume that SA1 sends a fresh SrvReg (R1) to DA1 first and another fresh SrvReg (R2) to DA2 later, when R1 and R2 are propagated, R2 MUST be installed at both DA1 and DA2. To identify the latest version, we need a version timestamp from SAs for each registration. We assume that each registration can be updated only by one SA. A DA installs an update if it has a newer version timestamp (from a mesh- aware SA or from a peer DA) or it does not have a version timestamp (from a non-mesh-aware SA). 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 yet. Blindly using incremental registrations may result incomplete registration states. 5.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 uses a technique similar to the death certificate [5], which sets a deletion flag for deleted states. 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. Zhao, et al. Expires: October 30, 2001 [Page 10]
Internet Draft DA Interaction April 30, 2001 6. Peer Relationship Management A mesh-enhanced DA MUST maintain a peer table to record information for each of its peers, which includes the peer URL, shared scopes, a reference to the peering connection, and a mesh flag (mesh-enhanced or not). Peering with a non-mesh-enhanced DA is simple, which only needs to establish a peering connection, forward newly received registration updates and send a KeepAlive MeshCtrl at a regular interval. Next we focus on the peer relationship management between two mesh-enhanced DAs. 6.1. Learning about a New Peer In SLPv2, an UA/SA learns about DAs in four ways: static configuration, DHCP [4], passive DA discovery (listen to DAAdvert multicast) and active DA discovery (multicast "service:directory- agent" SrvRqst). These mechanisms can be used as well for DAs to discover each other. Beyond that, mesh-enhanced DAs in mSLP use four additional ways for peer discovery: exchange common peers with a new peer, forward a new peer DAAdvert to existing peers (only an original DAAdvert SHOULD be forwarded, a forwarded DAAdvert MUST not be forwarded again), send an unsolicited DAAdvert to a new peer and unicast a "service:directory-agent" SrvRqst to solicit a DAAdvert. In any case, a mesh-enhanced DA MUST get a DAAdvert from a new peer before establishing the peer relationship. A new peer DAAdvert can be received passively from multicast (Figure 9-a) or from a peering connection (Figure 9-b). It can also be solicited actively via a "service:directory-agent" SrvRqst (Figure 9-c). +-----+ +-----+ | | Multicast DAAdvert | | (a) | DA1 | <------------------------------------------ | DA2 | | | | | +-----+ +-----+ +-----+ +-----+ | | Original or Forwarded DAAdvert | | (b) | DA1 | <------------------------------------------ | DA2 | | | (Peering Connection) | | +-----+ +-----+ +-----+ +-----+ | | Unicast "service:directory-agent" SrvRqst | | (c) | DA1 | ------------------------------------------> | DA2 | | | <------------------------------------------ | | +-----+ Unicast DAAdvert (UDP) +-----+ Figure 9. Getting a DAAdvert from a New Peer 6.2. Establishing a Peering Connection Zhao, et al. Expires: October 30, 2001 [Page 11]
Internet Draft DA Interaction April 30, 2001 After a mesh-enhanced DA gets a new peer DAAdvert (either directly from the peer or indirectly from another peer), if there does not exist a peering connection initiated by the peer, then it MUST create such a connection to the peer and send its DAAdvert over the connection (Figure 10). 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) Unsolicited DA1 DAAdvert +-----+ Figure 10. Establishing a Peering Connection 6.3. Exchanging Common Peers After establishing a peering connection, two peers send their existing common peers to each other via a PeerList MeshCtrl (Figure 11), which enables a DA to learn its peers incrementally from its known peers. If a mesh-enhanced DA finds any new peer URL in a PeerList MeshCtrl, it SHOULD unicast a "service:directory-agent" SrvRqst to the peer to solicit its DAAdvert (Figure 9-c). The common peers between two DAs can be constructed using Algorithm 1. +-----+ +-----+ | | PeerList MeshCtrl | | | DA1 | <--------------------------------------> | DA2 | | | (Peering Connection) | | +-----+ +-----+ Figure 11. Exchanging Common Peers Construct_Common_Peers(DA2) { CP = empty for each peer P in DA1 peer table { CS = common scopes between DA2 and P if (P <> DA2 && CS <> empty) add P to CP } return CP } Algorithm 1. DA1 Constructing Common Peers with DA2 Zhao, et al. Expires: October 30, 2001 [Page 12]
Internet Draft DA Interaction April 30, 2001 6.4. Maintaining a Peer Relationship A mesh-enhanced DA SHOULD send a KeepAlive MeshCtrl to each of its peers (Figure 12) every CONFIG_DA_KEEPALIVE seconds (Section 10). This message is used to detect failures (network partitions and peer crashes) if it is timeout (CONFIG_DA_TIMEOUT seconds, Section 10). +-----+ +-----+ | | KeepAlive MeshCtrl | | | DA1 | <--------------------------------------> | DA2 | | | (Peering Connection) | | +-----+ +-----+ Figure 12. Peer Keepalive 6.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 KeepAlive MeshCtrl is timeout. To tear down a peer relationship, a mesh-enhanced DA removes the peer from its peer table and closes the peering connection. 7. Registration Propagation Control As mSLP propagates registrations in the accepting ID order, a DA can directly forward a registration from an SA to a peer only after it has done an anti-entropy to the peer. A propagated registration MUST use the Fwded MeshFwd extension to carry its version timestamp and accepting ID. As a DA always replies with a SrvAck to a Srv(De)Reg, a mesh-enhanced DA SHOULD handle SrvAck messages properly. A direct forwarding is performed asynchronously, as shown in Figure 13, DA1 does not wait the SrvAck from DA2 before it can send a SrvAck to SA1. +-----+ RqstFwd Srv(De)Reg +-----+ Fwded Srv(De)Reg +-----+ | | ---------------------> | | ---------------------> | | | SA1 | (Peering Connection) | DA1 | (Peering Connection) | DA2 | | | <--------------------- | | <--------------------- | | +-----+ SrvAck +-----+ SrvAck +-----+ Figure 13. Direct Forwarding of a SrvReg/SrvDeReg When a mesh-enhanced DA receives a StateReport MeshCtrl from a peer, it SHOULD compare the StateReport with its own state summary, and send any new states it has in shared scopes to the peer (Figure 14). Note that a StateReport MeshCtrl is treated as a pull signal for new Zhao, et al. Expires: October 30, 2001 [Page 13]
Internet Draft DA Interaction April 30, 2001 states, so a mesh-enhanced DA SHOULD send its StateReport MeshCtrl to one peer at a time, otherwise repeated states may come from different peers. The scheduling order of StateReport MeshCtrl messages to peers may affect the anti-entropy performance. For example, scheduling a StateReport MeshCtrl to the nearest or the least loaded peer first may get new states with less delays. A new registration state is propagated 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 SrvDeReg. +-----+ StateReport MeshCtrl +-----+ | | --------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <-------------------------------------- | | +-----+ New States in Shared Scopes +-----+ Figure 14. One-way Anti-entropy 7.1. Batch Transfer: an Optional Feature To propagate new states in order in an anti-entropy, the sending DA needs to sort the new states or maintain an index from them. This burden can be avoided by using batch transfer (an optional feature for mesh-enhanced DAs), in which a mesh-enhanced DA sends a batch of unsorted states between a BatchBegin MeshCtrl and a BatchEnd MeshCtrl. When receiving a batch, a mesh-enhanced DA MUST store the latest accepting IDs in the batch temporarily, and use them to update its state summary after the whole batch has been received. A mesh- enhanced DA SHOULD carry the "batch-enabled" attribute keyword in its DAAdvert if it is capable to receive batch transfers. A DA can send a batch to a peer only if the peer is "batch-enabled". 8. Compatibility mSLP is fully backward compatible with SLPv2. It defines two new attributes ("mesh-enhanced" and "batch-enabled"), a new message type (MeshCtrl) 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 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 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. Zhao, et al. Expires: October 30, 2001 [Page 14]
Internet Draft DA Interaction April 30, 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 one or several mesh- enhanced DAs that cover its scopes and register with them using the RqstFwd MeshFwd extension (Section 5.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 5.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" (but MAY carry the "batch-enabled") attribute keyword in its DAAdvert (Section 3,7.1). Second, it MUST maintain a peer table and have peering connections to all of its peers. For each mesh-enhanced peer, KeepAlive, PeerList and StateReport MeshCtrl messages SHOULD be sent AND processed, BatchBegin and BatchEnd MeshCtrl messages MAY be sent OR processed (Section 6,7). Third, it accepts registrations from SAs and mesh-enhanced DAs, propagates RqstFwd registrations using direct forwarding and anti- entropy and processes SrvAck messages from mesh-enhanced DAs (Section 7). Fourth, it SHOULD forward a new peer DAAdvert to its existing peers (Section 6.1). 10. Constants MeshCtrl Message Type 12 (Section 4.1) MeshFwd Extension ID 6 (Section 4.2) CONFIG_DA_KEEPALIVE 200 seconds (Section 6.4) CONFIG_DA_TIMEOUT 300 seconds (Section 6.4) Zhao, et al. Expires: October 30, 2001 [Page 15]
Internet Draft DA Interaction April 30, 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] R. Droms, "Dynamic host configuration protocol", RFC 2131, March 1997. [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: October 30, 2001 [Page 16]
Internet Draft DA Interaction April 30, 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: October 30, 2001 [Page 17]