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]