INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-13.txt Columbia University November 21, 2001 Erik Guttman Expires: May 21, 2002 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 (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 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: May 21, 2002 [Page 1] Internet Draft DA Interaction November 21, 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 3.1. Fully-meshed Peering DA Architecture . . . . . . . . . . . . 4 3.2. Accept ID and Propagation Order . . . . . . . . . . . . . . 5 3.3. Version Timestamp and Registration Version Resolution . . . 6 3.4. Service Deregistration . . . . . . . . . . . . . . . . . . . 6 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 7 4.1. Mesh Forwarding Extension . . . . . . . . . . . . . . . . . 7 4.2. Data Request Message . . . . . . . . . . . . . . . . . . . . 8 4.3. Data Reply Complete Message . . . . . . . . . . . . . . . . 8 5. Peer Relationship Management . . . . . . . . . . . . . . . . 9 5.1. Discovering New Peers . . . . . . . . . . . . . . . . . . . 9 5.2. Establishing a Peering Connection . . . . . . . . . . . . . 9 5.3. Exchanging Peer and Accept DA Information via DAAdverts . . 9 5.4. Maintaining a Peer Relationship . . . . . . . . . . . . . . 10 5.5. Tearing Down a Peer Relationship . . . . . . . . . . . . . . 10 6. Registration Propagation Control . . . . . . . . . . . . . . 10 6.1. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Direct Forwarding . . . . . . . . . . . . . . . . . . . . . 12 6.3. SrvAck Messages . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Control Information for Each Registration Entry . . . . . . 12 6.5. Summary Vector for All Registration Entries . . . . . . . . 12 7. Compatibility and Incremental Deployment . . . . . . . . . . 13 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 1. Introduction In the Service Location Protocol (SLPv2 [1]), Directory Agents (DAs) accept service registrations from Service Agents (SAs) and answer queries from User Agents (UAs). They enhance the performance and scalability of SLP. When multiple DAs are present, how should they interact with each other? To address this open issue in SLPv2, we present the Mesh-enhanced Service Location Protocol (mSLP). mSLP proposes that if DAs are needed in an SLP deployment, a fully- meshed peering DA architecture (similar to IBGP [2]) should be used. Peer DAs exchange service registration states when they set up a peer relationship and continue to exchange new service registration updates during the entire peering period so as to maintain the same Zhao, et al. Expires: May 21, 2002 [Page 2] Internet Draft DA Interaction November 21, 2001 consistent data for shared scopes. mSLP improves the reliability and consistency of SLP directory services. It also simplifies SA registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. Currently, SLPv2 has three kinds of DA message flows: acknowledging SA registrations, answering UA queries and enabling DA discovery; message flows among DAs are not explicitly defined - DAAdvert is the only message that a DA may receive from other DAs. We will define a set of message flows for DA interactions in this document. 2. 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. Peering Connection A peering connection is a persistent TCP connection between two peer DAs, which provides a reliable FIFO channel for their message exchanges. The closing of a peering connection 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-enhanced SA A mesh-enhanced SA understands the "mesh-enhanced" attribute keyword in the DAAdvert and uses the Mesh Forwarding extension (Section 4) in its SrvReg/SrvDeReg messages. Registration Update A registration update refers to a SrvReg/SrvDeReg message. Registration State A registration state refers to an entry in the registration database. Accept DA For each registration update, the first DA accepting the update is the Accept DA for the update. An update is Zhao, et al. Expires: May 21, 2002 [Page 3] Internet Draft DA Interaction November 21, 2001 propagated from its Accept DA to other DAs. Accept Timestamp When a registration update is accepted by its Accept DA, it is assigned an Accept Timestamp in millisecond-accuracy. All Accept Timestamps assigned by the same DA MUST be monotonically increasing. Version Timestamp Each SrvReg/SrvDeReg sent from mesh-enhanced SAs MUST be assigned a Version Timestamp in millisecond-accuracy. All Version Timestamps assigned by the same SA MUST be monotonically increasing. 3. Protocol Overview For convenience of presentation, we first discuss interactions among mesh-enhanced DAs and SAs, then address incremental deployment of these mesh-enhanced agents, and mSLP compatibility with SLPv2 (Section 7). 3.1. Fully-meshed Peering DA Architecture In SLPv2, a DA can serve multiple scopes and a scope can have multiple DAs. mSLP enhances SLP DA services and simplifies SA registrations by using a fully-meshed peering DA architecture based on scopes. In mSLP, DAs that share service scopes are peers. Each pair of peer DAs has a peering connection, and all peer DAs in each scope maintain a set of fully-meshed peering connections. Registrations received by one DA are properly propagated to its peers, thus peer DAs maintain the same consistent registration states for their common scopes. In Figure 1, DA3 shares service scopes ("y", "y" and "z", respectively) with DA1, DA2 and DA4, so it maintains a peering connection and exchanges registrations with all of them. DA1 and DA2 have exactly the same service scopes, and exchange registrations in scope "x,y" using a single peering connection. (x,y) +-------------------------------------------------+ | +-----------+ | | | DA4 (z) | | | +-----------+ | | | (z) | +-----------+ (y) +-----------+ (y) +-----------+ | DA1 (x,y) | ---------- | DA3 (y,z) | ---------- | DA2 (x,y) | +-----------+ +-----------+ +-----------+ Figure 1. A Fully-meshed Peering DA Architecture Zhao, et al. Expires: May 21, 2002 [Page 4] Internet Draft DA Interaction November 21, 2001 The fully-meshed peering DA architecture improves SLP DA services. It avoids a single point of failure by replicating data among at least two peer DAs, automatically synchronizing data among these DAs. It also enables a DA to recover from a crash with much less effort, since a rebooted DA can get the existing registrations from its peer DAs purely through DA coordination, without involving SAs. The fully-meshed peering DA 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, which places a substantial burden on an SA implementation. In contrast, mSLP shifts the task of distributing service registrations to multiple DAs from many SAs to a few DAs, which is more efficient. In mSLP, a mesh-enhanced SA needs to register with only sufficient number of mesh-enhanced DAs such that the union of these DAs' service scopes covers its scopes. The registrations will then be propagated automatically to other DAs in the registration scopes. In Figure 2, DA1, DA2 and DA3 are mesh- enhanced DAs, thus SA1 may register with DA2, or with both DA1 and DA3, but SA1 does not need to register with all DA1, DA2 and DA3. By simplifying SAs, the overall SLP system scalability can be improved. (option2) +-----------+ (option2) +----------------- | SA1 (x,y) | -----------------+ | +-----------+ | | | (option1) | V V V +---------+ +-----------+ +---------+ | DA1 (x) | ----------- | DA2 (x,y) | ----------- | DA3 (y) | +---------+ +-----------+ +---------+ Figure 2. Options for Registration with Mesh-enhanced DAs 3.2. Accept ID and Propagation Order In mSLP, each registration update has a unique Accept ID [6], and a registration state inherits the Accept ID from the latest update applied to it. An Accept ID has two components: Accept DA and Accept Timestamp. Accept IDs define a total order for all registrations accepted by the same DA. A mesh-enhanced DA MUST propagate registrations in the increasing order of their Accept IDs, i.e., those accepted by the same DA MUST be propagated in the increasing order of their Accept Timestamps, and those accepted by different DAs MAY be propagated in any orders. The ordering propagation enables a DA to represent its received registrations using a Summary Vector, i.e., up to what points (in term of Accept Timestamps) the DA has received registrations accepted Zhao, et al. Expires: May 21, 2002 [Page 5] Internet Draft DA Interaction November 21, 2001 by its peer DAs. A Summary Vector at a DA includes all the latest Accept IDs it has received. For example, if the Summary Vector of DAi is ((DA1, T1), (DA2, T2), ..., (DAn, Tn)), then it means that DAi has received all registrations prior to timestamp Tj accepted by DAj, where 1<=i,j<=n. A direct consequence of the ordering propagation is that when a mesh-enhanced DA receives an update propagated from a peer DA, the Accept ID of the received update MUST be greater than an entry in its Summary Vector: if there is no corresponding entry in its Summary Vector, the receiving DA needs to add an entry for this Accept DA; if the received update has a smaller Accept ID (indicating an error), the receiving DA SHOULD discard the update. The ordering propagation ensures that no update is missed for propagation. By using the Summary Vector, each pair of peer DAs can easily determine the difference of their received updates, and exchange only new updates (not the whole database) to synchronize their registration states whenever they need to catch up registration updates with each other (after failure, boot, or reboot). 3.3. Version Timestamp and Registration Version Resolution When registrations are propagated among DAs, their arrival timestamps at DAs cannot be used for version resolution. For example, assume that 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 mSLP, a mesh-enhanced DA MUST use the Version Timestamp for registration version resolution. mSLP assumes that each registration is updated only by one SA, thus a mesh-enhanced DA does not need to compare Version Timestamps from two different SAs. A mesh-enhanced DA installs a registration update if and only if the update has a newer Version Timestamp (from a mesh-enhanced SA), or the update does not have the Mesh Forwarding extension (from a non-mesh-enhanced SA). As incremental registrations and partial deregistrations may result in incomplete registration states, especially when updates are propagated, a mesh-enhanced SA MUST use the Mesh Forwarding extension with a fresh SrvReg, or with a complete SrvDeReg. 3.4. Service Deregistration When a mesh-enhanced DA receives a SrvDeReg, it SHOULD mark the corresponding service entry in the database as deleted so that the entry will not appear in any query reply. However, whether a deregistered service entry exists or not, a mesh-enhanced DA SHOULD Zhao, et al. Expires: May 21, 2002 [Page 6] Internet Draft DA Interaction November 21, 2001 retain the SrvDeReg information properly to prevent earlier SrvReg messages from mistakenly causing this service entry to reappear in the database. A registration state (whether deregistered or not) will be purged from the database when it expires. 4. Protocol Elements mSLP defined a new SLP message extension - Mesh Forwarding, and two new SLP message types - Data Request and Data Reply Complete; all of them carry an Accept ID. Figure 3 shows the format of an Accept ID. 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 3. Accept ID 4.1. Mesh Forwarding Extension The Mesh Forwarding (MeshFwd) extension is used in a SrvReg/SrvDeReg message. It carries a Version Timestamp and an Accept ID. Its extension ID is 6. Figure 4 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Timestamp, cont'd. | Accept ID \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fwd-ID Abbreviation 1 RqstFwd 2 Fwded Figure 4. MeshFwd Extension and its Fwd-IDs Zhao, et al. Expires: May 21, 2002 [Page 7] Internet Draft DA Interaction November 21, 2001 A mesh-enhanced SA uses the RqstFwd Mesh Forwarding extension (Fwd-ID = RqstFwd, Accept Timestamp = 0) in a SrvReg/SrvDeReg to explicitly request a mesh-enhanced DA (the Accept DA) to forward the message. A mesh-enhanced DA uses the Fwded Mesh Forwarding extension (Fwd-ID = Fwded, Accept Timestamp != 0) in each SrvReg/SrvDeReg sent from it to another DA. A mesh-enhanced DA sends a SrvReg/SrvDeReg in two cases: forwarding a SrvReg/SrvDeReg received from an SA if and only if the message has the RqstFwd Mesh Forwarding extension, or propagating a registration state in its database. 4.2. Data Request Message 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 5. DataRqst Message The Data Request (DataRqst) message carries an Accept ID. Its Function-ID is 12. Figure 5 shows its format. The DataRqst message is used by a mesh-enhanced DA to request new registration states from a peer. The receiving DA of this message SHOULD send its registration states that have an Accept ID greater than the Accept ID specified in this message. Note that a DataRqst message requests new registration states accepted by one DA; to request new registration states accepted by multiple DAs needs to use multiple DataRqst messages, and each DataRqst message uses a different Accept DA. 4.3. Data Reply Complete Message 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 = DataRplyCmpl = 13) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept ID \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. DataRplyCmpl Message The Data Reply Complete (DataRplyCmpl) message carries an Accept ID. Its Function-ID is 13. Figure 6 shows its format. The DataRplyCmpl message is used by a mesh-enhanced DA to notify a peer that the Zhao, et al. Expires: May 21, 2002 [Page 8] Internet Draft DA Interaction November 21, 2001 replies (via SrvReg/SrvDeReg messages) to a corresponding DataRqst from the peer have been completed. A DataRplyCmpl and its corresponding DataRqst carry the same Accept ID. The DataRplyCmpl message enables the receiving DA to know when it has got all requested states (solicited via a corresponding DataRqst) from a peer, and then the DA may start a new DataRqst if needed. 5. Peer Relationship Management A mesh-enhanced DA maintains the following information for each peer: peer DAAdvert, expiration time, reference to the peering connection, and whether direct forwarding is enabled to the peer. 5.1. Discovering New Peers A mesh-enhanced DA can learn about new peers via static configuration, DHCP [4], DAAdvert multicast, solicited DAAdvert unicast [1], and unsolicited DAAdvert unicast (Section 5.2, 5.3). In any case, a mesh-enhanced DA MUST get the DAAdvert of a new peer before establishing the peer relationship to the peer. 5.2. Establishing a Peering Connection After getting the DAAdvert of a new peer, a mesh-enhanced DA MUST create a peering connection to the peer if such a connection does not exist yet. Then the initiating DA of a peering connection sends its DAAdvert via the connection (Figure 7). A DA can identify a peering connection initiated by a peer by receiving the peer's DAAdvert from the connection. Normally, one 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, which is inefficient but does not affect the correctness. +-----+ (1) DA2 DAAdvert | +-----+ | | <--------------------+ | | | DA1 | (2) Create a Peering Connection | DA2 | | | ---------------------------------------> | | +-----+ (3) DA1 DAAdvert +-----+ Figure 7. Establishing a Peering Connection 5.3. Exchanging Peer and Accept DA Information via DAAdverts After establishing a new peering connection, peer DAs exchange their peer and Accept DA information via DAAdverts. For all existing peers and all Accept DAs of its registration database, a mesh-enhanced DA sends their DAAdverts to the new peer (Figure 8). Note that all Zhao, et al. Expires: May 21, 2002 [Page 9] Internet Draft DA Interaction November 21, 2001 DAAdverts can be sent as one TCP stream for efficiency. Exchanging peer and Accept DA information enables a DA to learn about peers incrementally from its known peers, and to know the Accept DA set of the new peer. +-----+ DAAdvert(s) of DA1's Peers or Accept DAs +-----+ | | -----------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <----------------------------------------- | | +-----+ DAAdvert(s) of DA2's Peers or Accept DAs +-----+ Figure 8. Exchanging Peer and Accept DA Information via DAAdverts 5.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 9) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 9). +-----+ DA1 DAAdvert +-----+ | | ---------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <--------------------------------------- | | +-----+ DA2 DAAdvert +-----+ Figure 9. Maintaining a Peer Relationship 5.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. 6. Registration Propagation Control In mSLP, service registrations are propagated in two ways among peer DAs via peering connections: anti-entropy [5] and direct forwarding. Anti-entropy is used for exchanging initial states when two peer DAs get to know each other at the first time, and for catching up new states after failures (DA crashes and network partitions). In normal condition, direct forwarding is used by a DA to forward newly received SrvReg/SrvDeReg messages from SAs to peer DAs directly. Note that anti-entropy transfers new states in batch, whereas direct Zhao, et al. Expires: May 21, 2002 [Page 10] Internet Draft DA Interaction November 21, 2001 forwarding conveys new updates individually. 6.1. Anti-entropy A mesh-enhanced DA triggers an anti-entropy when it receives a DataRqst from a peer: it checks its Summary Vector and sends the requested new registration states it has to the peer in the increasing order of their Accept Timestamps (Figure 10). 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 SrvReg/SrvDeReg(s) can be sent as one TCP stream for efficiency. +-----+ DataRqst +-----+ | | -------------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <------------------------------------------- | | +-----+ New States via Srv(De)Reg(s) + DataRplyCmpl +-----+ Figure 10. Anti-entropy via DataRqst, Srv(De)Reg(s) and DataRplyCmpl Normally a mesh-enhanced DA needs to request new registration states only directly from their Accept DAs, but indirect requests are needed if failures occur. For example, assume that DA1 (scope "x,y"), DA2 (scope "x") and DA3 (scope "y") have set up peer relationships, then DA1 crashes. If DA4 (scope "x,y") wants to join DA1, DA2 and DA3 and get registrations accepted by them, DA4 can directly request registrations accepted by DA2 (or DA3) from DA2 (or DA3), but needs to indirectly request registrations accepted by DA1 from DA2 for scope "x" and from DA3 for scope "y" (Figure 11). DA4 ---- DataRqst (DA2, 0) ---> DA2 DA4 ---- DataRqst (DA3, 0) ---> DA3 DA4 ---- DataRqst (DA1, 0) ---> DA2 DA4 ---- DataRqst (DA1, 0) ---> DA3 Figure 11. Requesting New States Directly and Indirectly The DataRqst message enables a lightweight anti-entropy among peer DAs. In the traditional anti-entropy [6], a DA requests updates accepted by all DAs in one message (in this case the DataRqst should carry a list of Accept IDs - the Summary Vector of the sending DA), but the DA needs to request updates from one peer at a time, otherwise it will get repeated updates. In mSLP, a DA requests updates accepted by one DA at a time from a peer, thus a newly joined (rebooted, or reconnected) DA can directly request updates from all peer DAs at the same time without getting repeated updates, which is simple for use, efficient in the normal case (no failures) and Zhao, et al. Expires: May 21, 2002 [Page 11] Internet Draft DA Interaction November 21, 2001 flexible to support different requirements. 6.2. Direct Forwarding After sending all new registration states accepted by itself to a peer in answering the peer's DataRqst, a mesh-enhanced DA directly forwards newly received updates from SAs to the peer until a failure occurs. Thus, the typical steps of registration propagation from DA1 to DA2 are as follows: (1) DA1 receives a DataRqst (DA1, TSx) from DA2; (2) DA1 sends new states to DA2 in answering DA2's DataRqst; (3) DA1 directly forwards its accepted updates to DA2; (4) DA1 stops direct forwarding to DA2 if a failure occurs. In Figure 12, when a SrvReg/SrvDeReg is directly forwarded from DA1 to DA2, its Fwd-ID = Fwded, Accept Timestamp = its arrival timestamp at DA1. Note that a direct forwarding is performed asynchronously: DA1 can send a SrvAck to SA1 before it forwards the SrvReg/SrvDeReg to DA2. Also note that the direct forwarding of a SrvReg/SrvDeReg goes only one-hop from its Accept DA to other DAs. As peer DAs are in a full mesh, one-hop forwarding is sufficient to distribute registration updates among peer DAs when there is no failure. +-----+ RqstFwd Srv(De)Reg +-----+ Fwded Srv(De)Reg +-----+ | | ---------------------> | | ---------------------> | | | SA1 | | DA1 | | DA2 | | | <--------------------- | | | | +-----+ SrvAck +-----+ +-----+ Figure 12. Direct Forwarding of a SrvReg/SrvDeReg 6.3. SrvAck Messages According to [1], a DA MUST reply with a SrvAck to a SrvReg/SrvDeReg when the message is received from an SA. However, a mesh-enhanced DA SHOULD NOT reply with a SrvAck to a SrvReg/SrvDeReg if the message is received from a peer DA. This is for efficiency because peer DAs exchange SrvReg/SrvDeReg messages via reliable peering connections. A mesh-enhanced DA SHOULD also ignore SrvAck messages received from peer DAs. 6.4. Control Information for Each Registration Entry For each registration entry, a mesh-enhanced DA maintains the following control information: Accept ID (for update propagation), Version Timestamp (for registration version resolution - rejecting previous updates), and deletion flag (deregistered or not). 6.5. Summary Vector for All Registration Entries Zhao, et al. Expires: May 21, 2002 [Page 12] Internet Draft DA Interaction November 21, 2001 A mesh-enhanced DA maintains a Summary Vector to reflect its received registrations so far. When a SrvReg/SrvDeReg is received from an SA or from its Accept DA, a mesh-enhanced DA updates its Summary Vector directly, otherwise, the DA needs to update its Summary Vector on scope basis. Consider the example in Figure 11, when DA4 receives registrations accepted by DA1 from DA2, it updates DA1's latest Accept Timestamp for scope x, similarly, when DA4 receives registrations accepted by DA1 from DA3, it updates DA1's latest Accept Timestamp for scope y. Thus, when requesting new registration states from a peer indirectly via a DataRqst, a mesh-enhanced DA needs to use a scope-based Accept ID. 7. Compatibility and Incremental Deployment mSLP is backward compatible with SLPv2. A mesh-enhanced DA supports extended operations without affecting its original functionality. 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 Mesh Forwarding extension. mSLP supports incremental deployment of mesh-enhanced DAs and SAs. In a mixed deployment of mesh-enhanced and non-mesh-enhanced DAs and SAs, there are six types of interactions among DAs and SAs. Mesh-enhanced DA vs. Mesh-enhanced DA A mesh-enhanced DA interacts with other mesh-enhanced DAs as described in Section 5 and 6 of this document. Mesh-enhanced DA vs. Mesh-enhanced SA A mesh-enhanced DA interacts with mesh-enhanced SAs as described in Section 6 of this document. Mesh-enhanced DA vs. Non-mesh-enhanced DA A mesh-enhanced DA MUST establish a TCP connection with non-mesh-enhanced DAs in its scopes, and forward newly received SrvReg/SrvDeReg messages to them on behalf of mesh-enhanced SAs (registrations from non-mesh-enhanced SAs SHOULD NOT be forwarded). A mesh-enhanced DA MUST be prepared for a non-mesh-enhanced peer to drop the connection. In this case, the mesh-enhanced DA reopens a TCP connection. Note that a mesh-enhanced DA does not send the DataRqst, DataRplyCmpl, and other DAs' DAAdverts to a non- mesh-enhanced peer. Mesh-enhanced DA vs. Non-mesh-enhanced SA A mesh-enhanced DA operates as a non-mesh-enhanced DA [1] for all non-mesh-enhanced SAs. Mesh-enhanced SA vs. Non-mesh-enhanced DA Zhao, et al. Expires: May 21, 2002 [Page 13] Internet Draft DA Interaction November 21, 2001 If there are no mesh-enhanced DAs covering its scopes, for uncovered scopes, a mesh-enhanced SA operates as a non- mesh-enhanced SA [1] to interact with non-mesh-enhanced DAs. Non-mesh-enhanced SA vs. Non-mesh-enhanced DA They interact as described in [1]. In a mixed deployment of mesh-enhanced and non-mesh-enhanced DAs, mesh-enhanced SAs still need to take care of newly found and rebooted non-mesh-enhanced DAs as these DAs cannot get existing registrations from other DAs, therefore, uniform deployment of mesh-enhanced DAs is much more desirable than partial deployment. 8. Summary mSLP extends SLPv2 with four new definitions: a new DAAdvert attribute - "mesh-enhanced", a new message extension - MeshFwd, and two new message types - DataRqst and DataRplyCmpl. UA It MAY prefer 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-enhanced SA It needs to discover and register with all DAs in its scopes. It does not use the Mesh Forwarding extension. Non-mesh-enhanced DA It accepts SrvReg/SrvDeReg messages from SAs and mesh- enhanced DAs normally. It does not forward them. Mesh-enhanced SA It needs to discover only sufficient number of mesh-enhanced DAs that cover its scopes. It MUST register with mesh- enhanced DAs via the fresh SrvReg and complete SrvDeReg messages using the RqstFwd Mesh Forwarding extension. Mesh-enhanced DA It MUST carry the "mesh-enhanced" attribute keyword in its DAAdvert, maintain a peer table, and have peering connections to all peers. For each mesh-enhanced peer, the DataRqst and DataRplyCmpl MUST be sent AND processed. Also, it accepts registrations from SAs and mesh-enhanced DAs, propagates registrations in order. Furthermore, it SHOULD exchange peer and Accept DA information via DAAdverts with a new peer. Zhao, et al. Expires: May 21, 2002 [Page 14] Internet Draft DA Interaction November 21, 2001 9. Constants Mesh Forwarding Extension ID 6 (Section 4.1) Data Request Message Type 12 (Section 4.2) Data Reply Complete Message Type 13 (Section 4.3) CONFIG_DA_KEEPALIVE 200 seconds (Section 5.4) CONFIG_DA_TIMEOUT 300 seconds (Section 5.4) 10. Security Considerations mSLP uses standard SLPv2 authentication. First, a mesh-enhanced DA SHOULD authenticate other DAs before setting up a peer relationship with them so as to prevent any malicious DA from joining the DA mesh. Second, as a successful attack at a mesh-enhanced DA may affect all DAs in the DA mesh, a mesh-enhanced DA SHOULD authenticate SAs before accepting and forwarding their SrvReg/SrvDeReg messages to prevent illegitimate modification or elimination of service registrations. Third, as a mesh-enhanced SA depends on the mesh-enhanced DA with which it registers to forward its SrvReg/SrvDeReg messages, it SHOULD authenticate the DA to avoid using a malicious mesh-enhanced DA. 11. Acknowledgements James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and Xingang Guo provided valuable comments for this document. 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, Zhao, et al. Expires: May 21, 2002 [Page 15] Internet Draft DA Interaction November 21, 2001 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 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: May 21, 2002 [Page 16]